FB01 — Post Document (General FI Posting)
FB01 is the generic FI document posting transaction. It lets a user build a document line by line using any posting key and account type, unlike FB50, FB60 or FB70 which pre-restrict the scenario. It is used for manual corrections, multi-line entries, and postings that the specialized single-purpose transactions cannot express.
FB01 is the raw, unrestricted document entry transaction in FI, requiring the user to select the posting key and account manually rather than relying on a preset scenario. This page covers when consultants reach for it over FB50/FB60/FB70, the tables the posting writes, and the diagnostic categories behind the most common posting failures.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,074 words
Purpose
FB01 posts an FI document by letting the user enter each line item separately, choosing the posting key, account, amount and account assignment for every line. It does not assume the document is a vendor invoice, a customer invoice, or a GL journal entry the way FB60, FB70 and FB50 do. The single structural fact that explains most confusion around FB01 is that it has no built-in business logic for a scenario; the posting key chosen on each line determines whether the line behaves as a debit or credit and which account type it can hit. Get the posting key wrong and the document either fails to balance or posts correctly to the wrong side of the ledger, with no warning from the transaction itself.
When it is used
FB01 sits underneath the specialized entry transactions in the FI posting landscape. Consultants reach for it when a document does not fit a single-object scenario: correction entries with more than two lines, cross-company postings, documents needing an unusual document type, or postings that combine GL, vendor and customer lines in one document. It is also used in training to show how posting keys drive account type and debit/credit behavior, and in testing to force a specific combination of document type, posting key and account that FB60 or FB70 would not offer directly. For routine vendor invoices, customer invoices or GL journal entries, FB60, FB70 and FB50 are preferred because they carry built-in checks (duplicate invoice check, simplified tax handling) that FB01 does not provide.
How to use it in practice
- Enter company code, document date, posting date and document type (SA for GL, KR for vendor invoice, DR for customer invoice, etc.)
- Set currency and exchange rate if the document is not in local currency
- Enter the first line: posting key, account number, amount, and any required cost object or tax code
- Add each subsequent line the same way until the document is balanced to zero
- Use Document then Simulate to preview the full posting before committing
- Post the document with the Post icon or Ctrl+S; note the assigned document number
Key data objects
- BKPF - document header: company code, document number, fiscal year, document type, posting date, entry date, user
- BSEG - line items: posting key, account, account type, amount, tax code, cost center, WBS, profit center
- BSIS - open items index for GL accounts managed on open item basis
- BSIK / BSAK - open and cleared vendor line items
- BSID / BSAD - open and cleared customer line items
How to prove it in the data
In SE16N, filter BKPF on company code (BUKRS), user name (USNAM) and posting date range to locate the document created through FB01. Take the document number, company code and fiscal year and look up BSEG to see the actual line items, checking posting key (BSCHL) and account type (KOART) against what was intended. If the complaint is a wrong account hit, compare KOART and the target account against the field status group and posting key definition rather than assuming master data is wrong.
ECC vs S/4HANA
FB01 is available unchanged on S/4HANA and continues to write directly to the universal journal underneath BSEG, which behaves as a compatibility view on later releases. The Fiori equivalent for manual journal entry is the general journal entry app, but FB01 remains fully supported as the classic transaction and many consultants continue to use it for the same correction and multi-line scenarios as on ECC.
Common pitfalls and how to diagnose them
- Balance not zero: the document will not post if debit and credit totals differ. Check for a missing tax line, an unposted rounding difference on foreign currency, or a forgotten offsetting line before assuming a system error.
- Wrong posting key selected: since FB01 has no scenario logic, a user picking the wrong key posts a technically valid but functionally wrong document (e.g. debit posted as a credit, or a GL line posted through a vendor-restricted key). Check BSCHL on the posted line against the posting key definitions for the intended debit/credit and account type.
- Document type restricts account types: some document types only allow certain account types on their lines; a posting that seems to silently reject an account is often a document type mismatch, not an authorization issue.
- Posting period closed: a hard stop referencing the fiscal year variant. Verify the open period range for that company code and account type before escalating as a program error.
- Field status group conflict: a field marked required in the field status group but left blank, or a field suppressed that a batch process is trying to fill, causing an error or a dump in interfaced postings.
- Validation or substitution rule blocking the entry: the error message can look generic; trace it back to the active validation rule rather than treating it as a core FB01 bug.
- No duplicate invoice check: unlike FB60, FB01 does not automatically flag a duplicate vendor invoice. Double postings of the same invoice through FB01 are a recurring root cause when users bypass the dedicated invoice transactions.
- Tax code determination issue: tax amount calculated incorrectly or rejected because the tax code is not maintained for the company code or jurisdiction on that line.
Whose problem this is
This is a functional FI issue in nearly every case: posting key selection, field status groups, document type restrictions and validation rules are configuration and process matters, not code. ABAP gets involved only when a batch input or interface program calling FB01 dumps. A good handover includes the document type, posting key, company code, and the exact error message text, plus whether the posting was manual or interfaced.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/fb01ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.