KNC1 table — Customer Transaction Figures Totals Table

One row in KNC1 represents one customer, in one company code, for one fiscal year, with every FI line item posted against that customer's reconciliation account during the year rolled up into period buckets. Instead of storing individual documents, it carries accumulated debit and credit turnover per posting period and a balance carried forward from the previous fiscal year. It exists so that balance enquiries do not require summing thousands of open and cleared items on the fly; the periodic totals update alongside FI postings so the running balance is always available without a live aggregation. Screens like customer balance display and some dunning and credit history summaries read this table rather than the line item tables. It carries no reference to which specific document produced a given movement, only the accumulated figure by period.

Always restrict by MANDT, BUKRS and GJAHR at minimum; without KUNNR the read scans every customer in that company code for that year, which is expensive on a large customer base. The table is genuinely selective only when BUKRS, GJAHR and KUNNR are all supplied together, since that combination is effectively the primary key. A single period field is not the year's total; the annual figure requires summing the relevant period fields plus the carryforward, and special periods 13 through 16 need to be included when reconciling a year-end balance rather than a mid-year one.

Symptom: a customer's balance shown in the line item report does not match the figure shown in the customer balance display screen. Selection: read KNC1 for the given MANDT, BUKRS, KUNNR and GJAHR, sum the period fields up to and including the current period, add the carryforward, and compare that number against the sum of BSID and BSAD amounts for the same customer, company code and year. A mismatch points either to a totals update that fell out of sync with postings, or to documents posted against a different reconciliation account or company code than expected.

KNC1 belongs to the family of classic FI totals tables, alongside the general ledger and vendor equivalents, that the universal journal was built to replace as the single source of truth. Under S/4HANA the physical update-on-posting behavior for these totals tables is generally superseded, with the table kept available as a compatibility layer sourced from the universal journal so that older reports and custom code referencing it still return correct figures. Before writing new logic against KNC1 in an S/4 system, confirm on-site whether it is still a physically maintained table or a compatibility view, since the two behave differently for things like direct table locks or mass updates.

A discrepancy involving KNC1 is first a finance question, not a basis one: it lands with whoever owns accounts receivable reconciliation or period-end closing on the FI side. The FI technical consultant gets pulled in to determine whether the issue is a genuine totals-versus-line-item mismatch or simply a misread of which periods to sum; basis only gets involved if the underlying update process itself is failing.

BSID and BSAD hold the open and cleared line items that KNC1's totals are supposed to reconcile against. LFC1 is the structurally identical table for vendors. T001 supplies company code currency and control data used when interpreting the balances. Customer balance display and line item display transactions are the typical consumers, along with credit management screens that pull historical balance summaries; the actual updates to KNC1 come from ordinary FI posting transactions, not from any dedicated maintenance transaction.