支払日の前日、夕方。
経理の担当者が、Excelで振込データを作っています。
仕入先の口座を一件ずつ見直し、ネットバンキングに読み込ませる。作れるのは、この人だけです。
全銀フォーマットとは、全国銀行協会が定めた、銀行振込のデータの標準形式です。
NetSuiteでは、OracleのElectronic Bank Payments（電子銀行支払）を使えば、この形式の支払ファイルを作れます。
複数の仕入先への一括の支払も、振込手数料の自動計算も、公式の機能として用意されています。
ただし、手数料の計算には条件があります。
日本円だけのアカウントで、テキスト形式を使うこと。
では、自社の振込は、その条件の内側にあるのか。外側にあるのか。
この記事で分かること
- 全銀フォーマット（FBデータ）とは何か、なぜ手間になりやすいか
- NetSuiteで全銀の支払ファイルを作る仕組みと、2つの形式の違い
- 振込手数料の自動計算の条件
- 「標準に合わせる／開発する／残す」で見る、自社に要る範囲と費用の考え方
- 全銀対応でよくある3つの失敗と、その避け方
全銀フォーマット（FBデータ）とは
全銀フォーマットは、全国銀行協会が定めた、銀行振込のデータの標準形式です。
FBデータ（ファームバンキングデータ）は、この形式で作られた振込用のデータです。
振込の種別・口座名・金額・振込の指定日などが含まれます。
形式は各銀行で共通です。
インターネットバンキングに読み込ませれば、総合振込や給与振込をまとめて実行できます。
なぜ手作業の負担になりやすいのか
便利な仕組みですが、データの作成はかなり繊細です。
- FBデータは桁数が決まった固定長（1行120バイト）のテキスト。形式が少しでも崩れると銀行で受け付けられない
- 振込先が多いほど、入力と見直しの作業が増える
- 振込手数料の計算や仕訳も、手作業だとミスが起きやすい
冒頭の場面が続くのは、このためです。
一度作った手順を触るのが怖くなり、担当者が固定されていきます。
NetSuiteで全銀の支払ファイルを作る仕組み
Electronic Bank Paymentsが土台
NetSuiteで全銀の支払ファイルを作るには、Oracleが提供するElectronic Bank Payments SuiteAppを使います。
SuiteAppは、NetSuiteに追加して使う拡張機能です。
Oracleのヘルプでは、日本の支払形式を使うには、このSuiteAppのインストールが必要と書かれています。
対象の取引は、次の4つです（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
- 仕入先の請求書の支払
- 従業員の経費の支払
- 顧客への返金
- パートナーへの支払
設定の手順は、NetSuiteの総合振込・支払自動化｜Electronic Bank Payments（全銀対応）の使い方で詳しく扱っています。
全銀の2つの形式
Oracleのヘルプでは、全銀の形式が2つ案内されています（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
| 形式 | 提供元 | 振込手数料の自動計算 | 注意点 |
|---|---|---|---|
| Zengin Text（テキスト形式） | Electronic Bank Paymentsに付属 | 対応 | 手数料の計算は条件つき（2-4） |
| Zengin XML（XML形式） | Japan Localization SuiteAppに付属 | 未対応 | 先にElectronic Bank Paymentsを入れ、次にJapan Localizationを入れる |
Japan Localization SuiteAppは、日本の税や請求の実務に合わせるためのSuiteAppです。
詳しくはNetSuite Japan Localization SuiteAppとはをご覧ください。
どちらを使うかは、取引先の銀行が受け付ける形式で決めます。
手数料の自動計算を使いたいなら、テキスト形式が前提です。
複数の仕入先を、まとめて支払う
Oracleのヘルプでは、支払の画面が2つ案内されています（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
- Pay Single Vendor：1つの仕入先に支払う
- Pay Bills：複数の仕入先の請求書をまとめて支払う
支払のバッチ（まとめて処理する単位）の仕組みもあります。
ヘルプに書かれている主な点は、次のとおりです。
- 支払先ごとに支払をまとめて、1つの支払ファイルにできる
- 承認のルーティングを有効にすると、上限額を超えるバッチは承認まで処理されない
- 1つのバッチの取引は、最大5,000件。テンプレートの設定によって少なくなる
振込の件数が多くても、仕入先ごとに1件ずつ処理する必要はありません。
振込手数料の自動計算と、その条件
Electronic Bank Paymentsには、全銀の振込手数料を自動で計算する機能があります。
手数料の表を設定しておくと、支払のたびに手数料が計算され、支払ファイルに反映されます。
Oracleのヘルプに書かれている条件は、次のとおりです（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
- 日本円の単一通貨のアカウントだけで使える。複数通貨には対応していない
- 自社と仕入先の銀行口座が、全銀のテキスト形式のテンプレートを使っている
- 仕入先ごとに、手数料を仕入先が持つかどうかを設定する
- 仕入先の請求書の支払が対象。従業員・パートナー・顧客への支払は、自社の負担として扱う
仕入先が手数料を持つなら、請求額から手数料を引いた額が振り込まれます。
自社が持つなら、請求額の全額です。
問いは2つです。
日本円だけのアカウントか。銀行が受け付ける形式はテキストか。
両方に「はい」なら、手数料の計算は標準の機能に任せられます。
ライセンスの範囲
Oracleのヘルプでは、Electronic Bank Paymentsの高度な機能には、ライセンスが要ると書かれています。
（出典：Oracle NetSuiteヘルプ、2026年9月確認）
ヘルプに挙がっている主な機能は、次のとおりです。
- 支払のテンプレートの作成とカスタマイズ
- 「Process Bills Automatically」による、バッチの支払の自動処理
- 複数通貨の支払の処理
自社の契約でどこまで使えるかは、アカウントの担当に聞いてください。
NetSuiteの機能は随時更新されます。上の内容は2026年9月時点の公式ヘルプにもとづいています。
自社はどこまで要るか｜標準に合わせる／開発する／残す
全銀の支払を、どこまでシステムで行うか。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、振込の業務を見える化してから決めます。
選び方は3つです。
| 選び方 | 中身 | 向く会社 | 費用と手間の考え方 |
|---|---|---|---|
| 残す（手作業） | Excelやネットバンキングの画面で、振込データを作る | 振込先がごく少ない | 追加の費用はないが、属人化とミスが残る |
| 標準に合わせる | Electronic Bank Paymentsで、全銀の支払ファイルを作る | 日本円だけで、振込のルールが単純 | ライセンスの範囲を確かめる。設定と口座の登録が中心 |
| 開発する | 標準に、条件の外の処理や独自のルールを足す | 複数通貨・独自のルールがある | 足す範囲に比例して、導入費も稼働後の保守も増える |
「開発する」の例として、次のようなものが考えられます。
- 複数通貨のアカウントで、全銀の手数料を計算したい
- 銀行や取引先ごとに、独自の振込ルールがある
- 支払の後の仕訳や、関連する帳票の作成まで自動にしたい
手数料のXML対応のように、公式の更新を待つ部分もあります。
今後の更新の告知を見て、開発するか、待つかを選びます。
費用の目安も、この選び方で変わります。
ベンチャーネットが支援したNetSuite導入の費用には、幅があります。
3名程度・購買と販売だけ・開発なしで150万円程度の例。
100名程度・外部システムとの連携開発ありで2億円程度の例。
差を生む要因は4つです。業務の範囲、開発の量、社内の体制、ユーザー数。
振込の独自ルールを開発で補うほど、2つ目の「開発の量」が増えます。
事例の詳しい中身は、NetSuiteの料金・費用で扱っています。
判断の物差し
標準の機能で足りることが多い会社
- 日本円だけで支払っている
- 振込のルールが単純で、手数料の負担の決め方も決まっている
- 振込の件数は多くても、支払の流れが毎月ほぼ同じ
開発で補うことを考える会社
- 複数通貨のアカウントで、全銀の手数料を計算したい
- 取引先ごとに、例外の多い振込のルールがある
- 支払の後の仕訳や帳票まで、手入力をなくしたい
NetSuite以外が合う場合
全銀の振込だけのために、ERPを入れ替える必要はありません。
振込先が少なく、いまの会計ソフトの振込の機能で足りているなら、そのままで構いません。
困りごとが属人化だけなら、まず手順書と二人での見直しから始める手もあります。
会計・販売・在庫をまとめる理由があるときに、振込も一緒に整える。
そのほうが、効果は大きくなります。
第4章の見方を「こうしたいなら、これ」の形にすると、次の図のとおりです。
財務会計をNetSuiteにまとめる際の考え方は、NetSuiteで財務会計を行う前に確認すべきことで扱っています。
これから選ぶ会社と、いま使っている会社
これからNetSuiteを選ぶ会社
デモや見積もりの段階で、次の3つを聞いておきます。
- 全銀のテキスト形式とXML形式の、どちらを使うか
- 手数料の自動計算の条件（日本円だけか）に、自社が当てはまるか
- Electronic Bank Paymentsのどの機能が、契約に含まれるか
この3つが分かると、開発の要否と費用の見通しが立ちます。
NetSuiteのライセンスは、ミニマム構成で月額20万円〜が出発点です。
モジュールやユーザー数で変わり、数百万円規模になることもあります。
いまNetSuiteを使っていて、振込だけ手作業の会社
NetSuiteを使っているのに、振込データはExcelで作っている。
ベンチャーネットの仕事は、ゼロからの導入より、他社が導入した後の引き継ぎや立て直しが多くあります。
振込の手作業も、そこで見直す項目の一つです。
見直しは、次の順で進めます。
- Electronic Bank Paymentsが入っているか、どのバージョンか
- 仕入先の口座情報が、NetSuiteに正しく登録されているか
- 手数料の負担の決め方が、仕入先ごとに決まっているか
過去に作った独自の仕組みがあれば、標準の機能に置き換えられないかも見ます。
作った会社と、いまの保守の会社が違うことは珍しくありません。
その場合は、役割を分けて進めます。
| 担い手 | 担うこと |
|---|---|
| 日本オラクル | ライセンス・製品サポート（Electronic Bank Paymentsの契約の範囲を含む） |
| ベンチャーネット | 既存の仕組みの調査・設定の見直し・開発・保守 |
| 自社 | 仕入先の口座情報と手数料の負担のルールの整理、テスト |
全銀対応でよくある3つの失敗
失敗1：「標準で全部できる」か「何もできない」と思い込む
起きること：標準の機能だけで完結すると考えて導入し、稼働後に手間が残る。逆に、標準でできることまで作り込んでしまう。
原因：Electronic Bank Paymentsでできることと、その条件（日本円だけ・テキスト形式・ライセンス）を見ていなかった。
避け方：標準の範囲と条件を先に一覧にします。
「対応している」ことと「実務がそのまま楽になる」ことは、同じではありません。
失敗2：手作業での振込データの作成を続ける
起きること：特定の担当者しか振込データを作れない。二重振込や振込ミスのヒヤリがある。
原因：基幹システムを統合したのに、支払の業務だけがExcelや手入力のまま残っていた。
避け方：支払の流れをNetSuiteの中にまとめます。
振込データの作成が一人に依存する状態は、見えにくいけれど確かな経営のリスクです。
失敗3：過剰な作り込みで、改修が難しくなる
起きること：自社の特殊な振込ルールをすべてシステムに入れ、開発の費用が膨らむ。更新のたびに影響の確認が重くなる。
原因：Fit to Standard（業務を標準の機能に合わせる考え方）の逆を行き、例外まで作り込んだ。
避け方：標準でいけるところは標準で進め、条件の外だけを補います。
ERP導入がつまずく理由は、ERP導入はなぜ失敗するのかでも扱っています。
3つの避け方を並べると、次のとおりです。
ベンチャーネットならこう見る
ベンチャーネットは、特定の製品に誘導しない立場です。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
全銀の振込の相談で、最初に聞くのは3つです。
- 支払は日本円だけか
- 取引先の銀行が受け付ける形式は、テキストかXMLか
- 標準の条件に当てはまらない振込が、全体のどのくらいあるか
3つ目が少なければ、標準の機能で運用を始めます。
多い場合も、まず標準で回し、手間が残る部分から補います。
第3章の「標準に合わせる／開発する／残す」を、例外の一件ずつに当てはめる進め方です。
「変わること」を先に伝える
標準に合わせると、いまの振込の手順は変わります。
ベンチャーネットは、次の点を見積りと同じ場で伝えます。
- ライセンス：高度な機能を使うなら、契約の範囲が広がることがある
- 手数料の扱い：仕入先ごとの負担の設定を、NetSuite側で持つことになる
- 画面の操作感：ネットバンキングやExcelでの作業とは変わる
- 給与振込：給与・人事は導入の対象外。いまの仕組みを残す前提で考える
後から知れば「話が違う」になる点ばかりです。
先に並べておけば、どこまで標準に合わせるかを社内で決めやすくなります。
今日できること｜先月の振込を書き出す
先月の振込について、次の表を埋めてみてください。1時間ほどでできます。
| 項目 | 記入の例（架空） | 自社 |
|---|---|---|
| 振込の件数 | 80件 | |
| 仕入先の数 | 45社 | |
| 外貨での支払の有無 | なし | |
| 手数料を仕入先が持つ取引先の数 | 30社 | |
| 振込データを作れる担当者の数 | 1人 | |
| 標準の条件に当てはまらない振込 | 3件 |
最後の行が少なければ、標準の機能で足りる可能性が高くなります。
担当者が1人なら、機能より先に、属人化の解消を優先してください。
よくある質問
Q1. NetSuiteで、全銀フォーマットの振込データは作れますか
Electronic Bank Paymentsで作れます。
Oracleのヘルプでは、全銀のテキスト形式とXML形式が案内されています。
仕入先の支払・従業員の経費・顧客への返金・パートナーへの支払が対象です（第2章）。
Q2. 複数の仕入先に、まとめて支払えますか
Pay Billsの画面や支払のバッチでまとめて処理できます。
支払先ごとにまとめて、1つの支払ファイルにすることもできます。
1バッチの取引は最大5,000件です（2-3）。
Q3. 振込手数料は自動で計算できますか
条件を満たせば自動で計算できます。
日本円の単一通貨のアカウントで、全銀のテキスト形式を使うことが条件です。
XML形式では、手数料の計算にまだ対応していません（2-4）。
Q4. 開発（カスタマイズ）は必ず要りますか
必須ではありません。
日本円だけで、振込のルールが単純なら、標準の機能で足りることが多くあります。
複数通貨や独自のルールがある場合に、補う範囲を決めます。
開発を選ぶほど、導入費も保守も増えます（第3章）。
Q5. 手作業での振込データの作成を続けると、何が問題ですか
振込ミスのリスクと属人化が問題です。
振込データの作成が一人に依存すると、その人が休むと支払が止まりかねません。
支払の流れをNetSuiteにまとめると、ミスと属人化の両方を抑えられます。
Q6. 入金側の消込も自動にできますか
入金側は別の仕組みで考えます。
銀行の明細との照合や、全銀EDIを使った消込は、関連記事で扱っています。
支払と入金を分けて考えると、進めやすくなります。
導入でよくいただく質問は、NetSuite導入でよく受ける質問30問にもまとめています。
まとめ
- 全銀フォーマットは、全国銀行協会が定めた振込のデータの標準形式
- NetSuiteでは、Electronic Bank Paymentsで全銀の支払ファイルを作れる
- 複数の仕入先の一括の支払、承認、振込手数料の自動計算も公式の機能にある
- 手数料の計算は日本円だけ・テキスト形式が条件。XML形式は未対応
- 「標準に合わせる／開発する／残す」を例外ごとに選ぶ。開発するほど費用と保守が増える
冒頭の担当者の手順は、まず先月の振込を書き出すところから変えられます。
条件の内側の振込が多いと分かれば、その分はNetSuiteの標準に任せられます。
関連する記事：
もう少し詳しく知りたい方へ
全銀の振込で、標準の機能で足りるか、どこを補うか。
その切り分けの段階から、ご相談をお受けしています。
- 標準の外の処理を、開発で補いたい方：NetSuiteリブート（開発・カスタマイズ・連携）
- いまのNetSuiteの運用を見直したい方：NetSuiteの保守・伴走サポート
- まず自社の状況を相談したい方：お問い合わせ
コメント
コメント一覧 （1件）
[…] 個別の記事は、NetSuiteの銀行連携・自動消込ガイド、全銀フォーマット（FBデータ）の支払自動化、ZEDI（全銀EDI）×NetSuiteにあります。 […]