FB50 — Enter G/L Account Document

FB50 creates a financial accounting document directly against general ledger accounts, presenting all line items in one editable grid rather than forcing a separate posting key and account entry per line the way FB01 does. The structural fact that explains most confusion: FB50 is a document-based transaction, meaning the debit and credit lines are entered together and must net to zero before the system allows posting, and every line can carry its own cost object, tax code and currency independent of the others. It internally maps each row to the standard debit (40) and credit (50) posting keys even though the user never sees them, which is why error messages sometimes reference posting keys the user never typed.

FB50 is reached for for anything that is not a subledger invoice: month-end accruals, reclassification entries between cost centers or accounts, correction postings, intercompany journal entries booked manually, and adjustments coming out of a reconciliation. Vendor invoices go through FB60, customer invoices through FB70, and payment postings through F-28 or F-53, because those carry subledger reconciliation logic FB50 does not enforce. In S/4HANA, the Fiori app for posting general journal entries covers the same use case with a similar single-screen grid, and many finance teams now reach for that app first and only fall back to FB50 for edge cases the app does not yet support.

Pull the header from BKPF filtered on company code, document type and posting date range, then join to BSEG on company code, document number and fiscal year to inspect the individual lines: debit/credit indicator, amount in local currency, G/L account, cost object fields, and tax code. To confirm a document was parked rather than posted, check the document status field on the header. In S/4HANA the same information sits on ACDOCA directly, which avoids the header-to-line join and shows both the entry view and the ledger-specific values in one table.

FB50 still exists and behaves the same way in S/4HANA GUI. What changed underneath is the persistence: postings land in ACDOCA as the single line-item table instead of being split across classic and New GL totals tables, with BKPF and BSEG retained as compatibility views for reports and interfaces that still expect them. The Fiori app for posting general journal entries offers the equivalent function with a comparable grid layout and is the direction SAP is pushing new users toward, but FB50 remains fully functional and is not deprecated.

Functional FI territory for entry errors, account assignment defaults and field status configuration. Basis gets involved only for authorization failures or period-control settings maintained centrally. A clean handover includes the company code, document number and fiscal year if one was created, the exact error message text, and whether the issue reproduces with a different G/L account or cost object.

FB01 is the older two-step equivalent and useful for understanding how posting keys work under the hood of FB50's grid. FB60 and FB70 handle vendor and customer invoices respectively and should be used instead of FB50 whenever the posting is a subledger transaction. FB08 is the correct way to reverse a document created in FB50 rather than posting a manual offset. FBV0 completes documents that were parked instead of posted. OB52 controls which posting periods are open and is the first stop when FB50 rejects a posting date.