Google Sheetsでスリーウェイマッチングパイプラインを構築する方法：
POから請求書承認までのステップバイステップ

スリーマッチングに実際に必要なもの — 許容範囲の設定だけではない

スリーマッチングとは、支払いを承認する前に発注書、入庫伝票、仕入先請求書を照合し、発注内容と入庫内容、請求内容が一致するかを確認するプロセスです。ISO 9001:2015 第8.4項では、認証を受けた製造業者に対し、購入した製品が指定された要件を満たしていることの検証が義務付けられており、多くの企業がこれを満たすためにスリーマッチングを運用しています。ACFE「2024 Report to the Nations」（組織は年間収益の5%を職業上の不正により失うと推定）は、これを請求書不正に対する主要な対策として挙げています。規制上の論理は妥当です。しかし、その根底にあるデータの問題が、実務で機能不全を引き起こしています。

スリーマッチングの改善に関するアドバイスのほとんどは、照合レイヤーに焦点を当てています。すなわち、許容範囲の厳格化、承認ワークフローの追加、ERPでの自動照合ルールの設定などです。しかし、これらはいずれも、3つの文書が3つの異なるシステムから異なる形式で届き、そのうち2つが非構造化データであるという根本的な問題を解決しません。発注書は購買システムに存在します。入庫伝票は紙の納品書から入力されたかどうか定かではありません。仕入先請求書はPDFで届きます。照合ロジックがこれらの文書を比較する前に、構造化されていない2つの文書からデータを抽出し、比較可能な形式に変換し、単位や明細行が一致することを確認する必要があります。VLOOKUPやIF文、条件付き書式といった照合レイヤーは簡単な部分です。パイプラインの成否を分けるのは、データ抽出レイヤーです。

ERPのアドバイスがスプレッドシートのワークフローに合わない理由

SAPのMMモジュール、Oracle E-Business Suite、Microsoft Dynamics 365 — いずれも設定可能な許容範囲を持つスリーウェイマッチングモジュールを備えています。例えばSAPは、GR/IRクリアリング勘定を通じてマッチングを処理します。入庫報告書（トランザクションMIGO）は借方に計上され、請求書受領（MIRO）は貸方に計上され、システムは一致した明細行を自動的に消し込みます。このロジックは成熟しており、十分に文書化されています。

しかし、このロジックは、かなりの数の購買業務において当てはまらない前提に基づいています。それは、マッチングロジックが実行される前に、3つの文書すべてがERP内に構造化された比較可能なデータとして存在するという前提です。2025年のIFOL AP自動化トレンド調査によると、APチームの66%が依然として請求書データをERPに手入力しています。50〜200社の仕入先とのサプライヤー関係を管理する購買チーム — その多くはPDFをメールで送信する小規模な機械工場、地域の販売代理店、専門サプライヤーです — にとって、すべての請求書は、マッチングを開始する前に手入力のデータ入力イベントとなります。

もしあなたがそのグループに該当する場合 — 会社がスプレッドシートで購買を管理している、ERPの請求書取り込みにサプライヤーごとのテンプレート設定が必要でそれを維持する余裕がない、または仕入先基盤にPDFのみで送信する小規模ベンダーが十分に含まれている — その場合、ERPのマッチングモジュールは、あなたが実際に抱えている問題の下流にある問題に対処していることになります。より良いマッチングアルゴリズムは必要ありません。必要なのは、POデータ、入庫データ、請求書データを1つの構造化されたビューにまとめる方法です。そして、購買追跡にすでに使用しているツールは、おそらくスプレッドシートでしょう。問題は、そのスプレッドシートをパイプラインに変える方法です。

3層パイプラインアーキテクチャ

パイプラインには3つの層があります — スリーウェイマッチングの各文書に1つずつ — そして、その上に位置する4つ目の層、マッチングダッシュボードがあります。最初の3つの層は、非構造化文書から構造化データを抽出します。4つ目の層はそれらを比較します。最初の3つの層のいずれかが一貫性のないデータや不完全なデータを生成した場合、マッチング層はその役割を果たせません。アーキテクチャは、最も弱い抽出層と同じ強さしかありません。

各レイヤーは、調達から支払いまでのチェーンにおける特定のギャップを埋めます。POレイヤーは基準を確立します。何を、どの価格で、誰から注文したかです。入庫レイヤーは、物理的に何が到着したかを確認します。請求書レイヤーは、仕入先が請求した内容を捉えます。マッチングダッシュボードは、これら3つがすべて収束する場所であり、従来のマッチングワークフローにおける構造的な弱点として問題分析で特定された3部門にわたる調査を、スプレッドシートが置き換える場所でもあります。

レイヤー1と3で非構造化から構造化への変換を実現するツールがCustom Column Extractionです。各文書のフィールドに枠を描いたり、仕入先フォーマットごとにテンプレートを作成する代わりに、必要な列名（「PO番号」「仕入先名」「明細行」「数量」「単価」「行合計」）を入力するだけで、AIが文書を読み取り、それらの値がページ上のどこにあるかではなく、何を意味するかを理解して見つけ出します。SAPのPDF出力からの構造化POと、地元の仕入先からの手書きPOは、まったく似ていません。しかし、どちらにもPO番号、仕入先名、数量、価格が含まれています。列名抽出は、あらゆるレイアウトにわたってこれらのフィールドの意味を検索するため、数十種類の仕入先文書フォーマットを扱う調達チームにとってテンプレートベースのOCRを非現実的にする、仕入先ごと・フォーマットごとのテンプレート保守を排除します。

レイヤー1 — 購買発注書の抽出：照合の基準点

スリーウェイマッチングは、すべて購買発注書から始まります。POが条件を定めます。どの仕入先から、どの品目を、どの数量・価格で、いつ納品してもらうか。ERP統合環境では、このデータはすでに構造化された明細行として存在します。POはシステム内で作成されているからです。しかし、スプレッドシートベースの調達ワークフローでは、POは複数の形式で届きます。自社システムが生成したPDF、仕入先が注文確認として送ってくるメール添付のPO、紙ベースで運用している小規模ベンダーからのスキャン文書などです。POデータを構造化形式に変換することが最初のステップであり、スプレッドシートベースのチームにとっては、以降のパイプライン全体が成立するかどうかを左右するステップです。

POの抽出列は、照合プロセスで参照する必要がある項目によって決まります。最低限、以下の項目が必要です。

社内で一貫した形式（自社のPOテンプレート）で生成される購買発注書の場合、抽出は簡単です。AIは毎回同じレイアウトから同じフィールドを読み取ります。仕入先の形式で届く確認用POの場合も、抽出は柔軟に対応します。列名は同じままで、AIはレイアウトに関係なく値を特定します。1回の抽出実行で、PO台帳タブに構造化データが入力されます。POごとに1行、または明細行ごとに1行です。照合にヘッダーレベルと明細レベルのどちらの粒度が必要かによって異なります。Google Sheetsアドオンによる単一PO抽出ガイドでは、列の設定と最初の抽出ワークフローを説明しています。多数のPOを一度に処理する高稼働チーム向けには、バッチPO処理ダッシュボードで、1回のセッションで複数のPOに同じ抽出エンジンを適用できます。

上記のデモでは購買発注書プリセットを使用しています。これはPO文書用に事前設定された抽出列のセットです。購買発注書をアップロードすると、入力なしでフィールドが自動入力されるのを確認できます。POにプリセットがカバーしていないフィールド（商品サーチャージ行、運送条件セクション、内部コストセンターコードなど）が含まれている場合は、カスタム列として追加してください。抽出エンジンはそれらを同じ方法で処理します。プリセットが出発点を提供し、カスタム列でマッチングダッシュボードの要件に合わせて拡張できます。

レイヤー2 — 入庫報告書データ：扱いが難しい中間文書

入庫報告書は、構造化されたシステムに存在しないことが最も多い文書です。そして、スリーウェイマッチングを3つの文書によるプロセスにしているのもこの文書です。入庫確認がなければ、ツーウェイマッチング（POと請求書）しかできず、納品が確認できない商品に対して支払いを行うことになります。ACFEは特に、入庫報告書を請求詐欺（納品されていない商品への支払い）を防ぐ統制として特定しています。これを省略することは近道ではありません。統制フレームワークの欠陥です。

入庫データは、その作成方法のためにPOデータよりも構造化が困難です。荷受け場で、多くの場合紙ベースで、トラックの荷降ろしが優先でデータ入力が後回しになるスタッフによって作成されます。梱包明細書は通常、複写式のカーボン紙か、運送会社のサーマルプリント文書です。受入担当者はそれに署名し、受入数量（POと単位が異なる場合もあります）を記録し、紙のコピーをファイルします。そのデータがデジタルシステムに入るかどうかは、後で誰かが手入力するかどうかにかかっており、そのステップが繁忙期の受入日に最初に省略されるものです。

パイプラインにとって、入庫データには2つの実行可能な入力経路があります。1つ目は直接手動入力です。受入担当者、または指定されたデータ入力担当者が、受入ワークフローの一環として主要フィールドをGoogle Sheetに入力します。列はPO列を反映しています：PO番号（関連付け用）、受入品目、受入数量、受入日、運送会社、状態。この経路は、受入量が中程度（1日30件未満の出荷）で、荷受け場にSheetsを開いたデバイスがある場合に有効です。利点は管理性です。受入データは入力時点で構造化され、後続の変換が不要です。

2つ目の方法は、梱包明細書自体からの書類抽出です。署名済みの梱包明細書を写真に撮るかスキャンし、購買発注書や請求書に使用しているものと同じ抽出エンジンに通します。この方法は、手入力が現実的でない場合に有効です。大量の荷物を扱うドック、遠隔地の受入拠点、または梱包明細書が唯一の受入記録となる現場などです。抽出列は同じです。PO番号、品目説明、受入数量、受入日、運送会社です。サイドバーアドオンで処理した梱包明細書の写真は、手入力データと同じ構造化形式で受入タブに入力されます。主な制限は、梱包明細書の手書き文字が、印刷された購買発注書や請求書と比べて抽出精度を低下させることです。重要な出荷については、スポットチェックをお勧めします。文書品質別の詳細な精度内訳については、手書き文書の抽出精度に関するガイドをご覧ください。同じ原則が梱包明細書や入庫報告書にも適用されます。

どちらの方法を使用しても、出力は同じです。PO番号をキー項目とする受入台帳タブが作成され、各受入を元の購買発注書にリンクします。このリンクがなければ、マッチングダッシュボードは機能しません。

レイヤー3 — 仕入先請求書の抽出：制御できないフォーマット問題

フォーマットの多様性問題が最も顕著になるのが仕入先請求書です。単一の購買業務でも、大手MRO販売代理店からは構造化されたSAP生成PDF、地域の金属サプライヤーからは独自のExcel-to-PDF形式、地元の機械工場からは手書き文書の写真、海外ベンダーからは日付形式、通貨表記、税行構造が異なる請求書を受け取る可能性があります。テンプレートベースのOCR（各サプライヤーのレイアウトに合わせてフィールドマッピングテンプレートを作成し、レイアウトが変更されるたびに更新する方法）は、この多様性の前で機能不全に陥るか、メンテナンスに多大な時間を費やし、置き換えるはずだった手入力と同じだけの労力が抽出作業にかかってしまいます。

Custom Column Extractionは、抽出ロジックを特定のレイアウトから切り離すことでこの問題を解決します。列名は一度定義するだけです。AIが各請求書をフォーマットに関係なく読み取り、その列定義に一致する値を見つけ出します。スリーウェイマッチング用の請求書列設定には、通常以下の項目が含まれます。

また、推論列を追加することもできます。これは請求書に明示的に印刷されていないが、そのコンテキストから導出可能なデータを取得する列です。たとえば、マッチングステータス（選択肢：マッチング準備完了/PO参照が必要/明細行不足）として定義された列により、AIは抽出時にPO番号の有無や明細行の抽出可能性に基づいて各請求書を分類できます。PO番号を文書に含めない仕入先からの請求書は即座にフラグが立てられ、「PO参照が必要」ステータスでマッチングダッシュボードに表示されます。AP担当者はPO番号が追加されるまでマッチングを試みないことを認識します。これは抽出としての分類です。分類判断はデータを入力する同じパスで行われ、別途のレビューステップは不要です。

計算列は、抽出後にスプレッドシートの数式を必要とする計算を処理します。列を延長チェック（明細行合計 - 数量 × 単価）として定義すると、AIが抽出中に計算を実行し、請求された明細行合計が数量×単価と一致しない行にフラグを立てます。出力は差異の数値です。ゼロは延長が正しいことを意味し、ゼロ以外の値は仕入先請求書の算術エラーを特定します。これにより、マッチングダッシュボードの役割は「エラーを見つける」から「フラグが立てられた行を確認する」へと移行します。これは、AIが検出を行い、人間が処理を判断するワークフローです。計算列の構文と機能の詳細については、文書抽出における計算列のガイドをご覧ください。

スリーウェイマッチングパイプラインを支える同じ請求書抽出レイヤーは、より広範な仕入先からAPへの請求書パイプラインのエンジンでもあります。列構造は異なりますが、抽出メカニズムは同一です。マッチング用に構築された同じパイプラインは、APレポート、未払金計算、監査文書にも活用されます。

マッチングダッシュボード：VLOOKUP、IF、条件付き書式

PO台帳、入庫台帳、請求書台帳の3つのレイヤーがすべて入力されると、マッチングダッシュボードはそれらが集約される場所になります。これは、ルックアップ関数を使用して3つのソースタブすべてからデータを取得し、比較ロジックを適用してマッチ、差異、欠落データにフラグを立てる単一のタブです。マッチングロジック自体は複雑ではありません。スプレッドシートで実行できます。常に複雑だったのは、スプレッドシートがそれを実行できる状態にデータを整えることです。そして、その課題を解決するのがこのパイプラインです。このパイプラインの照合に焦点を当てた対応物（許容範囲ルール、自動マッチゾーン、曖昧な品目説明に対する人間の判断レイヤー）については、ERPなしでGoogle Sheetsでスリーウェイマッチングを行うためのガイドをご覧ください。

Google Sheetsで構築されたマッチングダッシュボードの構造：

条件付き書式でテーブルをダッシュボードに変身させます。列Nは「MATCHED」なら緑、「NO RECEIPT」なら琥珀色、「VARIANCE」なら赤で強調表示します。列J（数量差異）が設定可能なしきい値（バルク材は5%、高額なエンジニアリング部品は2%）を超える行には赤い枠線を適用します。上部に行集計を追加します。=COUNTIF(N:N,"MATCHED")で一致した請求書をカウント、=COUNTIF(N:N,"VARIANCE")で例外をカウント、=SUMIF(N:N,"VARIANCE",L:L)で差異の合計金額を算出します。

重要な設計上の判断は、PO番号をユニバーサルキーとすることです。照合ダッシュボードのすべてのVLOOKUPはPO番号列を参照します。サプライヤー請求書にPO番号がない場合（照合問題の分析で、これが照合失敗の最も一般的な根本原因であることが確認されています）、行はすべてのVLOOKUP列で#N/Aエラーとなり、ダッシュボードですぐに確認できます。修正は簡単です。請求書レジスタ行にPO番号を追加すれば、数式が再計算されます。しかし、可視性こそが重要です。ダッシュボードがなければ、PO番号のない請求書は誰かが気づくまでキューに滞留します。ダッシュボードがあれば、行が入力された瞬間にフラグが立ちます。

部分納入（1つのPOが複数の出荷をカバーする製造調達で最も一般的な複雑性）については、受入レジスタと請求書レジスタの両方に「納入番号」列を追加します。VLOOKUPは2キー検索になります。PO番号と納入番号で照合します。各部分納入は独自の照合行を持ち、累積受入計算（=SUMIFS(F:F, A:A, A2, [Delivery], "<="&[@Delivery])）は、すべての部分出荷にわたってPO総数量のうちどれだけが納入されたかを追跡します。同じロジックで、ロールリング月次リリースのあるブランケットPOも処理できます。ダッシュボードは、PO総承認額に対する累積数量を追跡します。

Collection Link — 仕入先が直接書類を提出できるようにする

スリーウェイマッチングにおける慢性的な非効率のひとつが、仕入先からAPチームへの書類の受け渡しです。仕入先は請求書をメールで送信します。AP担当者は添付ファイルをダウンロードし、共有ドライブやローカルフォルダに保存してから、抽出ツールにアップロードします。このダウンロードと再アップロードのサイクル自体はボトルネックではありませんが、50社の仕入先から毎月100件以上の請求書を処理する場合、余分な手順が摩擦を積み重ねることになります。

Collection Linkは、その中間ステップを排除します。これは、仕入先に送信する共有可能なURL（/c/xxxx形式）です。仕入先はリンクを開き、ページに表示される短い確認コードを入力して、請求書を直接アップロードします。アカウント作成もログインもソフトウェアのインストールも不要です。ファイルは自動的にアカウントの処理キューに登録され、使用されたリンクによって仕入先が識別されます。仕入先ごとに（または仕入先グループごとに）個別のCollection Linkを作成できるため、抽出が始まる前に、受信ファイルが送信元ごとに事前分類されます。

スリーウェイマッチングのパイプラインに適用すると、Collection Linkは書類の流れを「仕入先が請求書をメール送信 → ダウンロード → アップロード → 抽出」から「仕入先が直接アップロード → ファイルがキューに表示 → 抽出」に変えます。ダウンロードと再アップロードのステップを完全に排除します。同じ出荷に対する梱包明細書と請求書など、複数の書類を送信する仕入先の場合、1つのCollection Linkで両方のファイルを取得でき、抽出エンジンはシート内の列定義に従って各書類を処理します。詳細な設定とワークフローについては、抽出による書類収集ガイドをご覧ください。

本パイプラインで置き換わるもの、置き換わらないもの

パイプラインとは、「この一連のステップがこの出力を生み出す」という具体的な主張です。ここで説明するパイプラインが何を置き換え、何を補完し、そもそも何を目的としていないのかを正確に理解することが重要です。

置き換わるもの：

• 発注書や請求書からの手動データ入力。 抽出レイヤーが非構造化文書を構造化された行に変換します。発注明細や請求書項目を追跡シートに手入力する作業が不要になります。
• 仕入先ごとのOCRテンプレート管理。 列名抽出機能があらゆる文書レイアウトを読み取るため、事前設定テンプレートは不要です。新規仕入先はコレクションリンクを送るだけで登録完了。テンプレート作成は必要ありません。
• 3部門にわたる調査ループ。 発注データ、受入データ、請求書データが1つの構造化ダッシュボードに集約されれば、「請求書は発注書と一致するか？」という問いは、条件付き書式のセルを見るだけで解決します。購買部門や入荷 dock に電話する必要はありません。
• 書類不足による死角。 ダッシュボードのVLOOKUP構造は、ギャップを即座に露呈します。発注VLOOKUPで#N/Aが出れば、請求書が有効な発注書を参照していないことを意味します。受入数量が空白なら、入庫が未登録です。これらは月次監査で発見されるものではなく、すべての行でリアルタイムに可視化されます。

置き換わらないもの：

• ERPシステム（必要な組織向け）。 月間2,000～3,000件の請求書を処理する場合、スプレッドシートベースの照合ダッシュボードは実用限界に達します。例外処理のボリュームが手動レビューを圧倒します。この規模では、自動照合、統合監査証跡、職務分掌の強制といったERPの価値が必須となります。本パイプラインはERPに構造化データを供給しますが、統制環境としてのERPを置き換えるものではありません。
• 例外に対する人間の判断。 ダッシュボードは差異をフラグ付けしますが、解決はしません。請求単価と発注単価の47.50ドルの差は、購買チームが交渉したが買掛金部門に伝えていなかった正当な追加料金かもしれませんし、エラーかもしれません。AIにはどちらか判断できず、判断を委ねるべきでもありません。フラグは人間によるレビューをトリガーします。そのレビューには、AIが持たないビジネスコンテキストが必要です。
• 入庫プロセスそのもの。 入庫が作成されていない場合、つまり dock で到着品が記録されていない場合、パイプラインは受入タブでそのギャップを明らかにしますが、データを生成することはできません。受入レイヤーにはプロセス規律が必要です。誰かが納品されたものを確認し記録しなければなりません。パイプラインはそのデータを構造化しますが、無から作り出すことはしません。
• 仕入先による請求書への発注番号記載の遵守。 パイプラインは発注番号の欠落を可視化しますが、仕入先に番号を記載させることはできません。それには、技術的解決策ではなく、購買ポリシーとその執行が必要です。

よくある質問

このパイプラインは月に何件の請求書を処理できますか？

構造上の限界は抽出エンジンではなく、マッチングダッシュボードの手動レビュー容量にあります。適切に構築されたマッチングダッシュボードを使用すれば、1人のAP担当者が差異の確認と処理を快適に行えるのは、月に約300～500件の請求書が目安です（例外率22％の場合、調査対象は66～110件）。月1,000件を超えると、例外処理のボリュームが増大するため、複数のAP担当者を配置するか、自動マッチングルールを持つERPへの移行が必要になります。高ボリュームでは、このパイプラインの価値は「主要なマッチングツール」から「構造化データをERPに供給するデータ取り込みエンジン」へと移行します。抽出レイヤーは引き続き機能し、ダッシュボードは最終的なマッチング環境ではなく、ERPへの事前検証ステップとなります。

POが毎月変動する包括価格を使用している場合、パイプラインは変動価格に対応できますか？

はい。ただし、POレジスターを一度限りの抽出ではなく、生きた文書として維持する必要があります。商品市況に連動して毎月価格が調整される包括POの場合、その仕入先のPOレジスター行を毎月、その時点の有効価格で更新する必要があります。マッチングダッシュボードのVLOOKUPは更新された価格を反映します。監査証跡を残すもう一つの方法は、POレジスターに「有効日」列を追加し、日付範囲マッチングでVLOOKUPを使用することです。現在の価格ではなく、請求書日付時点で有効だったPO価格を取得します。設定は複雑ですが、出荷時に合意された価格を正確に反映するため、三者照合の本来の検証目的に適っています。

手書きの納品書や受領書でも抽出は機能しますか？

はい。AIは手書き文字を読み取ります。ドックでサインされた納品書に典型的な数字や記述も含みます。ただし、手書き文書の精度は印刷文書より低く、劣化の激しい文書（かすれた感熱印刷、薄い文字のカーボンコピー、しわくちゃで伸ばした納品書）では抽出エラーが増加します。受領データについては、以下をお勧めします。(a) 可能であれば、受領担当者がドックで主要項目（PO番号、品目、数量、日付）を直接Googleスプレッドシートに入力する。受領時点での手入力は、後日劣化文書から抽出するより速く正確です。(b) 納品書からの抽出が唯一の方法である場合、特に高額な出荷については、抽出行のサンプルを元の文書と照合してください。(c) 納品書の写真を受領行と一緒に添付ファイルとして保存する。抽出で数字を逃しても、元の文書をワンクリックで確認できます。

このパイプラインをGoogle Sheetsアドオンなしで、Webアプリだけで使用できますか？

はい、可能です。抽出エンジンは、Sheets内のサイドバーアドオンからアクセスする場合も、ImageToTable.aiのWebアプリケーションからアクセスする場合も同じです。アドオンの利点は、抽出結果がアクティブなシートに直接書き込まれることです。ダウンロードして再アップロードする手間がありません。Webアプリでは、ブラウザでドキュメントをアップロードし、抽出されたExcelファイルをダウンロードして、行をマッチングダッシュボードに貼り付けるかインポートします。列定義は同じです。抽出品質も同じです。アドオンは1つのステップ（ダウンロードとインポート）を省きます。WebアプリはGoogle Sheetsだけでなく、あらゆるスプレッドシートツールで動作します。その1つのステップがお客様のボリュームにとって重要かどうかで選択してください。

完全なパイプライン（POレジスタ、入庫レジスタ、請求書レジスタ、マッチングダッシュボード）のセットアップ時間はどのくらいですか？

Google SheetsでVLOOKUPと条件付き書式に慣れている方であれば、完全な4タブのパイプラインの構築にはおよそ2時間かかります。上記の列構造を持つ4つのタブの設計と作成に30分、マッチングダッシュボードでのVLOOKUPとIF数式の作成とテストに45分、条件付き書式とサマリーメトリクスの設定に30分、アドオンサイドバーでの抽出列セットの定義に15分です。列定義はシートに保存され、セッションをまたいで保持されます。一度定義すれば、サイドバーを開いてそのシートを選択するたびに利用できます。初期設定後、毎月のワークフローは次のとおりです：（1）新しいPOをPOレジスタに抽出する、（2）入庫データを入力または抽出する、（3）仕入先請求書を抽出する、（4）マッチングダッシュボードを開いてフラグが付いた行を確認する。最初の月はセットアップとデータ投入のため最も時間がかかります。3か月目には日常的になります。対応フィールドタイプ、形式、プラン詳細などの完全な機能の概要については、Google Sheetsへの抽出ページをご覧ください。

POと仕入先請求書の通貨の違いにはどう対応すればよいですか？

抽出エンジンは、文書に表示されている数値と通貨記号をそのまま取得します。通貨換算は行いません。POがUSDで、仕入先請求書がEURの場合、換算後の値が正しくても数値が一致しないため、マッチングダッシュボードには差異が表示されます。解決策は、PO台帳と請求書台帳の両方に「通貨」列を追加し、手動または数式で管理される為替レートを参照する「換算レート」列を追加することです。これにより、マッチングの価格比較では、抽出された生の金額ではなく換算後の金額が使用されます。パイプラインの役割は抽出です。通貨換算はスプレッドシート側の操作です。

まとめ

ここで説明したスリーウェイマッチングパイプラインは、ERPが必要な組織にとってのERPの代替品ではありません。これは、すでにスプレッドシートで購買業務を管理しているチームのためのシステムです。ERPの請求書取り込みに維持できないテンプレート管理が必要な場合、仕入先のフォーマットが多様でマッチングモジュールが対応できない場合、または取引量が「手動マッチングには複雑すぎる」と「ERPアップグレードを正当化できるほど大規模」の間にある場合です。そのようなチームにとって、問題は「マッチングを自動化すべきか」ではありません。「3つの文書すべてを、マッチングが3部門の調査ではなく数式の作業になるほど迅速に同じ構造化フォーマットに変換できるか」です。

パイプラインは、3つの抽出レイヤーと1つのダッシュボードでこの問題に答えます。POレイヤーは基準となるベースラインを提供します。入庫レイヤーは到着したものを確認します。請求書レイヤーは請求されたものを取得します。マッチングダッシュボードは、VLOOKUP、IFステートメント、条件付き書式を使用してそれらを比較し、人間の注意が必要なすべての行にフラグを立てます。位置ではなく意味で文書を読み取るAIを搭載した抽出エンジンは、複数仕入先の購買業務でテンプレートベースのアプローチを持続不可能にするフォーマットの多様性を処理します。Collection Linkは、文書取り込みプロセスからメール添付ファイルのダウンロードループを排除します。

私たちの問題分析で特定された構造的なギャップ（3つの部門、3つのシステム、データパイプラインの単一の所有者がいない）は消えません。しかし、3種類すべての文書が同じ構造化フォーマットで同じスプレッドシートに、同じPO番号を共通キーとして届けば、マッチングのステップに部門間の調査は不要になります。組織的なギャップは残ります。データはもはや3つの異なる入力チャネルの蓄積されたドリフトを保持しません。それが、マッチングを人員問題ではなくスプレッドシートの作業にする理由です。

PO抽出レイヤーから始めましょう。以下のデモで購買発注書をアップロードしてください。マッチングワークフローに重要なフィールド（PO番号、仕入先、明細行、数量、価格）が、手入力の数分ではなく数秒で構造化されて返されるかどうかを確認してください。最初のレイヤーが機能すれば、パイプラインの残りは同じエンジンで構築されています。