FBL1N — Vendor Line Item Display

FBL1N is a display-only transaction that lists accounting line items posted to one or more vendor accounts within a company code, filtered by open, cleared, or all items. It does not post anything; it reads existing documents. The structural fact that drives most confusion is that open and cleared items historically live in separate tables, and a document moves from the open table to the cleared table only at the moment of clearing - so the same invoice can appear in completely different result sets depending on which status filter is chosen and which posting or clearing date window is applied. Special GL transactions (down payments, guarantees) are excluded from the default view unless explicitly included, which is the second most common source of apparently missing items.

Used constantly during accounts payable operations: confirming why a specific invoice has not been paid before a payment run, reconciling a vendor's open balance ahead of a statement request, investigating a dispute over an invoice or credit memo, and tying a vendor's line items back to the reconciliation account balance in the general ledger. It is the natural next step after FK10N shows a vendor balance total and someone needs to see the individual documents behind that total. For payment-run diagnostics specifically, it is checked before and after F110 to confirm which items were picked up or excluded. Fiori-based line item apps exist on S/4HANA but the classic transaction remains widely used because of its flexible layout and export options.

To confirm a specific claim from FBL1N against the raw data, run SE16 on BSIK for LIFNR and BUKRS matching the vendor and company code in question - any row found there is genuinely still open. If the item is expected to be cleared, check BSAK instead with the same filter and inspect the clearing document and clearing date fields. On S/4HANA the underlying source is ACDOCA, filtered by RLDNR (ledger), RACCT (reconciliation account), and the vendor's business partner or account number, cross-checked against the clearing document field to settle open-versus-cleared disputes.

The transaction itself is unchanged on S/4HANA and behaves the same way from the user's perspective. Underneath, BSIK and BSAK are no longer physical tables but compatibility views generated from the universal journal table ACDOCA, so any custom code or query reading them directly still works but any direct table-level analysis for troubleshooting should be cross-checked against ACDOCA for completeness. A Fiori app for managing vendor line items is available as a modern alternative, offering similar filtering with a different interface, but it does not replace FBL1N for consultants who rely on its layout variants and mass export.

Functional AP/FI territory almost exclusively. A good handover to Basis or ABAP only happens when the issue is a genuine performance timeout on a mass selection or a custom layout variant throwing a dump - in that case, hand over the exact selection screen values, the variant name, and the table volume involved rather than a screenshot of the error alone.

FK10N gives the summarized vendor balance that FBL1N's line items should sum to, and is the usual entry point before drilling into detail. FB60 is where most vendor invoices behind these line items originate, so understanding its posting logic explains what shows up here. F-53 and F110 are the clearing and payment-run transactions that move items from open to cleared, which is the single biggest source of FBL1N confusion. FK03 is useful alongside it to check the reconciliation account and payment terms on the vendor master when a balance mismatch traces back to master data rather than postings.