バッチファイルを超えて：ERPと銀行をつなぐリアルタイムの資金管理と税務

20年にわたり、企業の財務は遅れを前提に動いてきました。ERP（SAP S/4HANA、Oracle、Odoo）がその日の帳簿を締めます。定期実行のジョブが、CSVやMT940のフラットファイルをSFTPで銀行へ送ります。チームは、銀行が何を受け付け、何が失敗したのかを翌朝まで知ることができませんでした。

こうした働き方は、GCC諸国、ヨーロッパ、中東、アフリカで崩れつつあります。二つの変化により、バッチファイルは直接的な事業リスクになりました。

夜間ファイルが通用しなくなった理由

• 税務はリアルタイムで検査されます。 サウジアラビアのZATCAフェーズ2、アラブ首長国連邦のPINT-AE枠組み、EUのViDA（VAT in the Digital Age）では、各請求書を法的に発行または決済する前に、XMLとして検証し、暗号学的に署名することを、リアルタイムまたはそれに近い速度で求めています。

• 決済には豊富なデータが載ります。 ISO 20022は、短い参照項目を、完全に構造化された送金詳細に置き換えます。対象は支払指図（pain.001）と資金管理メッセージ（camt.053、camt.054）です。

企業が古いバッチミドルウェアの上にリアルタイムの税務承認とISO 20022を重ねると、資金は途中で滞留し、照合は手作業になり、検査が失敗するたびに請求が止まります。

標準コネクターが本番で力不足になる理由

標準の連携コネクターは、単純なケースをうまく処理します。しかし、何千もの取引が一度に到着するときに財務記録の整合性を保つようには作られていません。成熟した企業では、次の三つの問題が繰り返し現れます。

• データが変換の途中で失われます。 カスタムのERPテーブルは、注意深くルールに基づくマッピング層がなければ、厳格なISO 20022スキーマやUBL 2.1の電子インボイスにきれいに対応しません。

• リトライで重複が生じます。 銀行や税務ゲートウェイが負荷でタイムアウトしたとき、単純なリトライは同じ支払を二度送ったり、同じ請求書を二度提出したりします。

• 二つのシステムに二つの真実。 ERPが請求書を記帳済みとする一方で、税務当局はその署名を拒否します。財務チームは、互いに連携しないシステム間で、手作業により仕訳を戻すことになります。

当社の作り方

XSISは、連携を設定ではなくエンジニアリングとして扱います。信頼できるリアルタイムの資金管理とコンプライアンスのエンジンは、四つの部分から成ります。

1. すべてのイベントを一度だけ取り込む

当社はERPのデータベースをポーリングしません。トランザクションアウトボックスまたはERP自身のイベントメッシュを通じて、変更が起きた時点で取り込みます。すべての財務イベントには、文書の出所に基づく安定したキーが付き、銀行と税務のシステムをまたいで正確に一度だけ処理されます。

2. 送信前の検査

メッセージが銀行や税務ポータルに届く前に、独立した検証エンジンがXMLをスキーマと照合し、暗号署名（CSIDまたはX.509）を付与し、必要なQRコードとハッシュチェーンを生成します。これらはすべて50ミリ秒未満で完了します。

3. すべての銀行に対応する一つの内部形式

ERPと外部の間には、バージョン管理された内部データモデルがあります。新しい銀行の追加や、MTメッセージからMXメッセージへの移行のために、ERPのABAPやPL/SQLコードを書き直す必要はありません。

4. 銀行明細の自動照合

銀行明細（camt.053）と即時決済の通知（camt.054）は、明確なルールに従って読み込まれ、未回収の売掛金と照合されます。99%を超える項目が手作業なしで照合され、人に渡るのは実際の例外だけです。

始め方

バッチによる遅れをなくすために、ERPを入れ替える必要はありません。当社のBrownfield Diagnostic Bridgeから始めます。1週間から2週間で、お客様のERP、ミドルウェア、銀行の間でデータがどこで失われているかを特定します。その後、最も負担の大きい照合ループからリアルタイムに移行します。