FK10N — Vendor Account Balance Display

FK10N displays a vendor's account balance broken down by fiscal year and posting period, giving debit total, credit total and cumulative balance per period rather than a list of individual documents. It is the vendor-side counterpart to FS10N (G/L) and FD10N (customer). The structural fact that explains most confusion: the numbers shown come from the vendor totals record, an aggregated running-total object updated at posting time, not from a live sum of open and cleared items. When totals updates fall out of step with the item tables, or when special G/L transactions are excluded from the default view, the balance shown here can diverge from what a line item report or a manual sum would produce.

Used constantly in day-to-day accounts payable work: before releasing a payment run to check what is actually owed, during period-end close to spot balances that look wrong, when a vendor disputes an amount, and when reconciling vendor sub-ledger totals against the general ledger reconciliation account. A consultant reaches for FK10N first to get the periodic shape of the balance, then switches to FBL1N to see the actual documents behind a suspicious period. It sits upstream of F110 in the payment process and is a routine first stop in any vendor balance investigation, well before opening individual documents in FB03.

In SE16 on LFC1, filter by vendor number and company code and fiscal year to read the stored period totals directly. To verify those totals against reality, pull BSIK and BSAK for the same vendor and company code, filter by posting date falling in the period in question, and sum the amounts separately for debit and credit postings. If the LFC1 period total does not match the sum from BSIK plus BSAK for that period, the totals record is out of sync and needs a rebuild rather than a master data fix.

FK10N still exists and behaves the same on the surface on S/4HANA. Under the hood, the classic totals tables such as LFC1 and LFC3 are no longer the primary data source; balances are derived on the fly from the universal journal, with the totals tables kept largely for compatibility. A Fiori app for vendor line item and balance display is available as the modern equivalent, but FK10N remains fully usable and is still the fastest route for consultants used to the classic screen.

Functional FI-AP territory in almost every case; a mismatched balance is investigated by the accounts payable consultant, not Basis. Escalate to Basis only if authorization objects block company code or vendor visibility, or to ABAP if a custom totals rebuild program is required. A good handover states the vendor, company code, fiscal year, the period where the discrepancy appears, and the raw BSIK/BSAK figures already pulled.

FBL1N is the natural next stop for line item detail behind any period shown in FK10N. FK01, FK02 and FK03 cover the vendor master data that FK10N's display draws its structure from. FS10N and FD10N are the same balance display pattern applied to G/L accounts and customers, worth knowing side by side since the totals-versus-line-item discrepancy pattern is identical across all three. F110 is the payment run that consumes the open balance a consultant has just verified in FK10N.