T012 table — House Bank Definitions
T012 stores house-bank definitions for a company code. A house bank represents a bank relationship used by payment and cash-management processes and is identified by company code plus house-bank ID. The table describes the house bank itself; individual account IDs and G/L linkage are maintained separately and must be combined with bank master and bank-account governance data.
A consultant-focused reference for T012 covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 689 words
What it stores
T012 stores company-code-level house bank definitions used by payment, cash-management and bank-account processes. 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
Use the company code and house-bank identifier to locate the relevant house-bank configuration. The house bank is not itself proof that a particular payment account is configured or usable.
- BUKRS — company code.
- HBKID — house bank ID.
- Bank country and bank key — identify the external bank, usually linking to BNKA.
- Address or descriptive settings — characterize the house bank.
- T012K or Bank Account Management data — provides account-ID and account-level context.
How it joins the data model
Link T012 house-bank identifiers to the appropriate account-ID details in T012K, with company-code context. Check bank master and payment configuration rather than joining unrelated records on a bank key alone.
- BUKRS to T001
- BANKS and BANKL to BNKA
- BUKRS and HBKID to T012K for account IDs
How to read it safely
When automatic payments fail to select a bank, inspect house-bank assignment, bank-account ID, currency, payment method and the application's ranking/selection configuration. Validate the intended company code before changing the bank setup.
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 T012 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
T012 remains part of S/4HANA house-bank configuration, while Bank Account Management adds governance and account-master capabilities around individual bank accounts. Do not assume that a T012 house-bank row alone proves an operational bank account is fully configured.
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
FI payments and treasury own the business configuration; bank master governance supplies approved bank records, and Basis/security support is relevant only when access or environment evidence calls for it.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t012ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.