2025年5月13日·1分で読めます

三者一致マッチ自動化：支払い保留のためのテーブルとワークフロー

PO、受領、請求書の数量と価格が一致するまで支払いを保留する、実践的なテーブル設計と視覚的ワークフローで三者一致の自動化を学びます。

三者一致マッチが実際に解決する問題

三者一致の自動化はシンプルです：発注した内容と実際に受領した内容、そして請求書が一致したときだけ支払いを行います。三つのドキュメントは、購入発注（PO）、受領記録（Receipt）、仕入先の請求書です。

このチェックがないと、経理は間違った、あるいは不完全な単一の書類に基づいて支払ってしまうことがあります。仕入先が実際より多く請求したり、合意した価格と違う価格で請求したり、メールスレッドで見た目が新しい重複請求書を送ることもあります。

こうした失敗は初日は劇的には見えません。小さな漏れとして現れます：同一ラインが二重に請求される、出荷が数単位不足している、承認されていない価格上昇、あるいは余分に課された送料。時間が経つと、それらの小さなミスは実際の金額に成長します。

目的は「請求書を承認すること」ではありません。重要なのは、あなたが選んだ主要フィールド（通常は数量、単価、合計）が PO、受領、請求書の間で揃うまで支払いをブロックすることです。一致しない場合、その請求書をメールの海に消えさせてはいけません。例外キューに入れ、明確な理由コードと差異のある正確なフィールドを示すべきです。

三者一致はチームの責任範囲を明確にします。調達は発注内容（条件や価格）を管理し、受領は到着したもの（数量や日付）を確認し、経理は支払い（請求書の確認とリリース）を管理します。

早い段階で期待値を合わせてください：これは単なる「承認ボタン」の問題ではなく、プロセスとデータの問題です。PO ラインが曖昧だったり、受領が記録されていなかったり、請求書が PO ラインに結びつかなければ、いくら自動化しても解決しません。

ドキュメントと役割：PO、受領、請求書、誰が何を担当するか

三者一致は、それぞれのドキュメントに明確なオーナーがいる場合にのみ機能します。「誰が何を更新するか」が不明瞭だと、システムは正しい支払いをブロックするか、間違った支払いを通してしまいます。

実用的な所有モデルの例：

要求者（Requester）が購入要求を作成し、必要性を確認する。
調達（Procurement）が PO を作成・維持する（仕入先、価格、条件）。
倉庫／受領者（またはサービスオーナー）が受領または受入を登録する。
AP／経理が請求書を記録し、支払いを管理する。

各ドキュメントには、マッチングが推測にならない最低限のフィールドが必要です。

PO（購入発注） には仕入先 ID、PO 番号、ライン項目（SKU やサービス）、発注数量、単価、通貨、税ルール、支払条件が必要です。

受領（Receipt） には PO 参照、受領日、PO ラインごとの受領数量、受領者が必要です。サービスの場合は受入として扱い、承認者を記録します。

請求書 には仕入先請求書番号、請求日、PO 参照（または PO を安全に見つける方法）、ライン明細（数量、単価）、税・送料、合計が必要です。

また、マッチングがいつ実行されるかを決めてください。一度きりのイベントにすべきではありません。現実が変わるたびにトリガーされるべきです：

請求書が取り込まれたとき（支払か保留かを即座に決めるため）。
受領が登録されたとき（保留中の請求書が支払可能になる可能性がある）。
PO が変更されたとき（未処理の請求書を再チェックするため）。

部分受領や複数の請求書は日常茶飯事です。PO ラインは 3 回に分けて届き、2 回に分けて請求されることがあります。ロジックは PO ラインごとの累積受領量と累積請求量を比較するべきで、単一の書類だけを見るべきではありません。

構築前に決めるルール

テーブルやワークフローステップに手を付ける前に、システム全体を動かすルールに合意してください。曖昧なルールは予測可能な失敗を生みます：システムが過度にブロックして人々が迂回するか、逆にブロックが緩くて悪い請求書が支払われてしまいます。

マッチングレベルを選ぶ。 ヘッダーのみのマッチングは書類合計をチェックします。設定は簡単に見えますが、部分納品、バックオーダー、送料ライン、混在した税率があるとすぐに破綻します。ラインレベルのマッチングは設定に時間がかかりますが、安全なデフォルトです。PO、受領、請求書の同じ行（数量、単価）を比較します。

ハードブロックと警告を定義する。 ハードブロックは問題が解決するまで支払いを進めないことを意味します。警告は請求書が前に進むが、誰かがリスクを認識して承認する必要があることを意味します。

一般的な出発点：

ハードブロック：請求数量が受領数量を超えている（商品）。
ハードブロック：単価が PO の単価を許容範囲以上に超えている。
警告：小さな端数差。
警告：税や送料の差異（予期され別処理されるもの）。

許容ルールを明確にする。 方法（％、金額、またはその両方の大きい方）と変更権限を定義してください。例：ラインあたり +/-1％または +/- $5 を許容し、許容値の変更は経理のみが監査ノート付きで行える、など。

小さな共通ステータスセットを使う。 チームごとにカスタムステータスを作りすぎないでください。一般に十分なセットは：Matched（一致）、Hold（保留）、Exception（例外）、Approved（承認済み）。“Hold” は支払いがブロックされていることを意味します。“Exception” は人がレビューする必要があることを意味します。“Approved” は特定の人物が不一致を承認し理由を記録したことを意味します。

データモデル：必要なテーブル（とその理由）

三者一致の自動化は、データモデルが PO ライン、受領されたもの、請求されたものを一致させられるときにのみ機能します。すべての請求書ラインは特定の PO ラインに結びつけられるべき（または明確に非 PO とマーク）であり、すべての受領ラインはその PO ラインの残数量を減らすべきです。

まずはコアな購買テーブルから始めます：

Vendors：仕入先ごとに 1 行（名前、支払条件、税情報）。
ItemsServices：任意だが一貫性に役立つ（SKU、説明、単位）。
PurchaseOrders：PO ヘッダ（vendor_id、currency、requested_by、status）。
PO_Lines：マッチングの基点（po_id、item_id/description、ordered_qty、unit_price）。

受領は請求書と分けて記録してください。受領を別に保持することで、いつ何が届いたかを証明できます：

Receipts：受領ヘッダ（vendor_id、received_date、location、status）。
Receipt_Lines：各ラインが PO ラインを参照（receipt_id、po_line_id、received_qty、notes）。

請求は受領に対応する形で保存します。仕入先が請求した内容をラインレベルで保存し、該当する PO ラインに結びつけます：

Invoices：請求書ヘッダ（vendor_id、invoice_number、invoice_date、due_date、status）。
Invoice_Lines：（invoice_id、対応する場合は po_line_id、invoiced_qty、unit_price、tax、line_total）。

最後に、ワークフローがブロックできる支払い向けレコードを作ります。一部のチームはこれを Bill や PaymentRequest と呼びます：

PaymentRequests（または Bills）：invoice_id に紐づき、payment_hold（true/false）や hold_reason を含む。

監査と例外処理のため、ヘッダ（PO、受領、請求書、支払い）に共通のライフサイクルフィールドを追加してください：status、created_at/created_by、approved_at/approved_by、posted_at、（任意で）source_document_id（インポート元）など。

マッチングを信頼できるものにする主要フィールドと関係性

支払い前の保留を自動化する

マッチルールが通るまで支払いリクエストをブロックし、自動で解除します。

保留を設定

各ドキュメントが同じライン項目に遡れるとき、マッチングは最もうまく機能します。つまり安定した ID、明確なリンク、そしてラインから合計を再計算できることが必要です。

各テーブルには内部的な安定 ID と、人が検索する外部番号の両方を持たせてください：

PO ヘッダ：po_id、po_number、vendor_id、currency、status、po_date
PO ライン：po_line_id、po_id、item_id または description、ordered_qty、unit_price、tax_rate、line_total
受領：receipt_id、receipt_number、vendor_id、received_date；receipt_line_id、receipt_id、po_line_id、received_qty
請求書：invoice_id、vendor_id、vendor_invoice_number、invoice_date、currency、subtotal、tax_total、total；invoice_line_id、invoice_id、po_line_id、qty、unit_price、tax_amount、line_total
仕入先・アイテム：vendor_id、payment_terms、default_currency；item_id、uom、tax_code

最も重要なのはラインレベルのリンクです：

invoice_line.po_line_id は PO ラインを指すべきです。
receipt_line.po_line_id は同じ PO ラインを指すべきです。

これにより数量と価格を推測せず比較できます。

部分対応を扱うには PO ラインごとの走行合計を計算します：received_qty（受領ラインの合計）と invoiced_qty（請求ラインの合計）。次に remaining_qty = ordered_qty - received_qty、open_to_invoice_qty = received_qty - invoiced_qty を計算します。これらの値で請求書が早すぎるか遅すぎるか、過剰請求かが明確になります。

PO を変更したときに履歴を上書きしないでください。PO の改訂番号を保存するか、古い PO ラインを残してアクティブフラグを付けるか、変更ログ（誰がいつ何を変えたか、旧値と新値）を残してください。

重複や不正な結合を防ぐための基本的なガードレールも追加します：

Unique (vendor_id, vendor_invoice_number)
Unique receipt_number と po_number
通貨、数量、単価は NOT NULL
qty >= 0 と unit_price >= 0 のチェック制約
invoice_line と receipt_line から po_line への外部キー

ステップ・バイ・ステップのワークフロー：請求書受領から支払い保留まで

三者一致の自動化は通常、請求書到着（メール、アップロード、EDI）、受領の登録、または PO の変更という三つの入口があります。ワークフローはこれらのどれに対しても反応し、欠けていた情報が揃ったら請求書が自動で保留解除されるべきです。

1) まず請求書の基本を検証する。 仕入先が有効か、PO が存在するか、通貨が PO と一致するか、合計が内部的に整合しているか（ライン合計が合う、税が妥当、負の数量がないこと）を確認します。失敗した場合は明確な理由で即座に Hold に送ります。

2) ヘッダーだけでなくラインごとにマッチする。 各請求書ラインについて関連する PO ラインとこれまでの受領累計を見つけ、比較します：

請求数量 vs 受領数量（または既に請求済み分を差し引いた受領）
請求単価 vs PO の単価
許容ルール
PO ラインがまだ請求可能かどうか

3) ステータスを設定しブロックを適用する。 一般的なパターン：

Matched：すべてのラインがチェックを通り、例外がない。
Hold：少なくとも一行が失敗した、または必要なデータが欠けている。

Hold が設定されたら、支払いランが従うべき支払保留レコードを作成します。保留は請求書と分離して管理し、保留の追加・解除・置換をしても請求書履歴を書き換えないようにします。

4) 経理が信頼できる理由コードを記録する。 フリーテキストだけの保留は避けてください。PRICE_OVER_TOLERANCE、QTY_NOT_RECEIVED、PO_CLOSED、VENDOR_MISMATCH、CURRENCY_MISMATCH のようなコードと短いメモを併記します。

経理向けの例外キュー設計（何を保存し何を表示するか）

部分受領を正しく処理する

PO ラインごとの受領累積と請求累積を追跡し、部分受領を正しく扱います。

ワークフローを作る

例外キューは、マッチングを単なる報告から実用的なものに変える場所です。経理は決定を下すために最小限の情報で十分に判断でき、かつ監査トレイルが残るべきです。

一般的には ExceptionCases のような専用テーブルを用意します。各行はブロックされた請求書（または請求書ライン）を表し、請求書、PO、受領レコードを参照します。マッチングエンジンは読み取り専用にしておき、キューは判断と記録の場所にします。

`ExceptionCases` に保存すべき項目

何が問題でどれくらいの差があり、誰が担当し次に何が起こるかを保存します：

Type（受領欠落、価格差、数量差、PO 未発見、重複請求の疑い）
Severity（info、warning、block）とユーザ向けの理由説明
Owner（担当者またはチーム）とステータス（open、waiting on vendor、waiting on warehouse、resolved、overridden）
差分のスナップショット（請求額、マッチ額、価格差、数量差）
SLA フィールド（期日、エスカレーションフラグ、reassigned_at、reassignment_reason）

また、コラボレーションや監査用のデータも保存します：コメント（作成者、タイムスタンプ）や添付ファイルのメタデータ（ファイル名、種別、uploaded_by、uploaded_at）。ファイル自体が別の場所にあっても、メタデータはケースに残して履歴を保ちます。

経理が見るべきもの（および操作）

キューのビューはタイトな作業リストであるべきです：仕入先、請求書番号、例外タイプ、重大度、金額、期日、担当者、そして「なぜ保留か」の明確なメッセージ。

ケースを開くと、PO ライン、受領数量、請求書ライン、失敗した具体的フィールドが横並びで見えるべきです。

操作は限定して安全に保ちます：

受領を依頼（受領チームへルーティングしステータスを waiting にする）
クレジットメモを依頼（仕入先へルートし想定調整を記録）
オーバーライド承認（理由必須、承認者とタイムスタンプを記録）
再割り当て（担当を更新し履歴を保持）
解決としてクローズ（変更後にマッチが通ったときのみ）

例：受領が 8 単位、請求が 10 単位なら、経理は「残り 2 単位」を理由に修正請求を依頼するか、受領 8 単位分だけを承認して残り 2 単位を保留にすることができます。

現実的な例：部分受領と不一致の請求書

ドラッグ＆ドロップでマッチングロジックを作る

ラインレベルのチェック、許容値、再実行トリガーを視覚的プロセスで構築します。

ロジックを作る

買い手が商品 A を 100 単位、単価 $10.00 で PO を作成しました。PO 合計は $1,000 です。2 日後に倉庫が 80 単位の受領を登録しました。

その後、100 単位で請求書が届いたとします。マッチは「発注された量」だけでなく「これまで受領された量」と請求を比較すべきです。

そのラインでは：

発注：100 単位
受領：80 単位
請求：100 単位
マッチした数量：min(受領, 請求) = 80 単位
未マッチ数量：請求 - マッチ = 20 単位

請求書は「保留」になります。なぜなら 20 単位に対応する受領がないからです。経理は数量差（+20）という明確な理由が表示されたケースを見ます。

通知は問題を最も早く解決できる人に送ります：通常は受領側（受領漏れを確認）と買い手（出荷が不足しているかを確認）です。

残りの 20 単位が届いたら、倉庫が 20 単位の受領を登録します。システムは再度マッチを実行し、受領が 100 になり未マッチが 0 になれば請求書は Matched となり保留は解除されます。

価格差を加えると：仕入先が 100 単位を $10.50 で請求した場合、数量は一致していますが単価が合いません。期待される結果は請求書を保留し「単価差：+$0.50/単位（合計 +$50）」のような理由でルーティングすることです。

三者一致ワークフローを破綻させるよくあるミス

ほとんどの失敗は数学の問題ではなく、弱いデータリンクと公開済みドキュメントの管理の甘さから来ます。

請求書合計だけでマッチする。 ヘッダーだけを見ていると、ある行が高すぎたり不足していたりしても見逃します。ラインレベルでマッチし、異なってよいもの（多くの場合送料）と許されないもの（受領数量や単価）を明確にします。

1 つの受領と 1 つの請求だけを想定する。 実際の購買は分割出荷や部分請求が含まれます。同じ PO ラインに対して複数の受領や複数の請求をサポートし、ラインごとの残数量を追跡してください。

登録済み受領や請求書をトレイルなしに編集できる。 誰かが後から数量をこっそり変えられると、マッチングは証拠になりません。登録済みレコードはロックし、訂正は変更履歴を残す調整書類で行ってください。

重複防止の欠如。 同一仕入先請求書番号が二重に入力されたり、PDF が別の人によって再アップロードされることがあります。早い段階でユニーク制約（vendor + invoice number、場合によっては日付/金額）を追加し、重複検出時は明確なメッセージを表示してください。

曖昧な例外理由。 経理に推測させてはいけません。価格不一致、数量不一致、受領欠落、重複疑い、PO 未発見、仕入先不一致のような理由コードを使って明確にルーティングします。

支払いブロックを有効にする前のクイックチェックリスト

監査対応のオーバーライドを追加する

請求書履歴を書き換えずに、誰が不一致を承認したか、いつ、なぜを記録します。

承認を追加

支払いブロックはマッチングが報告から統制へ変わるポイントです。基本が整っていないと経理にノイズを作り、仕入先への支払い遅延を招きます。

少数の異なる請求書でテストしてください：クリーンに一致するもの、部分受領、価格変更、税差分。どれかがきれいにマッチできなければ、まずデータとルールを直してください。

チェックリスト：

参照の完全性： すべての請求書に仕入先と PO 参照があり、各請求書ラインが特定の PO ラインにマップできる。仕入先がヘッダ番号しか出さない場合の扱いを決める。
計算の一貫性： 数量、単価、合計が毎回同じ方法で再計算される。税、送料、割引、端数処理（ラインごとに丸めるか合計で丸めるか）を明確にする。
ステータスが十分に早くブロックする： 支払いリクエストや支払処理レコードが作られる前に "on hold" を設定する。
構造化された例外： すべての保留は理由コードと担当者（AP、買い手、受領）を保存する。期日を入れて保留が放置されないようにする。
監査証跡： オーバーライドは誰がいつ何を承認したかを記録する。編集を許す場合は編集前後の値をログに残す。

次のステップ：プロセスをパイロットし、視覚的に構築する

三者一致の自動化は他の統制と同様に扱ってください：まず小さなスコープで動作を証明し、それから展開します。

監視しやすいパイロットから始めます。1 つの事業部、クリーンな請求書を送る小さな仕入先群、または単一の品目カテゴリを選びます。最初はルールを厳しく（数量と価格の完全一致）してデータ品質の問題を早く露呈させます。

成功はシンプルな経理ビューで測定します：週あたりの保留数、上位の理由コード、保留から解除までの時間、実際にミスマッチだった保留の割合、繰り返し例外を出す仕入先。

素早くプロトタイプしたい場合、ノーコードプラットフォームが役立ちます。テーブル、マッチングルール、ルーティングをコードなしでモデリングできます。例えば AppMaster (appmaster.io) では PO、受領、請求書、例外のテーブルを作り、視覚的なビジネスプロセスで保留ロジックを繋げれば、同じルールがトリガーごとに実行されます。

パイロットグループの実際の請求書（部分受領やよくある仕入先ミスを含む）でテストしてください。パターンを見てからマッチングキーを調整し、小さな許容値は状況を見てから追加するのが良いでしょう。保留の振る舞いが妥当で解決時間が短くなれば、適用範囲を広げ、税や送料、単位換算、分割出荷などの複雑さを段階的に追加しても、コアの統制は変えないでください：マッチがクリアされるまで支払いはリリースしない、という原則です。