JinJin48
JinJin48
SAP Consultant | BTP · S/4HANA · US Global Rollout
· 12 min read

カバー: SAP FI 銀行マスタ — グローバル銀行機関レジストリ

SAP FI 銀行マスタ

銀行マスタ(BNKA)は、全会社コードで使用される銀行機関を定義するグローバルなマスタレコードです。銀行識別情報(国固有の銀行キー、SWIFT/BICコード)、住所、連絡先データを格納します。会社コード依存のマスタとは異なり、1つの銀行マスタレコードがシステム全体で機能し、後で自社銀行レコードが特定の会社コードをこれらの銀行に紐付けます。本記事では、国別のキー構造、グローバルデータ階層、支払処理との統合、およびFI(財務会計)管理項目の詳細について説明します。


第1部: 銀行マスタ — 基本概念(全モジュール共通)

1.1 銀行マスタとは

銀行マスタの概要:グローバルスコープとモジュール間での使用状況

銀行マスタは、銀行機関の参照レコードです。特定の組織レベルに紐づくものではなく、銀行ごとに1つのレコードとしてシステム全体で使用されます。

項目詳細
役割銀行識別情報と連絡先の集中リポジトリ。得意先/仕入先マスタにおけるハウスバンク(会社固有の銀行口座)および取引先銀行口座割り当ての前提条件
使用モジュールFI(ハウスバンク設定、支払実行)、MM(仕入先支払方法)、SD(得意先返金/回収銀行詳細)、TR(資金管理)、RE(不動産支払)
トランザクションFI01(銀行作成)、FI02(銀行変更)、FI03(銀行表示)、FI04(銀行→会社コード割り当て表示)
主要テーブルBNKA(銀行マスタデータ:国、キー、名称、住所、SWIFT)、T012(ハウスバンク:BNKAと会社コードを紐付け)、TIBAN(IBAN構造ルール)
S/4HANAに関する注意点銀行マスタ構造はECCから変更なし。S/4HANA 2020以降ではSWIFT/BIC検証が厳格化。一括作成/アップロード用にFioriアプリ**銀行管理(F4242)**が利用可能。マルチバンクコネクティビティ(クラウドベースの銀行通信)との支払統合により、従来のEDI形式を置き換え

1.2 国別の銀行キー構造

各国の銀行キー形式の比較

銀行キーは国によって異なります。SAPは銀行国+銀行キーの組み合わせを一意の識別子として使用します。誤った形式を選択すると、支払ファイルの生成やSWIFTメッセージのルーティングに支障をきたします。

国キー形式コード長例キーの動作
日本 (JP)全銀コード7桁00012344桁の銀行コード + 3桁の支店コード;全銀システムによるルーティング;スペースなし
アメリカ (US)ルーティングナンバー (ABA)9桁021000021連邦準備制度によるルーティング;小切手処理;ABAディレクトリで検証
ドイツ (DE)銀行コード (BLZ)8桁10010010ドイツ連邦銀行の登録簿;SEPAではBICに置き換えられたが、社内では引き続き使用
イギリス (GB)ソートコード6桁2000002桁の銀行 + 4桁の支店(形式:XX-XX-XX);BACS/CHAPSルーティング
国際SWIFT/BIC8桁または11桁の英数字CITIUS33XXXISO 9362標準;8文字(銀行)または11文字(支店);国境を越えた支払いに必須

設計原則: 国内ルーティング用の国固有の銀行キーと、国際送金用のSWIFT/BICコードの両方を常に入力してください。どちらかが欠けていると、支払いファイルの拒否や手作業による修正が発生します。


1.3 組織階層とデータ階層

銀行マスタのグローバルスコープと自社銀行の会社コード連携

銀行マスタは組織依存ではありません。一度作成されると、すべての会社コードから自社銀行レコードを介して参照されます。

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)
組織レベルテーブル主要項目備考
グローバルBNKA銀行国コード (BANKS)、銀行キー (BANKL)、銀行名 (BANKA)、SWIFTコード (SWIFT)銀行ごとに1レコード。会社コードによるフィルタはなし。変更は全ユーザに影響
会社コードT012会社コード (BUKRS)、自社銀行ID (HBKID)、口座ID (HKTID)、銀行国コード/キー (BANKS/BANKL)BNKAを会社コードに紐付け。1つのBNKAレコード → 複数のT012レコード。G/L勘定はBNKAではなくここで割り当て
支払REGUH支払実行ではT012 → BNKAの連鎖を使用REGUH(支払ヘッダ)が自社銀行を読み取り、BNKAからSWIFT/ルーティング情報を取得してDMEファイルを生成

主要な設計判断: ハウスバンクレコードが参照している場合、銀行マスタの削除はブロックされます。削除を試みる前に、必ずFI04(銀行→会社コード割当)を確認してください。


1.4 他のマスタデータオブジェクトとの統合

銀行マスタ統合:ハウスバンク、仕入先、得意先、支払い

銀行マスタは支払処理の前提条件です。他のマスタに依存しませんが、広く参照されます。

オブジェクト関係性実務上の注意点
自社銀行口座 (T012)1 銀行マスタ → N 自社銀行口座各会社コードが独自の自社銀行口座IDを作成し、同一のBNKAレコードを参照します。買掛金・給与の支払い(AP、給与計算)や売掛金・ロックボックス(AR、ロックボックス)による入金に必要です。
仕入先マスタ (LFA1/LFBK)N 仕入先 → 1 銀行マスタ仕入先の銀行口座(LFBK)には、BNKAを参照する銀行国コード/キーが格納されます。自動支払プログラム(F110)で使用され、支払ファイル内の受取人銀行情報を設定します。
得意先マスタ (KNA1/KNBK)N 得意先 → 1 銀行マスタ得意先の銀行口座(KNBK)には、銀行国コード/キーが格納されます。返金、口座振替、ARロックボックスの照合に使用されます。
支払媒体ワークベンチ (OBPM1)支払プログラムがT012経由でBNKAを読み取りDME(データ媒体交換)設定により、BNKAからSWIFT/BIC、IBAN、ルーティング番号を取得し、SWIFT MT103、ACH NACHA、Zengin、SEPA XMLファイルを生成します。

パート 2: FI固有のフィールド詳細

2.0 FIオーナーシップの範囲

FIによる銀行マスタデータセクションの所有権

データ区分FI 関与備考
銀行識別◎ オーナー銀行国コード、銀行キー、銀行名 — 一意の識別子。FI管理者がFI01で作成
住所データ◎ オーナー通り、市区町村、地域、郵便番号 — 支払通知書やコンプライアンス報告に必須
通信データ◎ オーナーSWIFT/BIC、テレックス、FAX — 国際送金ルーティングやSWIFTメッセージヘッダーに重要
制御データ◎ オーナー私書箱、銀行支店、言語キー — 明細照合や地域支店向けの補足データ

凡例: ◎ = オーナー/クリティカル、○ = 直接関与


2.1 銀行識別

銀行識別フィールド - 国、キー、名称

銀行を一意に識別し、ルーティング動作を決定するコアフィールド。

フィールド説明実務上の使用例
銀行所在国ISO 3166-1 alpha-2 国コード(2文字、例:JP、US、DE)銀行キーの形式と検証ルールを決定します。日本(JP)は7桁の全銀コード、米国(US)は9桁のABAルーティングナンバーを想定します。国とキー形式の不一致は支払ファイルの拒否につながります。作成時に一度設定され、ハウスバンクが存在する場合は変更できません。
銀行キー国固有の銀行識別子(形式はセクション1.2を参照)国内支払の主要なルーティングフィールドです。日本では、銀行に送信される全銀フォーマットファイルで使用される全銀コードです。米国では、小切手に印刷されるABAルーティングナンバーです。公式レジストリ(全銀センター、連邦準備制度理事会など)と一致する必要があります。キーが誤っていると、支払は「無効なルーティング」として返却されます。
銀行名銀行の正式な法人名(最大60文字)支払通知、銀行取引明細書、ベンダーとの通信に表示されます。マーケティング名ではなく、公式登録名を使用してください。例:THE BANK OF TOKYO-MITSUBISHI UFJ, LTD.(MUFG Bankではありません)。一部の銀行ではSWIFTメッセージ受信のために正確なスペルを要求し、不一致があると手動調査が発生します。
銀行支店支店名または場所識別子(40文字、任意)銀行キーに支店コードが含まれる国(例:日本の全銀コード:下3桁=支店)で使用されます。複数支店構成の場合、どの物理的な場所が口座を保有しているかを明確にします。SWIFTメッセージでは使用されませんが、取引明細書の照合や監査証跡に役立ちます。本店または単一支店の銀行の場合は空白のままにします。

2.2 アドレスデータ

支払通知およびコンプライアンス用の銀行住所フィールド

銀行の物理的な住所。支払通知書、税務報告、規制当局への提出書類に必要です。

項目説明実務上の使用例
番地 / 建物番号通り名と建物番号日本のコンプライアンス報告(国税庁への届出では、特定の書式で銀行住所が必要)に必須。また、郵送で送付される支払通知書にも印字されます。大規模な銀行の場合は、銀行支店フィールドで特定の支店が指定されていない限り、本店住所を使用します。一部の支払形式(例:SEPA Pain.001 XML)では、債権者機関セクションに銀行住所が含まれます。
市区町村市区町村名SWIFTコードが不完全な場合、SWIFT MT103のフィールド57A(受益銀行)に表示されます。また、米国のNACHA ACHファイルでは、受取預金金融機関(RDFI)の名称/所在地として使用されます。中央銀行に登録されている市区町村名と一致している必要があり、不一致があると国境を越えた支払調査が遅延する可能性があります。
地域都道府県/州/省コード(2~3文字)米国(NY、CAなどの州コード)およびカナダ(ON、BCなどの州コード)で重要です。日本では、都道府県コード(東京は13、大阪は27)を使用します。支払実行ログには地域が表示され、トレジャリーチームが銀行の所在地を迅速に特定するのに役立ちます。中央登録機関での検証は行われませんが、市区町村と整合している必要があります。
郵便番号ZIP/郵便番号SEPA XMLファイル(債権者機関アドレスの郵便番号要素)で使用されます。日本では、全銀総合システム用の支払ファイルバリデーターにより、7桁の郵便番号形式(123-4567)が強制されます。誤った郵便番号は支払実行を妨げませんが、監査レポートでコンプライアンスフラグが発生する可能性があります。

2.3 通信データ

通信フィールド - SWIFT、電話、FAX、テレックス

支払いルーティング、SWIFTメッセージング、および銀行通信のための連絡先詳細。

項目説明実務上の使用例
SWIFTコード / BICISO 9362銀行識別コード(8桁または11桁の英数字)クロスボーダー支払いに必須。8桁コードは銀行を識別(例:東京三菱UFJ銀行の場合はBOTKJPJT)、11桁コードは支店を追加(例:大阪支店の場合はBOTKJPJTOSA)。SWIFTメッセージ(MT103、MT202)では、フィールド57A(受益銀行)で使用。SAPはダウンロードしたSWIFTディレクトリ(テーブルSWIFT_TAB)に対してBICを検証。BICが誤っていると、コルレス銀行により支払いが拒否される。合併・買収によりBICが変更されたにもかかわらず、SAPに旧コードが残っている場合に発生しやすいエラー。銀行合併の発表後は速やかに更新すること。
電話番号銀行の代表電話番号またはトレジャリー担当者番号(国際形式推奨:+81-3-1234-5678)トレジャリーチームが支払い調査のために使用。支払いが失敗または遅延した場合、最初に電話をかける番号。自動支払いファイルでは使用されないが、手動フォローアップには不可欠。大手銀行の場合は、カスタマーサービスではなく、コーポレートトレジャリーまたはコルレスバンキング窓口の番号を入力すること。
FAX番号FAX番号(日本では支払確認や口座開設で現在も使用)日本では、銀行は全銀ファイル受信後に支払確認FAXを送信することが多い。自社の口座を担当する支店のFAX番号を入力すること。欧米ではFAXは時代遅れであり、コンプライアンス文書のために銀行から特に要求がない限り、空白のままにすること。
テレックス番号レガシーテレックス番号(SWIFT普及後はほとんど使用されず)SWIFT以前の時代の項目。SWIFTへのアクセスが限られている国(例:一部のアフリカや中央アジアの銀行)の銀行と取引がある場合のみ入力。最新の支払いシステムはこのフィールドを無視する。後方互換性のために保持されている。不明な場合は空白のままにすること。

2.4 制御データ

コントロールフィールド - 私書箱、言語、グループキー

メールルーティング、地域別処理、およびレポート作成のための補足フィールド。

フィールド説明実務での使用例
私書箱私書箱番号(オプション)銀行によっては、支払通知書や取引明細書を住所ではなく私書箱に送付することを希望する場合があります。米国やオーストラリアで一般的です。銀行がレターヘッドに私書箱を記載している場合は、ここに入力します。SAPの支払通知印刷プログラム(例:米国小切手用のRFFOUS_C)はこのフィールドを読み取り、封筒の宛先を適切にフォーマットします。日本ではほとんど使用されません(銀行は住所を使用します)。
言語キーISO 639-1言語コード(2文字:EN、JA、DEなど)自動生成される支払通知書や文書の言語を決定します。JA(日本語)に設定すると、SAPは日本語で支払通知を印刷します。ENに設定すると英語で印刷します。SWIFTメッセージには影響しません(常に英語)。多言語地域(例:スイス:DE、FR、IT)で、銀行が希望する文書言語に合わせる場合に便利です。
銀行グループレポート用のグループ化コード(4文字、オプション)財務レポート(例:S_ALR_87012357 - 銀行マスタリスト)で、銀行を種類別に分類するために使用されます:CITY(日本の都市銀行)、RGNL(地方銀行)、FREX(外国為替銀行)、CRED(信用金庫)。支払処理では使用されません。純粋に内部レポートやKPIダッシュボード(例:「都市銀行経由の支払い割合 vs 地方銀行」)のためのものです。
銀行ネットワークネットワーク提携コード(例:SWIFT、CHIPS、ZENGIN)銀行が参加している支払ネットワークを示します。日本:ZENGIN(全銀ネットワーク)。米国:FED(連邦準備制度)、CHIPS(クリアリングハウス銀行間決済システム)。欧州:SEPA(単一ユーロ決済圏)。これは情報提供のためのメタデータであり、支払プログラムはこのフィールドではなく銀行国コードを読み取ってファイル形式を決定します。ただし、監査人や支払最適化プロジェクト(例:手数料削減のためCHIPS支払いをSWIFTに切り替える)には有用です。

次に読むべきもの

L1) Big Picture

IDCategoryTitle
fi-001OverviewSAP FIとは何ですか?

L2-A) Master Data

IDCategoryTitle
fi-a01OverviewSAP FI マスタデータ:概要、階層、および関係性
fi-a02-01Master DataSAP FI 品目マスタ
fi-a03-01Master DataSAP FI 勘定科目表
fi-a03-02Master DataSAP FI 総勘定元帳
fi-a04-01Master DataSAP FI 支払条件
fi-a04-02Master DataSAP FI 税コード
fi-a06-01Master DataSAP FI 銀行マスタ 📍
fi-a06-02Master DataSAP FI 仕向銀行
fi-a07-01Master DataSAP FI 資産クラス
fi-a07-02Master DataSAP FI 減価償却キー
fi-a07-03Master DataSAP FI 資産マスタ

L2-B) Transaction

IDCategoryTitle
fi-b01OverviewSAP FIトランザクション:プロセスフロー、階層、関係性