日本の発注書データをExcelに抽出する方法
仕入先請求書との照合に

日本の発注書の項目 — 項目ごとの解説

日本の発注書は、欧米の発注書と比較して、より標準化されつつも、より微妙なニュアンスを含む構造を持っています。標準化されているのは、公正取引委員会（JFTC）が下請取引に義務付ける必須項目（下請法で定められ、2026年の中小受託取引適正化法（取適法）で強化）により、法的に準拠した発注書にはすべて同じ基本情報が含まれるためです。微妙なニュアンスがあるのは、それらの項目の中身が、一般的な抽出ツールでは解析するように訓練されていない日本のビジネス慣行を反映しているからです。

JFTCは、発注書（2026年法では正式に4条書面）には最低限、双方の当事者名、発行日、納入物の説明、納期、納入場所、検査完了日、支払金額、支払期日、支払方法が含まれなければならないと定めています。実際には、ほとんどの日本の発注書には、照合ワークフローにとって重要な追加項目が含まれています。以下が、購買管理者が実際に扱う完全な構造です。

公正取引委員会のサンプル発注書テンプレートには、法令準拠文書に記載される必須項目の全セットが示されている。抽出における重要なポイントは、日本の発注書は自由形式のビジネスレターではないということだ。これは予測可能なフィールドを持つ構造化文書である。しかし、そのフィールドには、日本の調達コンテキスト向けに設計されていないツールには見えない慣習に従った内容が含まれている。抽出のタスクは「この文書を読む」ことではなく、「この文書を読み、締日が支払計算において何を意味するのかを理解する」ことなのである。

なぜ発注書・納品書・請求書のマッチング問題は単純な自動化を拒むのか

三者照合（発注書、納品書、請求書の数量・価格・条件を照合するワークフロー）は、日本の購買業務において過払い、二重支払い、不正を防ぐための管理ポイントです。同時に、手作業によるデータ入力のボトルネックが集中する箇所でもあります。多くのチームが最初に試す「OCR出力をVLOOKUPで照合するだけ」という解決策がうまくいかない理由を説明します。

核心的な難しさは、3つの文書が同じ取引を異なるテキスト表現で記述している点にあります。ある仕入先の発注書には「ステンレスボルト M8×30 (SUS304)」と記載されていても、対応する請求書では「SUSボルト M8」と省略されている——一方で検索してもExcelは#N/Aを返します。発注書には数量が「1式」と記載されていても、請求書では同じ合計に対してそのロットを5個に明細化している——数値的には一致しませんが、同じ注文を表しています。発注書には税抜単価、請求書には税込単価が記載されており、単純に比較すると価格が変わったと判断されます。

ここで、テンプレートを照合するのではなく文書の意味を読み取る抽出アプローチが状況を変えます。抽出ステップで発注書から構造化フィールド（発注番号を列に、品名を列に、数量と単位をそれぞれ別の列に、単価を税抜で正規化）を出力できれば、同じ構造で抽出された請求書との照合は、単純な列比較で完了します。重い処理はスプレッドシート（仕入先が書式を変更すると壊れる複雑な複数条件VLOOKUP数式）から抽出ステップ（AIが表現を単一スキーマに解決する）に移ります。

また、下請法は抽出速度に影響を与える時間的制約を課しています。支払いは商品やサービスの受領日から60日以内に行わなければなりません（納品日から60日以内）。抽出と照合にその60日のうち1週間かかると、購買チームは残り53日で承認ルーティング、差異解決、支払い処理などすべてを行う必要があります。抽出ステップを数日から数秒に短縮することで、コンプライアンス期間の実質的な余裕が直接拡大します。

発注書データをExcelに抽出する方法 — ステップバイステップ

手作業による発注書からExcelへの転記を置き換えるワークフローは、3つの段階で構成されています。最初の段階である抽出内容の定義は一度行うだけで、すべての仕入先、すべての発注書フォーマット、そして以降のすべてのバッチに適用されます。

同じ列スキーマは翌月も、新しく取引を始めた仕入先からの発注書にも、法人税法で7年間、下請法で2年間の保管が義務付けられている過去の決算年度のアーカイブ発注書にもそのまま使えます。仕入先がERPをアップグレードして発注書のフォーマットを変更しても、あなたが定義した列名は影響を受けません。

汎用抽出では対応が難しい項目とその対処法

日本の発注書に記載されるデータのうち、以下の3項目は特に自動抽出が困難です。理由は読み取りにくさではなく、抽出時に単純化せず保持すべきビジネスロジックが埋め込まれているためです。

支払条件 — 文字列から決済日への変換

日本の発注書における支払条件は、「20日締翌月末払い」「月末締翌々月末払い」「納品後60日以内」といった簡潔な複合表現で記述されます。それぞれに、請求期間の締め日（締日）と、その締日から見た支払期日という2つの情報が含まれています。発注書と請求書を照合する購買チームは、これらを別々の列で取得する必要があります。締日は請求書の請求期間が発注書と一致しているかを確認するため、支払遅延月数は請求書の支払期日が正しいかを確認するために使います。

汎用的な抽出では、これらが1つの未分化なテキスト文字列として出力されます。この問題を解決するのが計算列です。計算列とは、AIが文書から直接読み取るのではなく、抽出時に計算して値を生成する列です。締日（支払条件から日付を抽出。「20日締」なら20、「月末締」なら31） という列と、支払遅延月数（支払条件から抽出。「翌月末払い」なら1、「翌々月末払い」なら2） という列を定義します。AIが日本語の支払条件の慣例を解析し、数式で計算可能な構造化された値を出力します。

消費税区分 — 複数税率の自動判定

日本の複数税率制度では、1件の発注書に10％、8％、非課税の明細が混在する場合があります。2023年10月から開始されたインボイス制度に対応するため、請求書では税率区分ごとに税額を明示する必要があります。発注書の抽出データで各明細の税率が保持されていないと、請求書の税額合計を発注書と照合できず、購買部門は税額計算を確認できないまま支払いを承認することになります。

この問題の解決策は推論列です。推論列とは、ラベル付きフィールドから読み取るのではなく、AIが文脈から値を推論する列です。消費税区分（選択肢：10％標準、8％軽減、非課税）— 品目説明から判定。飲食料品→8％軽減。一般物品→10％。輸出物品または明示的に非課税と記載されたもの→非課税と定義します。AIが各明細の品目説明を読み取り、抽出時に正しい消費税区分を割り当てるため、出力されるスプレッドシートには税区分がすでに設定された状態で届き、税率グループごとの合計照合がすぐに行えます。

納入場所 — 詳細で可変、かつ極めて重要

日本の製造業の発注書に記載される納入場所は独特の詳細さを持ちます。「〇〇株式会社 埼玉工場 第二組立課 B棟3階」のように、工場構内の特定の建物、階、部署を参照します。これらの文字列はサプライヤーによって長さや詳細度が異なり、「埼玉工場」→「埼工」のように頻繁に省略されます。また、社内の生産スケジュール管理における検索キーでもあります。納入場所が破損または切り捨てられて「〇〇株式会社 埼玉工場 第二組立課 B棟」のように階数が欠落すると、資材が誤った受け入れドックに送られてしまいます。抽出では、印刷された完全な文字列を保持する必要があります。特に、日本語の言語モデルを持たないOCRエンジンが頻繁に誤読する漢字（工場と工塲、棟と楝など）に注意が必要です。

抽出した発注書データを日本の会計ソフトに取り込む

抽出ジョブの出力はスプレッドシートです。そのデータの行き先は、照合が行われる会計ソフトや購買管理ソフトです。ここでは、日本の企業が実際に使用しているツールと、このパイプラインがどのように連携するかをご説明します。

弥生会計 / 弥生販売 — 日本の中小企業向け会計ソフトでトップシェアを誇ります。弥生のデスクトップ版およびクラウド版製品は、仕訳帳や買掛金元帳データのCSVインポートに対応しています。抽出結果の列見出しがインポート時のフィールドマッピングになります。例：発注書番号 → 伝票番号、日付 → 日付、仕入先 → 仕入先、金額 → 金額。弥生販売は、購買管理や在庫管理のための姉妹製品で、発注書データを購買モジュールに直接インポートします。専用のパイプラインにより、抽出からインポートまでの工程がファイルのアップロードに集約されます。

freee — 7万以上の日本の中小企業が利用するクラウド会計プラットフォームです。freeeのAPIとCSVインポートは、自動仕訳による購買取引の登録をサポートしています。明細ごとに税区分が抽出された発注書データは、freeeの消費税申告機能に直接連携します。この機能は、適格請求書（インボイス）制度に対応するための10%標準税率と8%軽減税率の両方の計算をサポートしています。

マネーフォワード クラウド会計 — freeeの主要な競合で、日本国内で最多となる2,451以上の金融機関API連携を誇ります。マネーフォワードの購買管理モジュールはCSVインポートに対応しており、抽出された発注書データ（仕入先名や金額など）が買掛金元帳に直接反映されます。プラットフォームの自動銀行取引照合機能は、抽出された支払いレコードと銀行フィードを照合し、発注書の抽出から支払い確認までのサイクルを完結させます。

勘定奉行 — OBCが提供する会計スイートで、中堅企業（年商5億円～50億円）で高いシェアを持ちます。勘定奉行の購買モジュールは発注書データの一括インポートに対応しており、特に部門別原価管理に強みがあります。発注書に部門コードやコストセンターが含まれている場合、それらのフィールドは自動的に部門別損益計算書のレポートに反映されます。

共通点は、主要な日本の会計プラットフォームはすべて構造化データのインポートに対応しているということです。これまでボトルネックとなっていたのは、インポート機能そのものではなく、発注書データをそもそも構造化された形で入手することでした。きれいなExcelの列データがあれば、インポートはファイルのアップロードかコピー＆ペーストで完了します。

よくある質問

取引先からFAXで送られてくる手書きの発注書も読み取れますか？

はい、読み取れます。特に中小の製造業や商社からの発注書では、ボールペンで手書きされた品名や数量、会社印（社判）が押印されたものがFAXで送られてくることがよくあります。AIモデルは、調達業務でよく使われる略字（㈱やNo.など）を含む手書きの日本語文字を読み取ります。画質が劣化したFAX（用紙の地紋、傾き、インクの裏抜けなど）の場合、難しい文字については出力結果をスポットチェックすることをお勧めします。FAX原稿の場合は、300dpi以上でスキャンすると精度が向上します。

1枚の発注書が複数ページにわたる場合はどうなりますか？

発注書の全ページを一度にアップロードしてください。抽出エンジンは、同じファイルの複数ページを1つの連続した文書として扱います。ヘッダー情報（発注番号、取引先、日付）は1回だけ抽出され、全ページの明細行が同じ行セットにまとめられます。複数ページのFAX発注書で、継続ページにヘッダーがなく、前ページからの明細テーブルが続いている場合でも、抽出処理は継続性を維持し、すべての明細を1ページ目で特定された発注番号に関連付けます。

取引先ごとに発注書のフォーマットが異なっていても大丈夫ですか？

はい、問題ありません。これこそが、テンプレートベースのOCRに対するセマンティック抽出の決定的な利点です。テンプレートベースのツールでは、取引先ごとに異なる解析テンプレート（フィールドの座標範囲やラベルを定義したもの）を作成し、維持する必要があります。取引先がERPをアップグレードしたり、帳票をリニューアルしたりして発注書のレイアウトが変更されると、テンプレートは使えなくなり、再構築が必要になります。セマンティック抽出は、データがページのどこに表示されているかではなく、それぞれのデータが何であるかを理解して文書を読み取ります。発注番号は、三菱ケミカルの発注書では右上に印刷されていようと、地場の下請け業者からの手書きFAXでは下部中央に書かれていようと、発注番号です。

8%と10%の消費税区分の抽出はどのように行われますか？

日本における複数税率の消費税制度では、税率区分ごとに明細を記載した請求書が求められます。発注書の抽出において、例えば「税率（選択肢：8%、10%、非課税）— 品目説明に基づいて分類」といった税区分ロジックを指定する列を追加すると、AIが各明細行を評価し、抽出時に正しい税率を割り当てます。食品や定期購読新聞は8%、それ以外は10%、輸出取引や明示的に非課税の項目は非課税となります。抽出されたデータには税率が既に割り当てられており、請求書の税区分内訳に合致した税率グループごとの合計計算が可能です。これは推論列です。税率は発注書に印刷されているわけではなく、抽出時にAIが品目説明から導き出します。

同じワークフローで他の日本の調達書類も処理できますか？

列スキーマのアプローチは、調達書類の全チェーンに適用できます。見積書の場合：仕入先、品目、単価、有効期限を抽出し、発注書と照合して、注文価格が見積価格と一致するかを確認します。納品書の場合：納入数量を抽出し、発注書の数量と比較して、請求書が届く前に不足納品を特定します。請求書の場合：請求金額と税区分内訳を抽出し、発注書データと照合して支払承認前に確認します。同じ抽出プラットフォームで4種類すべての書類を処理でき、同じ列命名ロジックが適用されます。つまり、必要なフィールドを定義すれば、AIが意味に基づいてそれらを見つけ出します。関連する書類レベルのワークフローについては、日本の銀行通帳データの抽出、オーストラリアBAS抽出ワークフロー、カナダGST/HST申告データ抽出のガイドもご参照ください。

紙の発注書から照合済みの元帳へ

日本の調達書類チェーン（見積書、発注書、納品書、請求書）は、それぞれの書類を慣習を理解した人間が読むことを前提に設計されていました。発注書に「20日締翌月末払い」とあれば、人間はそれが請求月の20日締めで翌月末までに支払うことを意味すると理解します。請求書で品目名が省略されていても、人間はそれが発注書の同じ製品を指しているとわかります。税区分は品目説明に暗に含まれており、人間はそれを頭の中で対応づけます。調達のデジタル化における障壁は、これらの書類に構造が欠けていることではなく（実際には高度に構造化されています）、その構造が人間の読者間の共通認識に依存しており、その認識にアクセスできない機械が構造を誤読することにありました。

フィールドの位置ではなく意味を読み取る発注書抽出は、そのギャップを埋めます。発注番号はOCRエラーではなく検索キーになります。支払条件は、一つの文字化けした文字列ではなく、締日と支払猶予という二つの列になります。税区分は、請求書レビュー時の頭痛の種ではなく、値が入力された列になります。調達チームは現在手入力に費やしている時間を取り戻し、会社の資金を守る管理ポイントである照合ワークフローは、より迅速かつ信頼性の高いものになります。