注文は完了なのに請求額が違う。入金はあるのに対応する請求書が見つからない。「照合完了」という回答だけでは、書類の欠落、参照の誤り、二重取り込みを区別できません。
Busa Auditは、注文・請求・入金のエクスポートを例外確認の画面につなぐテンプレートです。規則で候補を抽出し、人が証拠を確認して対応案を編集します。銀行やERPから自動で全データを取得する製品として扱わないことが出発点です。
ステップ1：導入し、エクスポートと列を準備する
紹介ページからサインインし、対象ワークスペースへインストールします。処理権限のあるローカルCSVまたはJSONを用意してください。三種類の一部だけでも取り込めますが、欠けた資料は照合範囲に影響します。インポーターは外部業務システムから伝票を取得しません。
会社情報、基準通貨、必要な為替換算、列マッピングを確認します。注文のorder_no、請求のinvoice_no、入金のpayment_refが自然キーです。変動する行番号では同一伝票を識別できないため、安定した識別子を先に決めます。
請求までの許容日数、金額の許容差、滞留期間区分、重複検知期間も合意します。許容差が広すぎると見落とし、狭すぎるとノイズが増えます。異なる通貨の数字をそのまま比較してはいけません。
公式テンプレート・英語デモデータ
六つのBaseで伝票と判断をつなぐ
Orders、Invoices、Paymentsに正規化した伝票を保存し、Anomaliesに規則、根拠、対応案、人の決定と実行情報を残します。Import logは件数と警告、Settingsは設定とマッピングです。例外から元の注文・請求・入金へ戻れる構成です。
状態や滞留日数、指標は読み込んだ記録から派生します。追加ページがある場合、全帳簿の集計と誤認せず読み込み範囲を確認します。Agentには「まず列と自然キーを確認して取り込みを試行し、承認後に規則を実行してください。伝票、差額、未確認事項を示し、値の補造や督促送信はしないでください」と範囲を伝えられます。
ステップ2：試行後に取り込み、規則を実行する
import_tables.mjsは--applyなしでは試行です。適用時には自然キーで追加・更新し、ログへ追記します。未知の請求番号を参照する入金やスキップ行を確認し、画面に行があるだけで取り込み完了としません。
run_checks.mjs --applyは未請求、注文との金額差、期限超過、重複請求・入金、未照合入金、元伝票のない貸方訂正や負の入金などを調べます。いずれも調査候補であり、不正認定や自動仕訳ではありません。重複と未照合では、確認すべき識別子や銀行証憑も違います。
公式テンプレート・英語デモデータ
ステップ3：証拠と処理履歴を確認する
例外IDはanom-<rule>-<key>で安定し、再実行は重複作成せず更新します。既存の状態、参照、決定、実行情報は保持され、条件が消えた例外はdoneになります。doneが外部対応完了を意味するとは限らず、背景を確認する必要があります。
Agentは説明や対応案を整えられますが、識別子と証拠を保持します。帳尻を合わせるために根拠を書き換えず、元データの訂正を権限のある経路で行って再取り込みします。
ステップ4：対応案を確認して外部実行へ渡す
画面では証拠、編集可能な対応案、レビュー注記を確認し、承認・修正依頼・保留・終了を記録します。保存は利用者の権限に従い、書き込み権限があれば即時、なければCRになる場合があります。業務上のapprovedとCRの承認状態は別です。
execute_decisions.mjsは既定では試行で、明示した実行依頼と--applyによりready_for_agentと予定操作を書きます。メール送信、ERP修正、送金はしません。別の許可された実行経路で対応し、実際の結果を例外へ戻します。このスクリプトは業務状態をdoneにも変更しません。
公式テンプレート・英語デモデータ
ステップ5：照合の一巡を検証する
ファイル行数とログ、警告を照合し、一件の差額を原伝票まで追います。規則を再実行して重複せず判断が残ることを確認し、外部対応の権限と結果を別に検証します。
公式スクリーンショットは英語のデモデータであり、顧客帳簿の照合実績ではありません。具体的な操作はテンプレートのソースを確認してください。限定した資料で証拠の確認を成立させてから、範囲を広げられます。
確認できる一組の伝票から始める
Busa Auditのテンプレートページを開き、サインインして対象ワークスペースへ導入します。許可された注文・請求・入金のデータを用意し、列と許容差を確認してから試行と規則実行を依頼してください。証拠と対応案を確認した後で、外部実行の許可を判断します。