SAP-TabelleObjektBKPFModulFI_FICO

Tabelle BKPF — Kopfdaten des Buchhaltungsbelegs

BKPF speichert die Kopfdaten von Finanzbuchhaltungsbelegen, indiziert nach Buchungskreis, Belegnummer und Geschäftsjahr. Sie enthält Belegart, Buchungs- und Belegdaten, Erfassungsbenutzer/-zeit, Referenz, Währung und Stornierungskontext, während die Kontierungen und Beträge der Einzelposten in BSEG und ACDOCA gespeichert sind. In S/4HANA bleibt BKPF eine reale Belegkopf-Tabelle.

BKPF ist die Kopftabelle hinter jedem FI-Buchhaltungsbeleg, eine Zeile pro Beleg, unabhängig von der Anzahl der enthaltenen Einzelposten. Diese Seite behandelt die wichtigsten Kopfdatenfelder, wie man sich mit BSEG und verwandten Tabellen verbindet und welche wiederkehrenden Fehler Berater beim Lesen des Stornierungsstatus, der Daten und der Referenzschlüssel aus dieser Tabelle machen.

Veröffentlicht am 20. Sept. 2026· 1.136 Wörter

Was sie speichert

Eine Zeile in BKPF stellt einen einzelnen Buchhaltungsbelegkopf dar, der immer dann erstellt wird, wenn eine FI-Buchung vorgenommen wird, sei es durch einen G/L-Journalbuchung, eine eingehende Rechnung, eine Fakturabelegübertragung oder einen Zahlungslauf. Der Kopfdatensatz enthält die administrativen und steuernden Daten für diesen Beleg: zu welchem Buchungskreis und Geschäftsjahr er gehört, welche Belegart verwendet wurde, wer ihn erfasst hat und wann, das Buchungs- und Belegdatum, die Währung, eine freie Referenz und ob der Beleg inzwischen storniert wurde. Sie enthält keine monetären Beträge oder Kontierungen; diese befinden sich auf Einzelpostenebene. Ein Beleg mit einer Soll- und einer Haben-Zeile oder mit fünfzig Zeilen, die auf Kostenstellen und Steuercodes aufgeteilt sind, erzeugt immer genau eine BKPF-Zeile.

Schlüsselfelder

MANDT - Mandant
BUKRS - Buchungskreis
BELNR - Buchhaltungsbelegnummer, nur eindeutig in Kombination mit BUKRS und GJAHR
GJAHR - Geschäftsjahr
BLART - Belegart, steuert Nummernkreis und erlaubte Kontenarten
BLDAT - Belegdatum, das auf dem Quellbeleg gedruckte Datum
BUDAT - Buchungsdatum, bestimmt die Buchungsperiode
MONAT - Geschäftsperiode, abgeleitet vom Buchungsdatum
CPUDT - Erfassungsdatum, das Datum, an dem der Beleg in das System eingegeben wurde
USNAM - Benutzer, der den Beleg erstellt hat
TCODE - Transaktionscode, der zum Buchen verwendet wurde
WAERS - Belegwährungsschlüssel
XBLNR - Referenzbelegnummer, oft die Lieferantenrechnungsnummer oder externe Referenz
BKTXT - Belegkopftext
AWTYP - Referenzvorgang, der die Art des ursprünglichen Geschäftsobjekts identifiziert
AWKEY - Referenzschlüssel, der auf das ursprüngliche Objekt zurückverweist, z.B. einen Fakturabeleg oder ein Logistikdokument
STBLG - Nummer des Stornobelegs, wird ausgefüllt, sobald der Beleg storniert ist
STJAH - Geschäftsjahr des Stornobelegs

Wie es sich in das Datenmodell einfügt

BKPF-BUKRS/BELNR/GJAHR = BSEG-BUKRS/BELNR/GJAHR, um die einzelnen Soll- und Haben-Zeilen zu erreichen
BKPF-BUKRS = T001-BUKRS, um Buchungskreisattribute wie Währung und Kontenplan aufzulösen
BKPF-BLART = T003-BLART, um die Belegartkonfiguration und die erlaubten Kontenarten zu überprüfen
BKPF-BUKRS/BELNR/GJAHR = BSET-BUKRS/BELNR/GJAHR, um die Steuerpositionen für diesen Beleg zu erreichen
BKPF-AWTYP/AWKEY wird verwendet, um zum ursprünglichen Geschäftsbeleg, z.B. einem Fakturabeleg oder einer Warenbewegung, zurückzuverfolgen, wenn der Kopfdatensatz durch eine Integrationsbuchung und nicht durch manuelle Erfassung erstellt wurde

Wie man es sicher liest

Beschränken Sie die Auswahl immer implizit auf MANDT und explizit auf BUKRS plus GJAHR, bevor Sie etwas anderes tun; diese beiden Felder tragen die echte Selektivität für diese Tabelle. BELNR allein ist bedeutungslos, da Belegnummernkreise pro Buchungskreis vergeben werden und sich über Buchungskreise und Jahre hinweg wiederholen können. Wählen Sie nicht über alle Buchungskreise auf BUDAT oder CPUDT, ohne zuvor mindestens einen Buchungskreisbereich anzugeben; die Tabelle wächst über die Lebensdauer eines Systems unbegrenzt, und ein uneingeschränkter Datum-Bereichs-Scan ist eine häufige Ursache für einen feststeckenden Hintergrundjob oder eine blockierte Dialogsitzung. Wenn Sie nach Benutzer oder Erfassungsdatum über viele Buchungskreise suchen, erwarten Sie eine lange Laufzeit der Abfrage, es sei denn, ein geeigneter Index unterstützt sie.

Wie man es in den Daten nachweist

Symptom: Eine Kunden- oder Lieferantenposition wird als noch offen gemeldet, obwohl jemand behauptet, der Beleg sei storniert worden. Selektieren Sie BKPF nach BUKRS, BELNR, GJAHR für den ursprünglichen Beleg und prüfen Sie STBLG und STJAH. Sind beide Felder leer, existiert keine Stornierung, unabhängig davon, was dem Unternehmen mitgeteilt wurde. Sind sie gefüllt, nehmen Sie dieses STBLG/STJAH-Paar, suchen Sie den BKPF-Satz des Stornobelegs, um zu bestätigen, dass er erfolgreich gebucht wurde, und prüfen Sie dann BSEG für beide Belege, um zu bestätigen, dass die Ausgleichsfelder tatsächlich für die offene Position gesetzt wurden und nicht nur ein Stornobeleg existiert.

ECC vs. S/4HANA

BKPF bleibt eine Datenbanktabelle in S/4HANA und wird für Journalbuchungen gefüllt. ACDOCA liefert die Einzelposten des Universal Journals, während BSEG auch für die operative Buchhaltungsbeleg-Erfassungssicht eine Datenbanktabelle bleibt; SAP erklärt explizit, dass es keine Kompatibilitätssicht für BSEG gibt. Wählen Sie BSEG oder ACDOCA entsprechend den erforderlichen Geschäfts- und Ledger-Details.

Häufige Fallstricke

Versuch, Beträge aus BKPF zu summieren. Es gibt keine. Jeder Betrag, Soll oder Haben, lokale oder Belegwährung, befindet sich in BSEG oder dem Universal Journal, nicht im Kopf.
BELNR als alleinigen eindeutigen Schlüssel behandeln. Er ist nur innerhalb von BUKRS und GJAHR eindeutig; dieselbe Nummer kann in mehreren Buchungskreisen oder Geschäftsjahren für völlig unabhängige Belege existieren.
Annehmen, dass ein gefülltes STBLG bedeutet, dass die ursprünglichen Buchungen entfernt wurden. Eine Stornierung erstellt einen neuen Beleg und aktualisiert den Ausgleichsstatus der Einzelposten; der ursprüngliche Beleg und seine Zeilen bleiben in BSEG, jetzt als ausgeglichen gekennzeichnet, nicht gelöscht.
Verwechslung von BUDAT, BLDAT und CPUDT. Die Periodenfindung und Periodenabschlussprüfungen basieren auf BUDAT. Das Lesen von BLDAT, wenn die Frage ist, in welcher Periode ein Beleg gelandet ist, führt zu einer falschen, aber plausibel aussehenden Antwort.
Manuelles Dekodieren von AWKEY in Erwartung eines sauberen Fremdschlüssels. Das Format des Referenzschlüssels verkettet eine Objektkennung mit einem Geschäftsjahr auf eine für den in AWTYP genannten Referenzvorgang spezifische Weise, und die Behandlung als einfache Belegnummer führt zu falschen Übereinstimmungen.
Annahme, dass eine BKPF-Zeile einer Transaktion entspricht, wie der Business User sie versteht. Eine einzelne Rechnungseingabe kann mehr als einen Buchhaltungsbeleg generieren, z.B. einen separaten buchungskreisübergreifenden Beleg, und diese sind durch gemeinsame Referenzdaten und nicht durch eine einzelne BELNR verknüpft.
Ausführen einer uneingeschränkten Selektion gegen BKPF in einem Produktivsystem in der Erwartung, dass sie sich wie eine kleine Stammtabelle verhält. Es ist eine der größten Tabellen in einem ausgereiften FI-System, und ein uneingeschränktes Lesen ist eine häufige Ursache für eine Amok laufende Abfrage.

Wessen Problem dies ist

Fragen, warum ein bestimmter Beleg so aussieht, wie er aussieht, falsche Belegart, falsches Buchungsdatum, fehlende Stornierung, liegen beim funktionalen Team der FI- oder GL-Buchhaltung, nicht bei Basis. Performanceprobleme, die durch uneingeschränkte Lesevorgänge auf BKPF im Produktivsystem verursacht werden, sind ein Anliegen von Basis- und ABAP-Entwicklung, die sich normalerweise durch einen langlaufenden Job oder eine Eskalation des Datenbankteams und nicht durch ein funktionales Ticket äußern.