Title here
Summary here
SAP FI Bank Master
SAP FI Bank Master
The Bank Master (BNKA) is a global master record that defines banking institutions used across all company codes. It stores bank identification (country-specific bank keys, SWIFT/BIC codes), address, and communication data. Unlike company-code-dependent masters, one Bank Master record serves the entire system — House Bank records later link specific company codes to these banks. This article covers the country-variant key structures, global data hierarchy, integration with payment processing, and FI-owned field details.
Part 1: Bank Master — Core Concepts (All Modules)
1.1 What Is the Bank Master?
The Bank Master is a reference record for banking institutions. It is not tied to any organizational level — one record per bank, used system-wide.
| Aspect | Details |
|---|---|
| Role | Centralized repository of bank identification and contact details; prerequisite for House Bank (company-specific bank accounts) and partner bank account assignment in Customer/Vendor masters |
| Modules using it | FI (House Bank setup, payment runs), MM (vendor payment methods), SD (customer refund/collection bank details), TR (cash management), RE (real estate payments) |
| Transactions | FI01 (Create Bank), FI02 (Change Bank), FI03 (Display Bank), FI04 (Bank → Company Code assignment display) |
| Key Tables | BNKA (Bank Master Data — country, key, name, address, SWIFT), T012 (House Bank — links BNKA to company code), TIBAN (IBAN structure rules) |
| S/4HANA note | Bank Master structure unchanged from ECC; SWIFT/BIC validation stricter in S/4HANA 2020+; Fiori app Manage Banks (F4242) available for mass creation/upload; payment integration with Multi-Bank Connectivity (cloud-based bank communication) replaces legacy EDI formats |
1.2 Bank Key Structure by Country
Bank keys vary by country. SAP uses the Bank Country + Bank Key combination as the unique identifier. Choosing the wrong format breaks payment file generation and SWIFT message routing.
| Country | Key Format | Code Length | Example | Key Behavior |
|—|—|—|—|
| Japan (JP) | Zengin Code | 7 digits | 0001234 | 4-digit bank code + 3-digit branch code; Zengin system routing; no spaces |
| USA (US) | Routing Number (ABA) | 9 digits | 021000021 | Federal Reserve routing; check processing; validated via ABA directory |
| Germany (DE) | Bankleitzahl (BLZ) | 8 digits | 10010010 | Deutsche Bundesbank registry; replaced by BIC in SEPA but still used internally |
| UK (GB) | Sort Code | 6 digits | 200000 | Two-digit bank + four-digit branch (format: XX-XX-XX); BACS/CHAPS routing |
| International | SWIFT/BIC | 8 or 11 alphanumeric | CITIUS33XXX | ISO 9362 standard; 8-char (bank) or 11-char (branch); mandatory for cross-border payments |
Design principle: Always populate both the country-specific Bank Key (for domestic routing) and the SWIFT/BIC code (for international payments). Missing either will cause payment file rejection or manual rework.
1.3 Organizational Levels and Data Hierarchy
Bank Master is not organization-dependent. It is created once and referenced by all company codes via House Bank records.
Global Level (System-Wide)
|
└── BNKA (Bank Master)
├── Bank Country + Bank Key (Unique ID)
├── Bank Name, Address, SWIFT/BIC
└── Control Data (Branch info, PO Box, etc.)
|
└── T012 (House Bank) — Company Code Level
├── House Bank ID (4-char, company-specific)
├── Bank Account ID (alphanumeric, internal)
└── G/L Account (company code chart of accounts)| Org Level | Table | Primary Fields | Notes |
|---|---|---|---|
| Global | BNKA | Bank Country (BANKS), Bank Key (BANKL), Bank Name (BANKA), SWIFT (SWIFT) | One record per bank; no company code filter; changes affect all users |
| Company Code | T012 | Company Code (BUKRS), House Bank ID (HBKID), Account ID (HKTID), Bank Country/Key (BANKS/BANKL) | Links BNKA to company code; one BNKA record → many T012 records; G/L account assigned here, not in BNKA |
| Payment | REGUH | Payment run uses T012 → BNKA chain | REGUH (Payment Header) reads House Bank → retrieves SWIFT/routing from BNKA for DME file generation |
Key design decision: Bank Master deletion is blocked if any House Bank record references it. Always check FI04 (Bank → Company Code Assignment) before attempting deletion.
1.4 Integration with Other Master Data Objects
Bank Master is the prerequisite for payment processing. It does not depend on other masters but is widely referenced.
| Object | Relationship | Practical Notes |
|---|---|---|
| House Bank (T012) | 1 Bank Master → N House Banks | Each company code creates its own House Bank ID pointing to the same BNKA record; required for outgoing payments (AP, payroll) and incoming receipts (AR, lockbox) |
| Vendor Master (LFA1/LFBK) | N Vendors → 1 Bank Master | Vendor bank account (LFBK) stores Bank Country/Key referencing BNKA; used in automatic payment runs (F110) to populate beneficiary bank in payment files |
| Customer Master (KNA1/KNBK) | N Customers → 1 Bank Master | Customer bank account (KNBK) stores Bank Country/Key; used for refunds, direct debits, and AR lockbox matching |
| Payment Medium Workbench (OBPM1) | Payment program reads BNKA via T012 | DME (Data Medium Exchange) configuration pulls SWIFT/BIC, IBAN, routing number from BNKA to generate SWIFT MT103, ACH NACHA, Zengin, or SEPA XML files |
Part 2: FI-Specific Field Details
2.0 Scope of FI Ownership
| Data Section | FI Involvement | Notes |
|---|---|---|
| Bank Identification | ◎ Owner | Bank Country, Bank Key, Bank Name — unique identifier; FI Administrator creates via FI01 |
| Address Data | ◎ Owner | Street, City, Region, Postal Code — required for payment advice letters and compliance reporting |
| Communication Data | ◎ Owner | SWIFT/BIC, Telex, Fax — critical for international payment routing and SWIFT message header |
| Control Data | ◎ Owner | PO Box, Bank Branch, Language Key — supplementary data for statement reconciliation and regional branches |
Legend: ◎ = Owner / Critical, ○ = Direct involvement
2.1 Bank Identification
Core fields that uniquely identify the bank and determine routing behavior.
| Field | Description | Practical Usage |
|---|---|---|
| Bank Country | ISO 3166-1 alpha-2 country code (2 characters, e.g., JP, US, DE) | Determines the Bank Key format and validation rules. Japan (JP) expects 7-digit Zengin code; USA (US) expects 9-digit ABA routing number. Mismatch between country and key format will cause payment file rejection. Set once at creation; cannot be changed if House Bank exists. |
| Bank Key | Country-specific bank identifier (format varies, see section 1.2) | Primary routing field for domestic payments. In Japan, this is the Zengin code used in Zengin format files sent to banks. In USA, this is the ABA routing number printed on checks. Must match the official registry (Zengin Center, Federal Reserve, etc.); wrong key → payment returned as “invalid routing.” |
| Bank Name | Full legal name of the bank (60 characters max) | Appears in payment advice, bank statements, and vendor correspondence. Use the official registered name, not marketing name. Example: THE BANK OF TOKYO-MITSUBISHI UFJ, LTD. not MUFG Bank. Some banks require exact spelling for SWIFT message acceptance; discrepancies trigger manual investigation. |
| Bank Branch | Branch name or location identifier (40 characters, optional) | Used in countries where bank key includes branch code (e.g., Japan Zengin: last 3 digits = branch). In multi-branch setups, this clarifies which physical location holds the account. Not used in SWIFT messages but helpful for statement reconciliation and audit trails. Leave blank for head office or single-branch banks. |
2.2 Address Data
Physical address of the bank, required for payment advice letters, tax reporting, and regulatory filings.
| Field | Description | Practical Usage |
|---|---|---|
| Street / House Number | Street address and building number | Required for compliance reporting in Japan (National Tax Agency filings require bank address on certain forms). Also printed on payment advice letters sent via postal mail. For large banks, use head office address unless a specific branch is designated in Bank Branch field. Some payment formats (e.g., SEPA Pain.001 XML) include bank address in creditor agent section. |
| City | City or municipality name | Appears in SWIFT MT103 field 57A (Beneficiary Bank) if SWIFT code is incomplete. Also used in NACHA ACH files (US) for Receiving Depository Financial Institution (RDFI) name/location. Must match the city registered with the central bank; mismatches can delay cross-border payment investigations. |
| Region | State/Province/Prefecture code (2-3 characters) | Critical for USA (state code like NY, CA) and Canada (province code like ON, BC). In Japan, use prefecture code (13 for Tokyo, 27 for Osaka). Payment run logs display region to help treasury teams identify bank location quickly. Not validated against central registries but must be consistent with City. |
| Postal Code | ZIP/postal code | Used in SEPA XML files (postal code element in creditor agent address). In Japan, 7-digit postal code format (123-4567) is enforced by payment file validators for Zengin Total Bank System. Wrong postal code does not block payment execution but may trigger compliance flags in audit reports. |
2.3 Communication Data
Contact details for payment routing, SWIFT messaging, and bank communication.
| Field | Description | Practical Usage |
|---|---|---|
| SWIFT Code / BIC | ISO 9362 Bank Identifier Code (8 or 11 alphanumeric characters) | Mandatory for cross-border payments. 8-character code identifies the bank (e.g., BOTKJPJT for Bank of Tokyo-Mitsubishi UFJ in Tokyo); 11-character code adds branch (e.g., BOTKJPJTOSA for Osaka branch). SWIFT messages (MT103, MT202) use this in field 57A (Beneficiary Bank). SAP validates BIC against downloaded SWIFT directory (table SWIFT_TAB). Wrong BIC → payment rejected by correspondent bank; common error when mergers/acquisitions change BIC but old code remains in SAP. Update immediately after bank merger announcements. |
| Telephone | Bank main switchboard or treasury contact number (international format recommended: +81-3-1234-5678) | Used by treasury team for payment investigation. If a payment fails or is delayed, this is the first number called. Not used in automated payment files but critical for manual follow-up. For large banks, enter the corporate treasury or correspondent banking desk number, not customer service. |
| Fax | Fax number (still used in Japan for payment confirmations and account opening) | In Japan, banks often send payment confirmation faxes after receiving Zengin files. Enter the fax number of the branch handling your account. In Europe/USA, fax is obsolete; leave blank unless bank specifically requests it for compliance documentation. |
| Telex | Legacy telex number (rarely used post-SWIFT) | Pre-SWIFT era field. Only populate if dealing with banks in countries with limited SWIFT access (e.g., some African or Central Asian banks). Modern payment systems ignore this field; kept for backward compatibility. If unsure, leave blank. |
2.4 Control Data
Supplementary fields for mail routing, regional handling, and reporting.
| Field | Description | Practical Usage |
|---|---|---|
| PO Box | Post office box number (optional) | Some banks prefer payment advice letters and account statements sent to a PO Box rather than street address. Common in USA and Australia. If the bank provides a PO Box on their letterhead, enter it here; SAP payment advice printing programs (e.g., RFFOUS_C for USA checks) read this field and format the envelope address accordingly. In Japan, rarely used (banks use street addresses). |
| Language Key | ISO 639-1 language code (2 characters: EN, JA, DE, etc.) | Determines the language of auto-generated payment advice letters and correspondence. If set to JA (Japanese), SAP prints payment advice in Japanese. If set to EN, prints in English. Does not affect SWIFT messages (always English). Useful in multilingual regions (e.g., Switzerland: DE, FR, IT) to match bank’s preferred correspondence language. |
| Bank Group | Grouping code for reporting (4 characters, optional) | Used in treasury reports (e.g., S_ALR_87012357 - Bank Master List) to categorize banks by type: CITY (city banks in Japan), RGNL (regional banks), FREX (foreign exchange banks), CRED (credit unions). Not used in payment processing; purely for internal reporting and KPI dashboards (e.g., “% of payments via city banks vs. regional banks”). |
| Bank Network | Network affiliation code (e.g., SWIFT, CHIPS, ZENGIN) | Indicates which payment network the bank participates in. Japan: ZENGIN (Zengin Network). USA: FED (Federal Reserve), CHIPS (Clearing House Interbank Payments System). Europe: SEPA (Single Euro Payments Area). This is informational metadata; payment programs read the Bank Country to determine the file format, not this field. However, it is useful for auditors and payment optimization projects (e.g., switching CHIPS payments to SWIFT to reduce fees). |
What to Read Next
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| fi-001 | Overview | What is SAP FI? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| fi-a01 | Overview | SAP FI Master Data: Overview, Hierarchy & Relationships |
| fi-a02-01 | Master Data | SAP FI Material Master |
| fi-a03-01 | Master Data | SAP FI Chart of Accounts |
| fi-a03-02 | Master Data | SAP FI G/L Account |
| fi-a04-01 | Master Data | SAP FI Payment Terms |
| fi-a04-02 | Master Data | SAP FI Tax Code |
| fi-a06-01 | Master Data | SAP FI Bank Master 📍 |
| fi-a06-02 | Master Data | SAP FI House Bank |
| fi-a07-01 | Master Data | SAP FI Asset Class |
| fi-a07-02 | Master Data | SAP FI Depreciation Key |
| fi-a07-03 | Master Data | SAP FI Asset Master |
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| fi-b01 | Overview | SAP FI Transactions: Process Flow, Hierarchy & Relationships |