KNA1 table — Customer Master General Data
KNA1 holds the client-level general data of a customer master record: name, address pointer, country, language, tax numbers and central blocking flags. One row exists per customer number, independent of company code or sales area. Company-code-specific data lives in KNB1, sales-area-specific data in KNVV; KNA1 alone rarely tells the whole story about whether a customer can actually transact.
This page covers what a KNA1 row represents, which fields a consultant actually queries, and how the table joins into sales documents and address data. The pitfalls section focuses on the recurring mistake of reading a central block or deletion flag in KNA1 as the final word, when the real block often sits one level down in KNB1 or KNVV.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,153 words
What it stores
One row in KNA1 represents a single customer number at the general, client-independent level: the data that is true regardless of which company code or sales area is transacting with that customer. This includes the customer's name and search term, the pointer to the address record, country and region, language for correspondence, tax registration fields, and a small set of central control flags such as the overall deletion flag and central order or posting block. KNA1 does not carry pricing, credit, or shipping data, and it does not carry account-group-specific fields for a given company code or sales area. It is the anchor row that KNB1 and KNVV extensions hang off; without a KNA1 row the customer number does not exist in the system at all.
Key fields
- MANDT - client, part of every key, easy to forget when writing native SQL against the database directly
- KUNNR - customer number, the primary key and the join field to almost every downstream table
- NAME1 - customer name line 1, used in lists but unreliable for lookup due to duplicates
- LAND1 - country key, drives tax logic and address formatting downstream
- ORT01 / PSTLZ / STRAS - city, postal code, street, the basic postal address fields
- REGIO - region/state, relevant for tax jurisdiction determination in some countries
- SPRAS - language key used for correspondence and output determination
- KTOKD - account group, controls field status and number range at creation, cannot be changed later without a special conversion
- ADRNR - address number, the join key into ADRC for the full structured address
- STCEG - VAT registration number, often blank for purely domestic customers
- LOEVM - central deletion flag, a marker not an enforcement mechanism
- SPERR - central posting block, blocks the customer across all company codes
- AUFSD - central sales order block, blocks order creation across all sales areas
How it joins the data model
- KNA1-KUNNR = KNB1-KUNNR (company-code-specific data, one row per company code)
- KNA1-KUNNR = KNVV-KUNNR (sales-area-specific data, one row per sales org/distribution channel/division)
- KNA1-KUNNR = KNVP-KUNNR (partner function assignments held at customer master level)
- KNA1-ADRNR = ADRC-ADDRNUMBER (structured address detail, valid-from/to versions included)
- KNA1-KUNNR = VBAK-KUNNR (sold-to party stored redundantly on the sales document header for reporting)
- KNA1-KUNNR = VBPA-KUNNR (partner determined on an individual sales, delivery, or billing document)
How to read it safely
Always restrict on MANDT implicitly through the correct system logon rather than selecting across clients. KUNNR is the only field with real selectivity; selecting on NAME1 with a wildcard against the full table is a common source of runaway queries because the field is not the primary access path and duplicate names are common. When investigating a specific customer, always pull KNA1 together with KNB1 for the relevant company code and KNVV for the relevant sales area in the same session, because none of the three alone answers a transactional question. Do not attempt a full table dump for analysis; filter by KTOKD or a KUNNR range first if a broader extract is genuinely needed.
How to prove it in the data
Symptom: an order cannot be created for a customer, system says the customer is blocked. Select KNA1 where KUNNR equals the customer number and check AUFSD (central order block) and SPERR (central posting block). If both are blank, the block is not central; go to KNVV for that sales organization/distribution channel/division and check the sales-area-specific order and delivery block fields there instead. A block visible in KNVV but not in KNA1 is the normal case, not an anomaly.
ECC vs S/4HANA
KNA1 still exists in S/4HANA with the same key and largely the same field set. Under the business partner model, the customer master is maintained through the business partner transaction and synchronized into KNA1, KNB1, and KNVV via the customer/vendor integration mechanism running behind the scenes. Direct table content is technically still readable and joinable exactly as before, but the source of truth for maintenance has moved to the business partner object, and manual changes bypassing that synchronization are not supported.
Common pitfalls
- Reading LOEVM as blank and concluding the customer is fully active: the flag can be set at company code or sales area level in KNB1 or KNVV independently, and a blank flag in KNA1 says nothing about those levels
- Treating LOEVM as an enforcement mechanism: it is a marker checked by archiving and by some manual controls, it does not by itself prevent posting or order creation
- Assuming a customer exists for a given sales area because a KNA1 row exists: absence of a matching KNVV row means the customer has never been extended to that sales organization, and the sales document creation will fail on that basis alone
- Searching by NAME1 and treating the first hit as the correct customer: name fields are free text, duplicates across group companies and branches are routine, KUNNR is the only safe key
- Confusing the central block fields SPERR and AUFSD with the sales-area-specific order and delivery blocks that live in KNVV: these are different fields with different scope and are checked at different points in document processing
- Assuming the address on the document matches KNA1/ADRC at the moment of reading: sales documents can carry a manually overridden or time-sliced address captured at creation time, independent of subsequent master data changes
- Treating STCEG as mandatory: it is legitimately blank for many domestic-only customers and its absence is not itself a data error
- Forgetting that one-time customer account groups reference a shared dummy KNA1 record, with the actual name and address entered per document in VBPA/partner data rather than in KNA1 itself
Whose problem this is
Customer master data quality is normally owned by a master data governance or SD master data team, not by basis or by the technical SD configuration team. Central blocks and account group setup are a data governance decision; sales-area extension and area-specific blocks are usually a joint call between the SD process owner and the credit/collections function.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/kna1ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.