LFC1 table — Vendor Master Transaction Figures Table

One row in LFC1 represents the aggregated transaction figures for a single vendor within a single company code for a single fiscal year. It holds the balance carried forward from the prior year and a running cumulative balance for each posting period, including the special periods used for year-end adjustments. This table is a classic sum table, the same design pattern used for customer figures and general ledger totals, built to give fast balance reporting without scanning every open and cleared line item. It was the data source behind vendor balance display before line-item and Universal Journal based reporting became the norm, and it is still populated in many systems today as part of the classic totals update running alongside document posting.

Always restrict on MANDT, then on BUKRS and GJAHR before touching LIFNR, otherwise a full scan across every vendor and every year is triggered. The table itself is not large per vendor, but across a large vendor master and many fiscal years it adds up. UM01 through UM16 are cumulative, not deltas, so reading UM05 in isolation gives the balance up to and including period 5, not what moved during period 5; subtract the prior period value to get period movement. Remember figures are stored in company code currency, and possibly a parallel currency in a separate field set, so comparing against a report run in a different currency without conversion will look like a discrepancy that is not one.

Symptom: a vendor balance report total does not match what finance expects for a given year. Select LFC1 for that vendor, company code and fiscal year, take UMSAV plus the UM value for the current period, and compare it against the sum of open items in BSIK plus cleared items in BSAK for the same vendor and company code within the year. A clean match confirms the classic totals are still in sync with the sub-ledger. A mismatch points either to special G/L postings not included in the comparison or to postings that never fed the classic totals update.

LFC1 still exists as a table in S/4HANA for backward compatibility and continues to be readable by older reports and interfaces built against it. The Universal Journal in ACDOCA is now the source of truth for vendor balances, and current vendor balance display apps are built on CDS views that read from ACDOCA rather than from this classic totals table. Whether LFC1 is still actively updated for a given vendor and posting depends on which compatibility layer is active in that landscape; it should not be trusted as current without first checking that assumption against the actual posting flow.

The FI accounts payable or general accounting team that owns vendor sub-ledger reporting is first point of contact for a discrepancy involving this table. If the mismatch traces back to postings that bypassed the classic totals update, the conversation moves to whoever owns the Universal Journal migration or the classic/new reporting toggle for that landscape.

The vendor master tables holding the general and company code data referenced by LIFNR feed this table indirectly through posting; BSIK and BSAK hold the open and cleared line items that should reconcile against the balances stored here; KNC1 is the same aggregation applied to customers; a separate table exists for vendor special G/L transaction figures, which explains many apparent mismatches against LFC1 alone. Vendor balance display transactions such as FK10N read from this style of totals table historically, though in current systems they may be redirected to Universal Journal based sources.