FB70 — Post Customer Invoice in FI

FB70 posts a customer invoice straight into Financial Accounting: it debits the customer's reconciliation account and credits one or more G/L accounts entered manually on the same screen, with tax calculated if a tax code is supplied. It is the enjoy-transaction wrapper around the older FB01 general posting screen, with the posting keys for the customer debit (typically 01) and the offsetting credit already defaulted so the user only sees customer data, amount and G/L lines. The structural fact that explains most confusion: FB70 has no awareness of Sales and Distribution. There is no sales order, no delivery, no billing document, no pricing procedure and no output determination behind it. Anyone expecting revenue recognition, credit management updates driven by SD, or a billing document number to reference later will not find one, because none was created.

FB70 is reached for when the receivable does not come out of a sales process: intercompany invoices, interest or penalty invoices, manual corrections to a customer balance, one-off invoices in a company code that has no SD implementation, or data conversion loads during a cutover. It is also common in support work to raise a small test invoice quickly without building an SD order. It sits alongside FB60 (vendor invoice) and FB75 (customer credit memo) as one of the three enjoy transactions for direct AR/AP postings. In an SD-integrated business process, the invoice should come from a billing document (VF01/VF02) instead, which posts to FI automatically through account determination; using FB70 there duplicates or bypasses that flow and breaks reconciliation between SD and FI.

Start in SE16 on BKPF filtered by company code and a date range, looking for the document type used for direct customer postings (commonly DR or a client-specific variant). Take the BELNR, BUKRS and GJAHR and pull the matching rows from BSEG. The customer line has KOART equal to D; check the KUNNR, DMBTR/WRBTR amount, and SHKZG (debit/credit indicator) match what was entered. Cross-check BSID for that customer and document number to confirm the item is still open, or its absence to confirm it has already cleared.

FB70 still exists and functions the same way on S/4HANA. The underlying posting now writes into the universal journal (ACDOCA) alongside the classic tables, and document splitting is active by default, which is why missing account assignments surface as splitting errors rather than silent postings. A Fiori app for creating supplier and customer invoices covers the same use case with a modern interface, but the tcode is not deprecated and remains the faster route for consultants who need to see posting keys and tax detail directly.

Functional AR/FI territory. A good handover includes the document number, company code, the posting keys and tax code used, and whether the failure happened on entry, simulation or posting. ABAP gets involved only if a substitution, validation or BAdI is suspected of altering the posting; Basis is relevant only for authorization or number range lock issues.

FB60 is the direct parallel on the vendor side and worth comparing to understand the mirrored posting keys. FB75 covers the customer credit memo variant of the same enjoy-screen logic. FB08 is the reversal transaction for anything posted incorrectly through FB70. F-28 is where the resulting open item gets cleared against an incoming payment, which is the natural next step to trace once the invoice is confirmed in BSID. FD10N is useful for checking the customer's balance and open items after posting without going into table-level detail.