Anyone can name a T-code. A consultant can read the posting.

In Financial Accounting, every argument ends at the document. Not at the design slide, not at the config screenshot — at the rows SAP actually wrote. So this page does the one thing a static reference cannot: it posts a document in front of you, then opens every table it touched and explains every column.

Pick a business event, set the configuration a consultant actually owns, and press Post. The number range assigns a document number, the database writes fill in one by one, and five tables appear with their real field names. Then click any column header — you get what the field is, where its value came from (user entry, master data, configuration, or derived by SAP), and why it matters when something goes wrong.

One posting. Five tables. Each answers a different question.

A new consultant's most common mistake is looking for everything in one table. An FI document is deliberately spread across five, because five different readers need it — the accountant, the auditor, the tax authority, the controller and the subledger.

The open- and cleared-item tables you may know from ECC — BSIK/BSAK (vendor), BSID/BSAD (customer), BSIS/BSAS (G/L) — still answer queries in S/4HANA, but they are now views over ACDOCA, not separate stores.

The header: the facts that apply to the whole document.

BKPF is small and boring until something is wrong — then it is the first place you look, because almost every "why did it post like that?" question traces back to a header field.

The key is three fields: BUKRS + BELNR + GJAHR — company code, document number, fiscal year. Document numbers are only unique within a company code and year, which is why every FI table repeats all three.

What each group of header fields is for

Open any document with FB03 and read the header before the lines. Ninety percent of "wrong posting" tickets are a wrong posting date, a wrong document type, or a wrong exchange rate — all three are header fields.

The entry view: what the user actually typed.

BSEG holds the document as it was entered — before document splitting, one row per line, with the posting keys that decided debit, credit and account type.

Two fields do most of the explaining:

Amount fields come in pairs: WRBTR in document currency and DMBTR in local currency, with MWSTS for the tax portion. Clearing adds AUGBL (the clearing document) and AUGDT — an open item is simply a line where those are empty.

The Universal Journal: one table, every dimension.

S/4HANA's defining change. Where ECC kept FI in BSEG, CO in COEP, assets in ANEP and the material ledger elsewhere — and reconciled them nightly — S/4HANA writes one row carrying all of it.

The consequence is practical: a cost-centre report and a G/L balance can no longer disagree, because they read the same row. The reconciliation job that used to exist has nothing left to do.

The key, and why it has five parts

RLDNR + RBUKRS + GJAHR + BELNR + DOCLN — ledger, company code, year, document, line. The ledger comes first because the same posting exists once per ledger. Forget RLDNR = '0L' in a SE16N query and every amount you see is multiplied by the number of ledgers.

Field families

Amounts in ACDOCA are signed; amounts in BSEG are not. That single difference is behind a surprising number of custom-report defects: logic ported from ECC keeps reading SHKZG, which ACDOCA does not need, and flips half the lines.

The tax lines: what the VAT return actually reads.

One row per tax code per document. Not per line item — per tax code. Three expense lines sharing one tax code produce one BSET row with the summed base.

The amount fields come in pairs, once per currency, and the naming is worth memorising because every tax report in SAP uses it:

Alongside them: MWSKZ the tax code, KTOSL the account key that sent it to a G/L account, KSCHL the condition type from the tax procedure, KBETR the rate as applied, and HKONT the account it landed in.

The standard VAT return report is RFUMSV00 (S_ALR_87012357). It reads BSET. If a tax amount is missing from the return but visible in the G/L, the posting reached BSEG without reaching BSET — usually a tax code with no condition record or a manual posting to a tax account.

Withholding tax: a separate engine, a separate table.

VAT and withholding tax are often spoken of together and configured nowhere near each other. VAT is a tax code on a line. Extended Withholding Tax is its own engine, keyed by type and code, writing to its own table.

The key is BUKRS + GJAHR + BELNR + BUZEI + WITHT — note the last part: one row per withholding type on the line. A vendor subject to two types produces two rows on the same line.

Type versus code — the distinction that matters

Amount fields follow the same per-currency pattern as BSET: WT_QSSHB/WT_QBSHB base and tax in document currency, WT_QSSHH/WT_QBSHH in local currency 1, then …SH2 / …SH3 for further currencies. QSREC carries the recipient type and CTNUMBER the certificate number.

Reporting runs through RFIDYYWT — Generic Withholding Tax Reporting (S_P00_07000134). One selection screen produces forms, lists and e-filing files; which of them you get is decided by the output group, not by the selection. A report that "runs but produces nothing" is usually the wrong output group.

Document splitting: the same document, told twice.

Turn on splitting in the workbench and the row count changes. Nothing was posted twice — you are looking at the second view of one document.

A user enters an expense against a profit centre and a vendor line with none; the vendor is a balance-sheet account and carries no reporting dimension of its own. Document splitting pushes the characteristics of the P&L lines onto the balance-sheet lines, in proportion to the amounts, so that a balance sheet can be produced per profit centre or segment.

In FB03, always choose the General Ledger View and name the ledger before discussing segment or profit centre. Arguing about dimensions from the entry view is arguing about a document that does not exist in the ledger.

Every line carries several amounts — and all of them must balance.

Switch the workbench to USD and watch a second and third amount column come alive. S/4HANA stores up to ten currencies per line; most implementations use three.

Each amount is converted at the moment of posting using a rate from TCURR, selected by rate type (KURST, commonly M for average) and valid-from date (GDATU, which is stored inverted — a detail that has broken many a custom report). Maintain rates in OB08.

Rates are set at posting and then frozen. Period-end foreign-currency valuation (FAGL_FCV) does not change them — it posts additional lines for the difference on open items. So an open item legitimately shows an old rate; the revaluation sits beside it, not on it.

Nothing on a line is typed. Trace any field to the node that decides it.

This is the table a consultant actually works from. Read it right to left: a field on the document, the thing that determines it, and the IMG node or transaction where you change it.

Two of these are worth internalising because they are asked at interview: a tax code belongs to a country, not a company code (OBBG), and the account key, not the user, chooses the tax account (OB40).

How to read any FI document in sixty seconds.

The same order, every time. It works because it moves from the facts that apply to the whole document down to the line that is actually wrong.