Die 10 wichtigsten SAP-Tabellen im FI/CO-Überblick
Wo stecken die Daten eigentlich? Wer mit SAP FI/CO arbeitet, kommt an dieser Frage nicht vorbei. Dieser Artikel erklärt die zehn wichtigsten Tabellen — was sie enthalten, für wen sie relevant sind und wann man sie im Arbeitsalltag wirklich braucht. Mit praktischen Hinweisen zu ECC und S/4HANA.
Wer mit SAP arbeitet, kommt früher oder später an einen Punkt, an dem eine Frage auftaucht, die sich nicht über eine Transaktion beantworten lässt: Wo stecken diese Daten eigentlich?
Die Antwort liegt in den SAP-Tabellen. Jede Buchung, jeder Stammsatz, jede Customizing-Einstellung — alles landet letztlich in einer Tabelle. Ein SAP-System enthält schnell mehrere hunderttausend davon, je nach Modulumfang und Eigenentwicklungen. Die meisten davon sieht man nie. Aber ein paar tauchen immer wieder auf, egal ob man gerade eine Buchung analysiert, ein Problem debuggt oder ein Konzept schreibt.
Genau diese Tabellen sind hier aufgeführt: die zehn, die im FI/CO-Umfeld wirklich jeder kennen sollte. Mit dem Hinweis, was drinsteckt — und für wen sie besonders relevant sind.
So schaut man in eine SAP-Tabelle
Tabelleninhalte lassen sich über die Transaktion SE16 oder SE16N einsehen. Die Tabellenstruktur — also welche Felder eine Tabelle hat — zeigt die SE11. Beide Transaktionen sind in ECC und S/4HANA verfügbar.
1. BKPF — Der Belegkopf
Für wen: Berater, Key User, alle, die Buchungen analysieren oder nachvollziehen müssen.
Die BKPF ist die Kopftabelle jedes Finanzbelegs im SAP-System. Jede Buchung — ob manuell, automatisch oder per Schnittstelle — erzeugt einen Eintrag in der BKPF. Gespeichert werden dort die übergeordneten Informationen eines Belegs: Buchungskreis, Belegnummer, Geschäftsjahr, Belegdatum, Buchungsdatum, Belegart, Buchungsperiode und der erfassende Benutzer.
Die BKPF allein sagt noch nicht viel über den Inhalt einer Buchung — dafür braucht man immer das Gegenstück, die BSEG. Zusammen bilden sie das klassische Herzstück der FI-Datenhaltung in ECC.
Wichtige Felder
- BUKRS — Buchungskreis
- BELNR — Belegnummer
- GJAHR — Geschäftsjahr
- BLART — Belegart
- BUDAT — Buchungsdatum
- USNAM — Benutzername des Erfassers
Typische Verwendung
Prüfung von Belegdatum, Buchungsperiode, Belegart und erfassendem Benutzer — z. B. bei der Fehlersuche, im Rahmen von Audits oder zur Nachvollziehbarkeit automatischer Buchungen.
2. BSEG — Die Belegpositionen
Für wen: Berater, Entwickler, erfahrene Key User.
Während die BKPF den Kopf eines Belegs beschreibt, enthält die BSEG alle Einzelpositionen dazu — also die eigentlichen Buchungszeilen mit Konten, Beträgen, Kostenstellen, Steuerkennzeichen und Zahlungsbedingungen. Eine der größten und am häufigsten referenzierten Tabellen im SAP-System.
In klassischen ECC-Systemen ist die BSEG eine Cluster-Tabelle, was bedeutet, dass sie sich nicht direkt per SQL abfragen lässt — SAP stellt dafür eigene Lesetechniken bereit. In S/4HANA hat sich das zugrunde liegende Datenmodell grundlegend verändert: Die BSEG wird zwar weiterhin befüllt und bleibt für bestimmte FI-Beleginformationen relevant, für Auswertungen und Eigenentwicklungen sollte jedoch primär die ACDOCA herangezogen werden.
Hinweis für S/4HANA
In S/4HANA sollte für Reports und Analysen primär die ACDOCA verwendet werden (siehe Tabelle 3). Die BSEG bleibt technisch befüllt und ist für einzelne FI-spezifische Felder weiterhin relevant — sie ist jedoch nicht mehr die führende Datenhaltungsschicht.
Typische Verwendung
Analyse einzelner Buchungspositionen: Welches Konto wurde belastet? Welcher Betrag? Mit welchem Steuerkennzeichen? Welche Zahlungsbedingung ist hinterlegt? In ECC die Standardquelle für positionsgenaue Belegauswertungen.
3. ACDOCA — Das Universal Journal ⭐
Für wen: Berater, Entwickler, alle, die mit S/4HANA arbeiten.
Die ACDOCA ist die zentrale Tabelle des Universal Journal in SAP S/4HANA — und eine der bedeutendsten Änderungen im gesamten FI/CO-Datenmodell. Sie bündelt alle buchhalterischen und controlling-relevanten Einzelpostenpositionen in einer einzigen Tabelle: Hauptbuch, Nebenbücher, Kostenrechnung, Anlagenbuchhaltung — alles in einem Satz pro Belegposition.
Mit über 360 Feldern ist die ACDOCA deutlich breiter als alle ihre Vorgänger. Das erlaubt Auswertungen, die früher mehrere Tabellen-Joins erforderten, nun in einer einzigen Abfrage. Wer in S/4HANA Reports entwickelt oder Daten analysiert, kommt an der ACDOCA nicht vorbei.
Was die ACDOCA bündelt
- FI-Einzelpostenpositionen (in ECC u. a. in BSEG gehalten — BSEG bleibt in S/4HANA weiterhin relevant)
- CO-Einzelposten (in ECC: COEP)
- Anlagenbuchhaltung (in ECC: ANEK/ANEP)
- Profit-Center-Rechnung (in ECC: GLPCA)
- Ergebnis- und Marktsegmentrechnung (CO-PA)
Typische Verwendung
Grundlage für alle modernen FI/CO-Auswertungen in S/4HANA: Einzelpostenlisten, Abschlussanalysen, CO-PA-Reporting, Anlagenabschreibungen — alles aus einer Quelle, ohne Tabellen-Joins über mehrere Module hinweg.
4. BUT000 — Der Geschäftspartnerstamm ⭐
Für wen: FI-Berater, Stammdatenverantwortliche, alle, die mit S/4HANA migrieren.
Die BUT000 ist die zentrale Stammdatentabelle des Geschäftspartners in SAP — und in S/4HANA die führende Struktur für alle Debitoren- und Kreditorenstammdaten. Gespeichert werden dort die grundlegenden Daten eines Geschäftspartners: GP-Nummer, GP-Art (Person, Organisation, Gruppe), Name und zentrale Grunddaten. Adresszuordnungen erfolgen u. a. über BUT020 und ADRC.
Der Geschäftspartner ist in S/4HANA nicht optional — er ist Pflicht. Klassische Debitoren (XD01) und Kreditoren (XK01) gibt es als eigenständige Transaktionen nicht mehr. Die Stammdatenpflege läuft ausschließlich über die Transaktion BP, die Daten landen in den BUT-Tabellen und werden von dort über die Customer-Vendor-Integration (CVI) mit den klassischen Tabellen KNA1/KNB1 und LFA1/LFB1 synchronisiert.
Die wichtigsten BUT-Tabellen im Überblick
- BUT000 — Allgemeine Grunddaten des Geschäftspartners
- BUT020 / ADRC — Adressen des Geschäftspartners
- BUT100 — Geschäftspartnerrollen (z. B. Debitor, Kreditor, Kontakt)
- CVIS_EI_MAPP — CVI-Mapping zwischen GP-Nummer und Debitoren-/Kreditorennummer
Hinweis zur Migration
Die Geschäftspartner-Migration ist eine der häufigsten Stolperfallen in S/4HANA-Projekten. Nicht alle Debitor- und Kreditorenstammdaten lassen sich 1:1 überführen — fehlende GP-Rollen, Dublettenprobleme oder nicht synchronisierte Felder zwischen BUT- und KNA1/LFA1-Strukturen sorgen regelmäßig für Aufwand. Ein frühzeitiger Blick in die CVI-Mapping-Tabellen spart Zeit.
Typische Verwendung
Prüfung von GP-Grunddaten, Rollen und CVI-Mapping im Rahmen von Migrationsprojekten, Dublettenanalysen oder bei Fehlern in der Stammdatensynchronisation zwischen Geschäftspartner und klassischen Debitoren-/Kreditorenstrukturen.
5. KNA1 / KNB1 — Debitorenstamm
Für wen: FI-AR-Berater, Debitorenbuchhaltung, Key User.
Der Debitorenstamm ist auf zwei Tabellen aufgeteilt — ein Prinzip, das sich durch den gesamten SAP-Stammdatenbereich zieht. Die KNA1 enthält die mandantenübergreifenden Daten eines Debitors: Name, Adresse, Land, Sprache, Steuernummer. Die KNB1 enthält die buchungskreisspezifischen Daten: Zahlungsbedingungen, Mahnverfahren, Abstimmkonto, Zahlungswege.
Für Analysen, Datenmigrationen und die Geschäftspartner-Migration im Rahmen von S/4HANA-Projekten sind beide Tabellen unverzichtbar. In S/4HANA sind KNA1/KNB1 und LFA1/LFB1 über die Customer-Vendor-Integration (CVI) des Geschäftspartners synchronisiert.
Typische Verwendung
Abfrage von Kundenstammdaten für Massenauswertungen, Datenqualitätsprüfungen, Migrationsvorbereitung oder zur Analyse von Abstimmkonten und Zahlungsbedingungen über mehrere Buchungskreise hinweg.
6. LFA1 / LFB1 — Kreditorenstamm
Für wen: FI-AP-Berater, Kreditorenbuchhaltung, Key User.
Das genaue Pendant zum Debitorenstamm auf Lieferantenseite. LFA1 speichert die allgemeinen Lieferantendaten (Name, Adresse, Bankverbindung auf allgemeiner Ebene), LFB1 die buchungskreisbezogenen Daten (Abstimmkonto, Zahlungsbedingungen, Zahlungswege, Mahnverfahren).
Im Rahmen der S/4HANA-Migration werden Kreditoren- und Debitorenstammdaten in den Geschäftspartner überführt. Die Tabellen LFA1 und LFB1 bleiben technisch bestehen, die führende Stammdatenpflege erfolgt dann über die BP-Transaktion. Die Synchronisation zwischen Geschäftspartner und den klassischen Strukturen übernimmt die Customer-Vendor-Integration (CVI).
Typische Verwendung
Analyse von Lieferantenstammdaten: Bankverbindungen, Zahlungsbedingungen, Abstimmkonten. Häufig genutzt bei Datenqualitätsprüfungen vor einem Go-Live, bei der Vorbereitung von Zahlungsläufen oder im Rahmen von Lieferantenkonsolidierungen.
7. SKA1 / SKB1 — Sachkontenstamm
Für wen: FI-GL-Berater, Customizing, Abschlussteams.
Sachkonten haben in SAP ebenfalls eine zweigeteilte Stammdatenstruktur. SKA1 enthält die kontenbezogenen Grunddaten auf Kontenplanebene: Kontonummer, Kontenbezeichnung, Kontengruppe, Bilanz- oder GuV-Kennzeichen. SKB1 enthält die buchungskreisspezifischen Einstellungen: Feldstatusgruppe, Währung, Offene-Posten-Verwaltung, automatische Buchungskennzeichen.
Wer Sachkonten in großem Umfang anlegt, pflegt oder migriert, arbeitet fast zwangsläufig direkt mit diesen Tabellen — etwa beim Massenupload über LSMW oder beim Abgleich von Kontenplänen zwischen Systemen.
Typische Verwendung
Prüfung und Massenauswertung von Sachkontenstammdaten: Welche Konten sind im Buchungskreis aktiv? Welche Feldstatusgruppe ist zugeordnet? Welche Konten sind als Offene-Posten-Konten geführt? Unentbehrlich bei Kontenplananalysen und Migrationsvorbereitungen.
8. T001 — Buchungskreise
Für wen: Berater, Customizing, systemnahe Key User.
Die T001 ist eine der zentralen Customizing-Tabellen in SAP FI. Sie enthält alle im System definierten Buchungskreise mit ihren wesentlichen Einstellungen: Buchungskreisbezeichnung, Landeswährung, Kontenplan, Geschäftsjahresvariante, Buchungsperiodenvariante und Land. Wer mandantenübergreifende Analysen durchführt oder Systemeinstellungen prüft, schaut früher oder später in die T001.
Typische Verwendung
Überblick über alle aktiven Buchungskreise im System: Welche Landeswährung ist hinterlegt? Welcher Kontenplan gilt? Welche Geschäftsjahresvariante ist zugeordnet? Relevant bei Systemanalysen, Konzeptarbeiten und mandantenübergreifenden Projekten.
9. REGUP / REGUH — Zahlungslauf
Für wen: FI-AP/AR-Berater, Kreditorenbuchhaltung, Treasury.
Diese beiden Tabellen dokumentieren die Ergebnisse des automatischen Zahlungsprogramms (Transaktion F110). REGUH enthält den Zahlungskopf — also Informationen zum Zahllauf selbst: Datum, Zahlungsweg, Hausbank, Betrag. REGUP enthält die zugehörigen Einzelposten — also welche offenen Posten mit welchem Zahlungsbeleg ausgeglichen wurden.
Für die Analyse von Zahlungsläufen, die Fehlersuche bei nicht ausgeführten Zahlungen oder die Abstimmung mit der Hausbank sind diese Tabellen unverzichtbar.
Typische Verwendung
Nachvollziehen von Zahlungsläufen: Welche Belege wurden im letzten F110-Lauf bezahlt? Warum wurde ein bestimmter Beleg nicht berücksichtigt? Welche Hausbank wurde verwendet? Erste Anlaufstelle bei Rückfragen aus der Buchhaltung nach einem Zahllauf.
10. ANLA / ANLZ — Anlagenstamm
Für wen: FI-AA-Berater, Anlagenbuchhaltung, Abschlussteams.
ANLA ist die Kopftabelle des Anlagenstamms und enthält die allgemeinen, nicht zeitabhängigen Daten einer Anlage: Anlagennummer, Anlagenklasse, Buchungskreis, Bezeichnung, Aktivierungsdatum und Inventarnummer. ANLZ enthält die zeitabhängigen Stammdaten — also Daten, die sich über den Lebenszyklus einer Anlage ändern können, etwa Kostenstelle oder Standort, inklusive dem jeweiligen Gültigkeitszeitraum.
Wer Anlagenmigration, Jahresabschluss in FI-AA oder Abschreibungsanalysen macht, arbeitet direkt mit diesen Tabellen — ergänzt durch die Bewegungsdaten in ANEK und ANEP (in ECC) bzw. der ACDOCA (in S/4HANA).
Typische Verwendung
Massenauswertung von Anlagenstammdaten: Welche Anlagen sind in einer bestimmten Anlagenklasse? Wann wurden sie aktiviert? Welche Kostenstelle ist zum Stichtag X zugeordnet (ANLZ)? Grundlage für Migrationslisten, Inventurauswertungen und Abschlussanalysen.
Und was ist mit den anderen?
Natürlich gibt es viele weitere Tabellen, die je nach Schwerpunkt mindestens genauso relevant sind. Ein paar Kandidaten, die knapp nicht in diese Liste geschafft haben:
- T030 — Fixkonten (automatische Kontenfindung)
- BSIK / BSAK — Offene und ausgeglichene Kreditorenposten
- BSID / BSAD — Offene und ausgeglichene Debitorenposten
- COEP — CO-Einzelposten (in ECC, in S/4HANA durch ACDOCA ersetzt)
- FEBEP — Elektronischer Kontoauszug (Positionen importierter Bankauszüge)
Wenn Sie tiefer einsteigen möchten — in bestimmte Module, in die Unterschiede zwischen ECC und S/4HANA oder in die Frage, welche Tabellen für welche Auswertungsszenarien am besten geeignet sind: Das ist genau das, womit ich in Schulungen und Beratung arbeite.
SAP-Wissen, das im Alltag wirklich hilft
In meinen Schulungen für Anwender, Key User und Berater erkläre ich nicht nur was Tabellen enthalten — sondern wann und warum man sie braucht. Praxisnah, ohne Umwege.
Jetzt Kontakt aufnehmen →