SAP AP Aging Report: AP Open Items + Aging

What this report answers

PostNow.ai's AP Open Items + Aging (FICO-12) is the list AP and treasury pull before every payment run and every month-end close. It is built to answer:

• How much do we owe each vendor, per company code, and how much of it is already past due at the key date?
• What falls due before the next payment run, and what is held back by a payment block?
• Which balances are down payments or other special G/L items that do not belong in the trade payables aging?
• Which items are old enough that someone should look for a dispute, a missing goods receipt or a duplicate?

You get one row per open item: vendor and name, document number, type and dates, baseline date, payment terms, cash-discount days, amounts in local and document currency, debit/credit indicator, special G/L indicator, payment block, reconciliation account and payment methods. The 0–30 / 31–60 / 61–90 / 90+ buckets are not calculated for you: you set the key date and derive them in Excel, so the intervals stay your own.

FBL1N and S_ALR_87012078: the SAP standard way, and where it stops

PostNow.ai reads the same open-item data that the standard AP reports sit on, so it is worth knowing what those reports already give you. FBL1N (Vendor Line Item Display) lists open items at a key date, cleared items or all items, and you tick which item types to include: normal items, special G/L transactions, noted items, parked items. It is the right screen for checking one vendor. For aging, most teams run S_ALR_87012078, Due Date Analysis for Open Items, which groups open vendor items by due date.

Both give you a list, not a data set. Getting FBL1N into a pivot means one export per company code, a layout that a colleague may have changed, and amounts whose signs you have to fix. The due date analysis shows totals per interval but not the items behind them, and new intervals mean a new run.

SAP tables behind it: BSIK, BSAK and the due date fields

PostNow.ai's FICO-12 joins five tables: BSIK for the open items, LFA1 for vendor name and country, LFB1 for the company-code data (reconciliation account AKONT, payment methods ZWELS), T003T for the document type text and T001 for the company name.

• BSIK vs BSAK. BSIK is the secondary index of open vendor items. When an item is cleared it moves to BSAK. BSIK therefore always means “open as of now”, whatever key date you have in mind.
• Due date fields. ZFBDT is the baseline date, ZTERM the terms key, ZBD1T and ZBD2T the days for the first and second cash discount, ZBD3T the net payment period. SAP calculates the net due date from the baseline date plus those days (function module DETERMINE_DUE_DATE). The report delivers ZFBDT, ZTERM and ZBD1T; if your terms carry a net period (2% in 14 days, net 30), have a designer add ZBD2T and ZBD3T in the visual builder before you calculate due dates.
• S/4HANA. BSIK and BSAK are no longer physical tables. Same-name compatibility views read the items from BSEG and ACDOCA, and both of those carry the field NETDT (due date for net payment).

Checks to run before you trust the aging

1. Key date vs today. An item open on 30 September but paid on 3 October has already moved to BSAK. A September aging pulled from BSIK in mid-October is therefore short. For a true period-end aging, run FBL1N at that key date, or add the BSAK items cleared after the key date, and in both cases keep posting date ≤ key date.
2. Signs. Amounts are stored unsigned and the debit/credit indicator carries the direction: H (credit) is the normal invoice side for a vendor, S (debit) is a payment on account or a credit memo. Build a signed column before you sum, or credit memos inflate the balance.
3. Special G/L items. Down payments and similar items carry a value in Sp GL Ind and post to their own reconciliation account. Filter them out of the trade aging and report them on their own line.
4. Credit memos. A credit memo with no invoice reference is due on its baseline date, so it ages from day one whatever the terms say. With “V” in the invoice reference field the terms apply as for an invoice.
5. Payment blocks. A blocked item is open and may be overdue, but the payment run (F110) will not pay it. Split the overdue buckets into blocked and payable before treasury sees them. Invoices held by invoice verification carry payment block R; the SAP invoice matching guide covers the tolerance checks that set it.
6. Currency. Bucket on Amount (LC) within one company code and only add company codes together when they share a local currency. Use Amount (DC) when you talk to the vendor.

How PostNow.ai runs it

In PostNow.ai you open AP Open Items + Aging from the Report Library in the Excel add-in and set the selection with SAP value help: company code, vendor, fiscal year, posting date, baseline date, document number, document type and reconciliation account. The joined rows land in your sheet, read-only in your own SAP session. A max-rows guard keeps the first run small; once the selection is right, widen it and refresh, and the report keeps your filters. Save it to My Reports or share it to Team Reports so the same selection runs at every close. Operators run library reports as delivered; adding columns such as ZBD3T is a designer task. For the vendor documents behind a balance, see GL Line Items 360; the customer side is AR Open Items + Aging 360. For the AP process around the payment run, see SAP accounts payable automation.