ERPなしで実現する3Wayマッチング：
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の照合モジュールは、あなたが実際に抱えている問題の下流にある問題に対処していることになります。より良い照合アルゴリズムは必要ありません。必要なのは、発注データ、入庫データ、請求書データを1つの構造化されたビューにまとめる方法です。そして、購買追跡にすでに使用しているツールは、おそらくスプレッドシートでしょう。問題は、そのスプレッドシートをパイプラインに変える方法です。

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

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

各レイヤーは、調達から支払いまでのチェーンにおける特定のギャップを埋めます。発注レイヤーは基準を確立します—何を、いくらで、誰から注文したか。入荷レイヤーは物理的に到着したものを確認します。請求書レイヤーは仕入先が請求した内容を取得します。照合ダッシュボードはこれら3つが収束する場所であり、問題分析で従来の照合ワークフローの構造的弱点として特定された3部門間の調査をスプレッドシートが代替します。

レイヤー1と3で非構造化から構造化への変換を実現するツールはカスタム列抽出です。各文書のフィールドに枠を描いたり、仕入先ごとにテンプレートを作成する代わりに、必要な列名（「発注番号」「仕入先名」「明細」「数量」「単価」「明細合計」）を入力するだけで、AIが文書を読み取り、画面上の位置ではなく意味を理解して値を検出します。SAPのPDF出力からの構造化発注書と、地元仕入先からの手書き発注書は全く異なります。しかし、どちらにも発注番号、仕入先名、数量、価格が含まれています。列名抽出は、あらゆるレイアウトにわたってこれらのフィールドの意味を検索するため、数十もの異なる仕入先文書形式を扱う調達チームにとってテンプレートベースのOCRを非現実的にする、仕入先ごと・形式ごとのテンプレート管理を排除します。

レイヤー1 — 発注書抽出：基準となる参照点

3ウェイマッチはすべて発注書から始まります。POは、どのベンダーから、どの品目を、いくつ、いくらで、いつ納品するかという条件を設定します。ERP統合環境では、このデータは構造化された明細項目として既に存在します。POはシステム内で作成されています。しかし、スプレッドシートベースの購買ワークフローでは、POはいくつかの形式で届きます。買い手側のシステムで生成されたPDF、注文確認としてサプライヤーからメールで送られてくるPO、紙ベースで運用する小規模ベンダーからのスキャン文書などです。POデータを構造化形式に変換することが最初のステップであり、スプレッドシートベースのチームにとっては、その後のパイプライン全体が可能かどうかを左右するステップです。

POの抽出列は、照合プロセスで参照する必要があるものによって異なります。最低限必要なものは次のとおりです。

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

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

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

入庫伝票は、構造化システムから欠落しがちな書類であり、スリーウェイマッチングを成立させるための重要な書類です。入庫確認がなければ、ツーウェイマッチング（PO対請求書）しかできず、納品されたか確認できない商品の支払いを行うことになります。ACFEは特に、入庫伝票を請求書詐欺（未出荷商品の支払い）を防ぐ管理手段として挙げています。これを省略することは近道ではなく、管理フレームワークの欠陥です。

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

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

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

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

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

仕入先請求書は、フォーマットの多様性の問題がピークに達する領域です。単一の購買業務で、構造化されたSAP生成PDFの大手MRO販売代理店からの請求書、手作りのExcel-to-PDF形式の地域金属サプライヤーからの請求書、写真撮影された手書き文書の地元機械工場からの請求書、そして日付形式、通貨規則、税額明細行が異なる国際的なベンダーからの請求書を受け取る可能性があります。各サプライヤーのレイアウトにフィールドマッピングテンプレートを作成し、レイアウトが変更されるたびに更新するテンプレートベースのOCRは、この多様性の前で機能しなくなるか、維持に多大な時間を費やし、結果的に置き換えるはずだった手動入力と同じ労力がかかることになります。

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

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

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

3者照合パイプラインを支えるのと同じ請求書抽出レイヤーが、より広範な仕入先からAPへの請求書パイプラインのエンジンでもあります。列構造は異なりますが、抽出メカニズムは同一です。照合用に構築された後、同じパイプラインがAPレポート、未払金計算、監査証憑にデータを提供します。

照合ダッシュボード：VLOOKUP、IF、条件付き書式

発注書登録、受領登録、請求書登録の3つのレイヤーすべてが入力されると、照合ダッシュボードでそれらが統合されます。これは、3つのソースタブすべてからルックアップ関数を使用してデータをプルし、比較ロジックを適用して一致、差異、欠落データにフラグを立てる単一のタブです。照合ロジック自体は複雑ではありません。スプレッドシートで実行できます。常に複雑であり、パイプラインが解決するのは、スプレッドシートがそれを実行できる状態にデータを整えることでした。

Googleスプレッドシートで構築された照合ダッシュボードの構造：

条件付き書式でテーブルをダッシュボードに変身させます。列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総承認額に対する累積数量を追跡します。

コレクションリンク — サプライヤーが直接書類を提出

三者照合における非効率の一つに、サプライヤーからAPチームへの書類の受け渡しがあります。サプライヤーが請求書をメールで送信。AP担当者が添付ファイルをダウンロードし、共有ドライブやローカルフォルダに保存した後、抽出ツールにアップロードします。このダウンロードと再アップロードのサイクル自体がボトルネックというわけではありませんが、50社のサプライヤーから月100件以上の請求書を処理する場合、積み重なる摩擦になります。

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

三者照合パイプラインに適用すると、コレクションリンクは書類の流れを「サプライヤーが請求書をメール送信 → あなたがダウンロード → あなたがアップロード → あなたが抽出」から「サプライヤーが直接アップロード → ファイルがキューに表示 → あなたが抽出」に変えます。ダウンロードと再アップロードのステップを完全に排除します。同じ出荷のパッキングスリップと請求書など、複数の書類を送るサプライヤーの場合、1つのコレクションリンクで両方のファイルを取得し、抽出エンジンはシートの列定義に従って各ファイルを処理します。詳細な設定とワークフローについては、抽出機能を使った書類収集ガイドをご覧ください。

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

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

置き換わるもの：

• 発注書や請求書からの手動データ入力。 抽出レイヤーが非構造化文書を構造化された行に変換します。発注明細や請求書項目を追跡シートに手入力する作業が不要になります。
• 仕入先ごとの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ヶ月目にはルーティン化します。

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

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

結論

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

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

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

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