BSAK table — Cleared Vendor Line Items

Each row in BSAK is one vendor line item from BSEG that has reached clearing status, duplicated here with the clearing document attached. A single invoice line moves from BSIK into BSAK the moment it is matched against a payment or another offsetting document; the original document number, fiscal year, and line item stay the same, but AUGBL, AUGDT, and AUGGJ get populated with the clearing document, its posting date, and its fiscal year. BSAK is not a separate ledger of facts - it is a filtered, indexed copy of vendor-relevant BSEG rows, kept so that queries like 'what did we pay this vendor and when was it cleared' do not have to filter the entire BSEG table by account type and clearing status on every run.

Always restrict on MANDT implicitly through the system, then on BUKRS first - BSAK is not partitioned by anything more selective, and a company-code-only select on a large vendor ledger can still return millions of rows. Add LIFNR whenever the question is vendor-specific; it is the next most selective field after company code. If the question is about a clearing event rather than an invoice, filter on AUGBL plus BUKRS plus AUGGJ rather than scanning by BELNR, since one clearing document can clear many line items across many vendors. Avoid open-ended date ranges on BUDAT alone - combine with BUKRS and, where possible, BLART, or the read turns into a full table scan on a table that has no small footprint in any live system. Restricting purely on ZUONR or WAERS without BUKRS is a common way to make a five-minute query run for twenty minutes.

Symptom: accounts payable says an invoice was paid but the vendor claims otherwise. Select BSAK with BUKRS = the company code and LIFNR = the vendor and BELNR = the invoice document number. If a row exists, read AUGBL and AUGDT - that clearing document number and date is the payment or offset that closed the invoice. If no row exists in BSAK for that BELNR, the invoice is still open and belongs in BSIK, meaning the vendor's claim of non-payment may be correct and the finance team's belief that it was settled is wrong.

In S/4HANA, BSAK is implemented as a compatibility view rather than a physical table populated by its own update logic. The line item data is sourced from BSEG (and, for reporting, from the universal journal), with clearing status derived rather than stored redundantly the way ECC did it. Reads against BSAK still work and return the same shape of data, but the table is not being written to directly, and heavy custom code that assumed direct table buffering or database-level locking on BSAK should be revalidated during an S/4HANA move.

Accounts payable and general ledger accounting own the business meaning of what is cleared and why. Basis or the data/reporting team owns why a query against BSAK is slow. If a clearing date or clearing document looks wrong, it is an FI question first - reversed clearings, manual F-44-style resets, and payment program runs all write here differently, and someone who knows the process that cleared the item needs to look at the clearing document itself, not just the BSAK row.

BSIK holds the same vendor items while still open, and an item moves from BSIK to BSAK the moment it clears. BKPF and BSEG are the underlying document header and line item tables that BSAK indexes. REGUH and REGUP hold the payment proposal and payment run data that often generates the clearing document referenced in AUGBL; PAYR holds the payment medium record. LFC1 carries vendor balance totals used to reconcile against sums derived from BSIK and BSAK together.