KNBK table — Customer Bank Details
KNBK stores bank-account details associated with classic customer master records, such as customer number, bank country, bank key, bank account, and account-holder or control information. In S/4HANA customer bank information is maintained through Business Partner and synchronized to customer structures, so KNBK should be interpreted as part of that synchronized customer view rather than as an independent master.
A consultant-focused reference for KNBK covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 684 words
What it stores
KNBK stores bank accounts maintained for classic customer master records. Each row must be interpreted using the complete technical key and the application process that writes it. A consultant should first establish whether the row represents current state, a dated master-data slice, a document item, a history event, an index entry or a compatibility representation. Organizational levels, validity dates, fiscal years, ledgers, languages, statuses and sequence numbers are part of the grain whenever those dimensions exist. The table should be read as evidence of application behavior, not as an isolated spreadsheet. Confirm the owning business object and configuration before deciding that a value is wrong.
Key fields
Customer number and the bank country/key/account combination describe customer-side bank details. Multiple account entries can exist, so a report that assumes one row per customer can duplicate results.
- KUNNR — customer number.
- BANKS — bank country.
- BANKL — bank key.
- BANKN — bank account number.
- Bank control/account-holder fields — depend on country and process.
- Business Partner/CVI mapping — required S/4HANA ownership context.
How it joins the data model
Connect KNBK to the proper customer master and Business Partner mapping in S/4HANA. Preserve the customer and bank-identification dimensions when reconciling records; a bank account string is not a reliable stand-alone join key.
- KUNNR to KNA1
- BANKS and BANKL to BNKA
- customer to Business Partner through CVI_CUST_LINK in S/4HANA
How to read it safely
When a direct-debit or refund process selects the wrong account, inspect the configured customer master and payment method before recommending table edits. Confirm the account is authorized and current using business-supported maintenance tools.
How to prove it in the data
Take one reproducible example from the relevant SAP screen, report or application log. Record its full displayed key, organizational context, key date, language and status. Locate the matching KNBK row using those values, then follow the documented parent and child joins without dropping key components. Compare the result using the same key date and ledger. When values differ, test for leading-zero conversion, multiple validity slices, inactive history, parallel ledgers, fiscal-year boundaries, archived data and asynchronous replication. Save the read-only evidence before escalating. If the row is wrong, reproduce the maintenance path in a non-production system and route the fix to the application owner rather than changing the table.
ECC vs S/4HANA
S/4HANA uses Business Partner as the leading customer master. Customer bank details maintained in BP can be synchronized into classic customer tables including KNBK for compatibility and application use. Diagnose mismatches through BP/CVI before attempting direct customer-table correction.
Common pitfalls
- Selecting by one convenient identifier and silently mixing organizational units, years, ledgers, languages or validity periods.
- Joining on a partial key or descriptive value and creating duplicates that appear to be legitimate business rows.
- Ignoring inactive, deletion, reversal or status indicators and reporting retained history as current state.
- Assuming this table is authoritative without checking S/4HANA simplification, Business Partner synchronization, Universal Journal, MATDOC, CDS views or an external cloud source.
- Treating a missing row as proof that an event never occurred even though logging, replication, authorization and archiving scope can differ.
- Updating table rows directly instead of correcting data through the supported transaction, app, API or migration process.
Whose problem this is
Customer master governance and accounts receivable own the underlying bank instructions. FI configuration and payment processing teams own selection logic; ABAP owns extraction or integration mistakes evidenced by the trace.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/knbkERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.