Setup

ERP、請求、銀行照合

支払いと承諾済み見積りをERPに送信し、銀行取引と保留中の支払いを自動的に照合します。すべてBYOモデル(ERPと銀行はあなたのものです)です。

この連携は、財務業務のための汎用的で中立的、グローバルなコネクタで、2つの独立した機能を持ちます:(1)支払いが確認されたとき、または見積りが承諾されたときにデータをERP/会計システムに送信する。(2)銀行(Open Banking経由)、Plaid、Tink、TrueLayerなどの金融アグリゲーター、または銀行自体から取引を受け取り、保留中の支払いと自動的に照合する。国や通貨を問わず、QuickBooks、Xero、NetSuite、SAPなど任意のERP、任意の銀行と機能します。BYOモデル:アカウントと認証情報はあなたのものであり、当社側でのコストはありません。

どちらも無効な状態で始まります。設定して有効化するまで何も起こりません。シークレット(ERP APIキーと銀行のwebhookシークレット)は暗号化して保存され、再表示されることはありません。

前提条件

ERP/請求:POST JSONを受信できるERP(QuickBooks、Xero、NetSuite、SAPなど)内のHTTPエンドポイントと、それを認証するための認証情報(APIキーまたはトークン)。
銀行照合:取引webhookを送信でき、HMAC-SHA256で署名できる、銀行またはOpen Bankingアグリゲーター(Plaid、Tink、TrueLayer、または銀行自体)のアカウント。
Sellioにおいて、設定 → 連携でコネクタを保存・有効化できる管理者アクセス権。

ERP/請求(送信)

支払いが確認されたとき(決済プロバイダーのwebhookまたは銀行照合による)、またはリンクされた見積りが承諾されたときに、CRMはあなたのERPエンドポイントに { event, data, source, sentAt } 形式のJSONエンベロープでPOSTします。eventはその出来事を示し(例:payment.paid)、dataには各フィールド(金額、通貨、参照番号、見積り/商談ID)が含まれます。

設定 → 連携を開き、「ERP/請求」カードに移動します。
エンドポイント(URL):POSTを受信するERPのアドレスを貼り付けます(例:https://erp.yourcompany.com/api/webhooks/crm)。
認証ヘッダーとプレフィックス:認証方法を入力します(例:プレフィックス「Bearer 」付きのAuthorization、またはプレフィックスなしのX-Api-Keyのようなカスタムヘッダー)。
APIキー:ERPのキーを貼り付けます。暗号化して保存されます。
コネクタを保存し、「テスト送信」で検証してから「有効化」をクリックします。自動送信はコネクタが「有効化」されている場合にのみ行われます。

💡 送信はベストエフォートです。ERPがダウンしていたり呼び出しを拒否したりしても、CRMには影響がなく、支払いは正常に記録されたままです。

銀行照合(受信)

銀行/Open BankingのwebhookをCRMが生成するURLに向けます。受信した各取引(金額、通貨、参照/説明、外部IDを含むJSON)について、CRMは一致する「保留中」の支払いを探し、支払い済みとしてマークします。

「銀行照合」カードでWebhookシークレット(呼び出しの署名に使うキー)を入力し、保存します。
webhook URLを生成し、銀行/Open Banking/アグリゲーターに貼り付けます。
プロバイダーが各呼び出しの本文をHMAC-SHA256で署名し、署名をX-Signatureヘッダー(16進数またはbase64、sha256=プレフィックスの有無を問わない)で送信するように設定します。
連携を有効化します。

マッチングの仕組み

CRMは(お金に関わることなので決して推測せず)保守的に、かつ国に依存しない方法で照合します:(1)正確な金額で保留中の支払いを絞り込み、取引が通貨を報告している場合は同じ通貨でも絞り込みます。(2)取引に参照/説明がある場合、その参照内に識別子(ID、外部ID、見積りまたは商談)が現れる支払いを優先します。(3)参照による絞り込みができない場合、その金額の保留中支払いが「ちょうど1件」だけのときに限り照合します。同じ金額の支払いが複数あり、区別するものが何もない場合、その取引は未照合のままになります(手動で対処するため)。

例: 取引:{ amount: 199.90, currency: "USD", reference: "Payment quote q_8f2a", external_id: "tx_123" } → 見積りがq_8f2aである199.90の保留中の支払いに一致し、支払い済みとしてマークされます。

💡 照合は冪等です。マッチングの対象は保留中の支払いのみであるため、銀行が同じ取引を再送しても、支払い済みの支払いが再度触れられることはありません。一致しない取引は、受信を中断することなくログに記録されます。

テスト方法

ERP:コネクタを有効化した状態で、「ERP/請求」カードの「テスト送信」をクリックし、ERP側でPOSTが届いたことを確認します(受信したwebhookの記録/ログを探してください)。
銀行照合:一意の金額で保留中の支払いを作成し、銀行/アグリゲーターで同じ金額と、見積り/商談を参照する説明を持つ取引をトリガー(またはシミュレート)します。支払いが「支払い済み」になったことを確認します。
連携の履歴/ログを確認し、受信した呼び出しと照合結果を確認します。

トラブルシューティング

「テスト送信」が401/403で失敗する:ERPのAPIキーが間違っているか、認証ヘッダー/プレフィックスが一致していません。キーを貼り直し、ヘッダー名(例:Authorizationの「Bearer 」、またはX-Api-Key)を確認してください。
送信時に404:ERPエンドポイントが間違っているか、そのルートが存在しません。POSTを受信する完全なURLを確認してください。
照合時に無効な署名(webhookが拒否される):CRM内のwebhookシークレットが銀行の署名に使うものと異なるか、署名がX-Signatureヘッダー(HMAC-SHA256、16進数またはbase64)で来ていません。両側で同じシークレットに揃えてください。
取引が照合されない:同じ金額の保留中支払いが複数あり、区別できる参照がない可能性があります。取引の説明にID/見積りを含めるか、手動で照合してください。通貨が一致しているかも確認してください。
送信時に何も起きない:自動送信はコネクタが「有効化」されている場合にのみ行われます。保存後に有効化してください。

この記事をシステム内で開く →