KNB1 table — Customer Master Company Code Data

One row in KNB1 represents the accounting view of a customer for a single company code: the combination of KUNNR and BUKRS. It exists because a customer can be a legitimate business partner in one company code and completely unknown in another. The row carries the reconciliation account that ties the customer's open items into the general ledger, the payment terms and dunning procedure used for that legal entity, correspondence and tolerance group settings, and the posting and deletion blocks that FI applies at company code level. Without a KNB1 row for a given BUKRS, no financial posting can happen for that customer in that company code, regardless of what exists in KNA1 or KNVV. It is maintained through the customer master transactions and is the segment finance teams own, as opposed to the sales area segment which sales teams own.

Always restrict on MANDT and, in practice, on BUKRS before touching KNB1 in a wide report, since a large customer base multiplied by every company code can produce a large result set even though the table itself is not huge. KUNNR plus BUKRS together are unique and selective; querying by KUNNR alone across all company codes is fine for a single customer check but wrong for a mass report. Do not confuse SPERR (posting block) with the sales-side blocks stored in KNVV or on the sales order; they are independent and a customer can be fully open in one and blocked in the other.

Symptom: an invoice cannot be posted to accounting for a customer, error referencing a blocked or missing account assignment. Select KNB1 for that KUNNR and the BUKRS of the billing document's company code. Check SPERR for a posting block, LOEVM for a deletion flag, and AKONT for the reconciliation account; if the row does not exist at all for that BUKRS, the customer was never extended to that company code and that is the entire root cause, not a configuration issue elsewhere.

KNB1 continues to exist as a transparent table in S/4HANA and is still populated and read directly by much of the customer master logic. SAP's direction is to model the customer as a business partner with company-code data carried through the business partner's company code role, and reporting increasingly goes through compatibility views layered over KNB1 rather than the table being queried raw. For ABAP development and ad hoc analysis, selecting KNB1 directly still works and returns correct data.

The FI-AR or credit management team owns the content of KNB1, since it is company-code accounting data: reconciliation account, payment terms defaults, dunning setup and posting blocks. Sales or O2C consultants read it to explain why a customer cannot bill or post to a given company code, but changes to the row are made through the customer master maintenance owned by finance master data governance, not by SD configuration.

KNA1 holds the general, client-wide customer data that every KNB1 row depends on. KNVV holds the sales-area-specific data (sales org, distribution channel, division) that sits alongside KNB1 at a different organisational level for the same customer. VBRK and VBKD pick up payment terms and account assignment defaults that originate in KNB1 or KNVV when a sales document is created. Customer master maintenance transactions write KNB1 directly; sales order and billing transactions only read it.