BNKA table — Bank Master Data Table

One row in BNKA represents a single bank, identified by its country and a bank key, as known to the SAP system. It does not represent a business partner's account at that bank; it represents the bank institution itself, the way a bank directory file would list it: name, street, city, region, and where available a SWIFT/BIC code and a national bank number. Rows are created either manually when a new vendor or customer supplies bank details for the first time, or in bulk by importing a country's official bank directory file. A single physical bank can end up with more than one row if it was loaded from more than one directory import over time, which matters when someone is trying to reconcile bank address data across systems.

MANDT first, as always. The real key is BANKS plus BANKL together; querying on BANKL alone across countries will return unrelated banks that happen to share a numeric code, since routing numbers are only unique inside their own country's numbering scheme. BANKA (bank name) is free text, not indexed for exact matching in the way BANKS/BANKL are, and multiple rows can carry near-identical names after repeated directory imports, so name-based lookups need a wildcard and manual eyeballing rather than an exact match. The table is not huge by SAP standards but can run into tens of thousands of rows after a full country bank directory load, so always filter by BANKS before doing anything else.

Symptom: a vendor payment run rejects a vendor with 'bank not maintained' or similar. Pull the vendor's bank country and bank key from LFBK for that vendor and partner bank type. Take that BANKS/BANKL pair and look it up directly in BNKA. No row returned means the bank was never loaded into the master; a row returned with LOEVM set means it exists but is flagged for deletion, which blocks it from being newly assigned even though old documents referencing it remain valid.

BNKA continues to exist as a standard table in S/4HANA and has not been replaced by a compatibility view; it remains the primary bank master table. Maintenance can be done through newer Fiori-based bank master apps in S/4HANA environments where those are activated, but the underlying table structure and key fields are unchanged from the ECC version, so joins and reports written against BANKS/BANKL still work the same way.

Ownership sits with FI master data governance, frequently shared with treasury for house bank and SWIFT/BIC accuracy. Country-specific bank directory imports are usually a periodic data load owned by whoever manages master data feeds, not something an individual consultant edits row by row. Vendor and customer-specific bank assignment errors are usually the AP/AR team's problem to raise, but the underlying BNKA record itself is fixed centrally.

KNBK and LFBK hold customer and vendor specific bank account assignments and are maintained through the customer and vendor master transactions. House bank and house bank account configuration is a separate IMG object referencing BANKS/BANKL but stored outside BNKA. Bank master maintenance itself is typically done through the standard bank create, change, and display transactions. REGUH and PAYR pick up the bank reference during payment program runs and payment medium generation respectively.