FBL5N — Customer Line Item Display

FBL5N is a report, not a posting transaction: it reads accounting documents already sitting in the customer sub-ledger and presents them as open, cleared, or all items for a given customer or range of customers within a company code. It does not touch customer master data or credit management settings, only line items already posted to the account. The single structural fact that explains most confusion with this transaction is the special G/L indicator. Down payments, bills of exchange, and guarantees are posted with a special G/L transaction type and are excluded from the default customer item view unless that indicator is deliberately included in the selection screen. A customer balance that looks wrong is frequently just a balance that is incomplete for the selection made, not a posting error.

FBL5N is reached for whenever the question is about a specific customer's account history rather than a general ledger account: dispute resolution before a collections call, reconciling an AR aging report against the sub-ledger, checking whether a payment actually cleared an invoice, or confirming what open items exist before running dunning or a credit check. It sits downstream of sales order billing and payment application; nothing is posted from here. Consultants use FBL5N instead of FBL3N when the object of investigation is the customer, and reach for FAGLL03 instead when the investigation needs to cross into the general ledger view of the reconciliation account. On S/4HANA a Fiori line item app exists with similar filtering, but the classic transaction remains fully functional and is still the faster tool for ad hoc, keyboard-driven investigation.

To confirm a discrepancy, query BSID for open items or BSAD for cleared items filtered on the company code and customer number, and join BKPF on document number, company code, and fiscal year to bring in posting date and document type. Check the UMSKZ field on the line item to see whether a special G/L transaction exists that the user's selection excluded. On S/4HANA, run the same filter directly against ACDOCA using company code, customer, and the relevant posting date range, since BSID and BSAD are compatibility views over that table.

FBL5N still works on S/4HANA and behaves the same functionally. Underneath, it reads from the universal journal table through compatibility views rather than the separate BSID and BSAD tables, which keeps figures consistent with FI and CO since both now share one line item source. A Fiori app for customer line items offers additional filtering and a modern layout, but it does not replace the tcode; both are used depending on the consultant's habit and the client's rollout of Fiori. The special G/L indicator logic and the open/cleared/key date behavior are unchanged.

This is a functional FI/AR issue in almost every case: the fix is nearly always a selection screen adjustment, not a code or basis change. Escalate to basis only for an authorization trace or a genuine performance timeout on very large selections. A good handover states the customer, company code, date range, and exact selection options used, plus whether special G/L items were included, so the receiving consultant does not have to rediscover the selection that produced the confusing result.

Read FBL3N next to understand the equivalent report for general ledger accounts, useful when a customer sub-ledger total needs cross-checking against the reconciliation account. FAGLL03 covers the new general ledger line item view and is the right tool once the investigation needs to move from the sub-ledger into the ledger itself. FB03 is the natural drill-down from any single line item in FBL5N when the document detail, not just the line item summary, needs review.