2ウェイマッチングがチェックする内容
と通過させてしまうもの

2ウェイマッチングが比較するもの

2ウェイマッチングはPOマッチングとも呼ばれ、買掛金管理（AP）の基本形です。請求数量は発注数量を超えられず、請求書の単価は発注書の価格を超えられません。これらはOracleがPayablesについて記述している基準であり、各テストの方向性は多くの説明が認めている以上に重要です（Oracle Payables Help）。

発注より少ない数量の請求書は通過します。POより低い価格の請求書も通過します。この統制は過剰請求を止めるために作られています。取引が実際に行われたことを確認するためではありません。この違いが、2ウェイマッチングで十分かどうかをめぐる議論のほとんどを説明します。

ERPでは、テストは明細行レベルで、設定した許容範囲内で実行されます。許容範囲とは、明細行がフラグを立てられる前に許される差異の割合または金額です。より弱いバージョンでは請求書合計とPO合計を比較しますが、2つの明細行の誤りが相殺されるため、明細行が誤っていても合計は一致することがあります。同じ請求書に運送費の明細行と納品不足が併存するのはよくある組み合わせです。

3ウェイマッチングは両方のテストを維持し、3つ目を追加します。請求数量は入荷数量を超えられません。4ウェイマッチングは検収を追加します。これは検査に合格した数量です。

ERPシステムはマッチングレベルを混在させるように作られています。Oracleでは、サプライヤー、サプライヤーサイト、発注書の出荷単位で請求書マッチングオプションを変更できます。SAP Ariba自身のガイダンスは、多くの企業が3ウェイマッチングを運用する一方、低額の購買を簡素化するために2ウェイを採用する企業もあると指摘しています（SAP Ariba invoice reconciliation guide）。すべての請求書に同じレベルを適用するのはポリシーの選択であり、通常は高くつく選択です。

商品が届かなくても通ってしまう請求書

500ユニットを$8で発注した発注書と、500ユニットを$8で請求する請求書は、500ユニットが届いても、450ユニットしか届かなくても、1つも届かなくても2ウェイマッチングを通過します。450ユニットしか届いていないのにサプライヤーが500ユニット分を請求した場合、数量チェックは請求500と発注500を比較して合格となります。$400の差額は例外にはなりません。3ウェイマッチングでは請求500と入荷450を比較し、その請求書を保留にします。

数量単位は数量チェックを両方向で破綻させます。20ケースを$240で発注した発注書と、240個を$20で請求する請求書は同じ金額になります。生の数値20と240を比較するシステムは、正しい請求書を保留にしてしまいます。合計金額を比較するシステムは、明細行の数量が対応していなくても合格させてしまいます。梱包単位の変更や重量から個数への換算がこの不一致を生むため、マッチングポリシーには数量単位のフィールドが必要です。

ヘッダーレベルマッチングにはもう一つの盲点があります。発注書に存在しなかった明細行です。運送費、燃料サーチャージ、パレット料金、少額注文手数料は、発注書に対応する項目がないまま請求書の明細行として届くことがよくあります。3%の許容範囲で合計金額をマッチングすると、$4,000の注文に対する$120の運送費は、その費用が合意されていたかを誰も判断しないまま通過します。こうした注文が年に200件あれば、$24,000が1件の例外も出さずに通過します。

2ウェイマッチングが答えるのは、請求書が発注書と一致するかどうかです。発注が履行されたかどうかには答えません。

2ウェイマッチングが適切な統制となる場合

2ウェイマッチングは、照合対象となる独立した納品イベントが存在しないあらゆる場面で適切な統制です。サービス、サブスクリプション、家賃、公共料金、保険、通信、専門家報酬は、出荷ではなく契約や料率に基づいて請求されます。受け取るものが存在しないため、入荷記録をでっち上げるしかなく、でっち上げた入荷記録は証拠のように見える分、統制がないよりも有害です。

前払い条件も同じ問題を生みます。30%の頭金は設計上、納品前に請求され、3ウェイのルールは入荷記録が存在するまでそれを保留するため、サプライヤーが出荷を遅らせるか、誰かがケースごとに統制を免除することになります。

すべての2ウェイの行の背後にある条件は同じです。価格の基準がどこかに存在し、請求書がそれを参照していなければなりません。PO番号のない請求書は2ウェイマッチングではありません。それは手順が増えただけの承認です。

入荷記録側の実際のコスト

3つ目のドキュメントは、比較するのは安く、入手するのは高くつきます。コストは3つの場所に潜んでいます。

取り込み。誰かが納品を、PO明細行・数量・日付を持つ記録に変換しなければなりません。受入システムのある倉庫ではスキャンです。ドックで紙の梱包明細書に署名する業務では、シフト終わりに人が打ち直すことになり、まさにその時間帯が最も正確さが低くなります。

タイミング。請求書は入荷記録が登録される前に届くことがよくあります。その請求書は承認済みでもなく、本当の例外でもないため、待たされます。請求書の2週間後に登録された入荷記録は、支払いの判断を待ち行列に変えてしまいます。

責任の所在。入荷記録の不一致はAPではなく、受入または購買部門に属します。入荷記録の例外はすべて、同じ上司に報告しないチーム間の引き継ぎになります。

Ardent Partnersは、同じ2024年のベンチマークセットで、請求書1件の処理にかかる総コストを$9.40、平均例外率を14%としています（Ardent Partners）。取り込み時間と独自の例外待ち行列を増やす3つ目のドキュメントは、統制コストにおける実際の費目です。

4ウェイマッチングは、入荷記録とは別のイベントである検査を追加し、支払い後に見つかった欠陥の回収が高くつく場面では、その遅延に見合う価値があります。

支払い実行後に登録された入荷記録は統制ではありません。理由コードの付いた遅延です。

各ステップの担当者

マッチングはAPの業務ですが、その根拠となる証憑はAP以外の人が作成します。この分離が、3ウェイマッチングがロジックよりも担当者の問題で失敗する理由です。

r/Accountingのある会計士は、AP側から見たこのパターンをこう説明しています。「POはほとんど発注書と一致しない……価格の差異や入荷数量の差異」があり、そのコストは「差異をサプライチェーンに伝えるのに多くの時間を失う」ことだと述べています（r/Accounting）。不一致は上流で発生し、APに届きますが、APは自分が所有していないPOや入荷記録を修正できません。

これが、入荷記録が信頼できないカテゴリで2ウェイマッチングを選ぶ理由です。誰も所有していない記録に依存する統制は、大きな音を立てて失敗するのではなく、全員が回避するようになる滞留を生み出します。製造業では、この滞留には独特の形があります。製造業のAPで3ウェイマッチングが失敗するのは、請求書が届く前から始まる理由があるからです。

今週から実践できる判断チェックリスト

マッチングレベルは台帳全体で一度に決めるのではなく、支出カテゴリと金額帯ごとに設定しましょう。6つのステップで、説明責任を果たせるポリシーに到達できます。

抽出が計算を変える場所

抽出はマッチングレベルを選ぶものではありません。選択の根拠となるドキュメントのコストを下げ、それが答えを変えることがあります。入荷記録側でコストがかかるのは、紙の梱包明細書を行に変換する部分であり、比較自体は数秒で終わります。入荷ドキュメントのバッチが請求書と同じ列を持つスプレッドシートに取り込まれれば、3ウェイマッチングの限界コストが下がり、正当化するには小さすぎたカテゴリも手が届くようになります。

それがImageToTable.aiが担う層です。カスタム列抽出では、請求書番号、PO番号、請求数量、単価、明細合計、請求書合計など、必要な列名を入力すると、モデルはページ上の位置ではなく意味に基づいて各値を探します。レイアウトが指示に含まれないため、同じ列セットがサプライヤーをまたいで機能します。

計算列は計算処理を抽出に持ち込みます。差異（請求書合計 − PO合計）という列は、読み取るドキュメントに両方の数値がある場合にその差を返します。これはサプライヤーが請求書にPOを添付した場合に起こります。明細レベルのチェックも同様です。明細チェック（数量 × 単価 − 明細合計）は、計算が合わない明細行にフラグを立てます。

バッチ処理は請求書のフォルダを1つのシートにまとめ、Bbox（バウンディングボックス）レビューはセルの値が元のページのどこから来たかを示すため、数量の紛争を素早く解決できます。

スプレッドシートでの3ドキュメント版の全体像については、ERPなしでの3ウェイマッチングで台帳と数式を扱っています。Excelでの請求書とPOのマッチングでは2ドキュメントの列設計を、AP自動化ソフトウェアと抽出ステップの比較ではスコープの違いを扱っています。

正直な境界線：このツールは、PO台帳をまたいだレコードのマッチング、請求書の保留やリリース、許容範囲の適用、承認のルーティング、ERPへの転記は行いません。ドキュメントを行に変換するだけで、比較はあなたのチームに残ります。また、マッチングはサプライヤーの実在を証明するものでもありません。ACFEの2024 Report to the Nationsによると、請求スキームは職業詐欺事件の22%を占め、損失額の中央値は$100,000、発覚までの典型的な期間は18ヶ月です（ACFE）。偽のPOを持つ偽のベンダーと共謀した承認者は、あらゆるマッチングレベルを通過します。

FAQ

小規模企業に2ウェイマッチングで十分ですか？

サービス、サブスクリプション、家賃など、納品イベントを伴わない支出であれば十分です。サプライヤーが納品不足を起こしたり、到着した数量を超えて請求した物品の場合は不十分です。実務上の判断基準は履歴です。回収できなかった過払いが一度でも発生したカテゴリは3ウェイに移行し、それ以外はそのままにします。

2ウェイマッチングと3ウェイマッチングの違いは何ですか？

2ウェイマッチングは、請求書を発注書と照合し、発注数量と単価を比較します。3ウェイマッチングは入荷記録を追加し、請求数量と受領数量を比較します。入荷記録の照合により、納品不足や、到着していない物品への請求を検出できますが、これは2ウェイマッチングでは見つけられません。

2ウェイマッチングで重複請求書を検出できますか？

いいえ。重複検出は別の統制であり、請求書番号、ベンダー、金額、日付を過去の支払いと比較します。異なる請求書番号を持つ重複請求書は、2ウェイマッチングでも3ウェイマッチングでも通過してしまいます。だからこそ、別のテストではありますが、重複チェックも同じポリシーに含めるべきなのです。

2ウェイマッチングはサービスにも使えますか？

はい、発注書または契約書に業務範囲と単価が明記されている場合に使えます。入荷記録の代わりに、マイルストーンの承認や承認済みタイムシートを用います。請求書が時間単位で請求している場合は、その時間をタイムシートと照合してください。発注書だけでは水増しされた時間を検出できないからです。

2ウェイマッチングにERPは必要ですか？

いいえ。発注書番号を共有する発注書台帳と請求書台帳があればよく、中程度の件数ならスプレッドシートでも対応できます。ERPは自動の許容範囲、保留、監査証跡を追加します。ほとんどのチームは、月あたり数百件の請求書に達するあたりで手動運用の限界を迎えます。それより早く限界になることはありません。

請求内容を証明する最も安価なドキュメント

適切なマッチングレベルとは、請求書が主張する内容を反証できる最も安価なドキュメントの組み合わせです。多くのチームは低リスクの支出を過剰に管理し、納品不足が損害となるカテゴリを過少に管理しています。ポリシーが一度設定されたきり、カテゴリごとに見直されないためです。解決策は短いリストです。各請求書が何を主張しているか、どのドキュメントがそれを否定できるか、そのドキュメントの入手にいくらかかるか。

答えが誰も入力したがらない紙の梱包明細書である場合、その管理のコストはポリシーの問題である前にデータの問題です。データを安くすれば、判断は容易になります。

1枚の請求書をPOと照合する