複数サプライヤー形式の日本語納品書（納品書）からExcelへデータを抽出する方法
日本語の納品書（納品書）はサプライヤーによって異なります。AI抽出がサプライヤーごとのテンプレート設定なしで多形式の納品書データ抽出をどのように処理するかを学びます。
なぜテンプレートベースの抽出は日本の納品書で失敗するのか
テンプレートベースのOCRは、フィールドがページ上のどこにあるかを記憶することで機能します。仕入先Aの納品書レイアウト（納品日は右上、注文番号はヘッダー下、明細テーブルは12行目から開始）でトレーニングすると、仕入先Aが今後送るすべての納品書からそれらのフィールドを正しく抽出できます。次に仕入先Bが、納品日が左下にあり、注文番号が参照行に埋め込まれ、明細テーブルが縦型レイアウトの納品書を送ってきた場合、テンプレートは失敗します。30社の仕入先を処理するには30個のテンプレートが必要で、仕入先がERPを更新してレイアウトが予告なく変更されるたびに、そのうちの1つが壊れます。
日本の納品書は、西洋形式向けに作られた一般的な納品書ツールが対応できない3つの点で、テンプレートの問題を増幅させます。複数税率の消費税により、ツールが認識しない2つの税区分に金額が分割されます。日付は西暦ベースの日付パーサーが誤読する和暦（令和）で記載されます。そして日本の形式の多様性は極端です。異なる会計・販売管理システム（弥生販売、freee、Money Forward、楽々シリーズ、カスタムERPエクスポート）で生成される納品書には共通のレイアウトがなく、さらに手書きのカーボンコピー納品書（修理サービス、建設資材業者、小規模ベンダーで今も広く使用）は、ほとんどのOCRツールがトレーニングされていない日本語文字の手書き認識という課題をもたらします。
核心的な問題はOCRの精度ではありません。最新のAI-OCRエンジンは、きれいな印刷済み納品書の個々の文字を高い信頼度で読み取れます。問題は、ツールがどのテキストがどのフィールドに対応するかを把握できないことです。「令和7年6月10日」「T1234567890123」「¥140,000」をテキスト文字列として認識しても、「納品日」「適格請求書登録番号」「合計金額（10%対象）」にマッピングできません。各フィールドが何を意味するかを理解していないからです。これがOCRとカスタム列抽出の差です。カスタム列抽出は、意味に基づいて必要な列を定義し（「納品日」「注文番号」「仕入先名」）、AIがその意味を理解してページ上のどこからでも対応する値を特定します。前回どこにあったかを記憶するのではなく、何を表しているかを理解するのです。
調達・受入業務を支える納品書の項目
納品書データをExcelに抽出する前に、どの項目を抽出するかを決める必要があります。日本の納品書には、受入・在庫計上・三方向照合に必要な項目が8〜14項目あり、インボイス制度に基づく適格請求書を兼ねるかどうかによって異なります。
日本の納品書には法的に定められた形式はありません。国税庁は税務書類として必要な5つの必須項目を定めており、2023年10月から施行されたインボイス制度では、納品書が適格請求書を兼ねる場合にさらに3項目が追加されます。しかし、調達部門には税務上の最低限以上の項目が必要です。倉庫管理システム、ERPの入庫モジュール、発注照合ワークフローに必要な項目が必要です。
日本の受入現場に必要な最小限の抽出列セット：
| 項目（英語） | 日本語の表記例 | 後続での用途 |
|---|---|---|
| 仕入先名 | 発行者名、会社名、納入元 | 仕入先マスタと照合、発注書発行者と検証 |
| 納品書番号 | 納品書番号、伝票番号、No. | 入庫記録の主キー、監査証跡 |
| 納品日 | 納品日、発行日、取引年月日 | 受入記録、会計期間の帰属判定 |
| 発注書参照 | 発注番号、注文番号、ご注文番号 | 未処理発注書との三方向照合 |
| 品名／説明 | 品名、商品名、品目 | 在庫計上、発注明細との照合 |
| 数量 | 数量、個数 | 在庫更新、過不足納品の検出 |
| 単価（表示がある場合） | 単価 | 価格検証、一部の納品書では省略される |
| 行ごとの金額（表示がある場合） | 金額、税抜金額 | 受入額の集計、一部の納品書では合計のみ表示 |
| 登録番号（適格請求書） | 登録番号、T+13桁 | 仕入税額控除のための適格請求書発行事業者資格の検証 |
| 税区分（適格請求書） | 10%対象、8%対象、消費税額 | 消費税申告のための10%・8%課税額の区分 |
| 宛名 | 宛名、納品先、御中 | 正しい事業者への納品確認、コストセンターの振り分け |
納品書が適格請求書を兼ねる場合、登録番号と税率ごとの消費税額は任意ではなくなります。これらがないと、購入側はその取引で仕入税額控除を申請できません。
適格請求書制度が納品書のデータ抽出をどう変えたか
2023年10月以前は、納品書データの抽出は純粋に効率化の手段でした。タイピングを省いて時間を節約できたのです。2023年10月以降、適格請求書制度（インボイス制度）の導入により、納品書の抽出にはコンプライアンス上の側面が加わりましたが、ほとんどの抽出ツールはまだ対応できていません。
旧来の区分記載請求書等保存方式では、納品書に必要な基本項目は5つでした。発行者の氏名・名称、取引日、取引内容（軽減税率の記載を含む）、税率ごとの合計金額、受領者の氏名・名称です。新しい適格請求書制度ではさらに3つが追加されます。適格請求書発行事業者の登録番号（登録番号、T+13桁の形式）、区分ごとの適用税率、税率ごとに区分した消費税額です。適格請求書として機能する納品書にはこれらすべての記載が必要であり、買い手は消費税法第30条に基づく仕入税額控除を受けるために、これを7年間保存しなければなりません。
つまり、抽出ツールは数年前までは任意だった項目を取得する必要があるのです。さらに重要なのは、10%の標準税率と、食品や新聞に適用される8%の軽減税率という二段階税率の構造により、1枚の納品書に2つの税区分別小計が含まれることがあり、それぞれに独自の課税標準と税額計算があるという点です。合計を単一の数字として読み取り、税率で区分しない抽出ツールでは、消費税の申告に対応できないスプレッドシートが生成されてしまいます。
国税庁は、納品書と請求書を組み合わせて1つの適格請求書として扱うことを明示的に認めています。日本税理士会連合会のガイドラインによれば、納品書に明細を、請求書に税額の内訳を記載するなど、相互に明確な参照関係がある複数の書類は、まとめて適格請求書の要件を満たすことができます。つまり、納品書からの抽出結果は、後段の請求書データと組み合わせられるように構造化する必要があります。共通キーのない2つのスプレッドシートは役に立ちません。
適格請求書制度が調達ワークフロー全体の文書処理にどのような影響を与えるかについて詳しくは、日本の適格請求書制度におけるデータ抽出ガイドをご覧ください。
複数サプライヤーの納品書フォーマットに対応した抽出：ステップバイステップのワークフロー
ここからは理論から実践へと移ります。弥生販売のエクスポート、freeeで生成されたPDF、Money Forwardの印刷物、手書きのカーボンコピー、そしてサプライヤー内部システムが生成する独自フォーマットまで、さまざまな納品書があります。抽出方法は、1つの列定義でこれらすべてを処理できる必要があります。30種類のテンプレートを管理することは、自動化の目的を損なうからです。
抽出列を一度だけ定義する
必要なフィールドに名前を付けます。ピクセル位置ではなく、その意味に基づいてです。「納品日」は、ページ上のどこに表示されていても納品日を見つけるようAIに指示します。「品名」は、表、縦型リスト、バーコードの横に印刷されている場合でも、すべての明細行の説明を特定します。「発注番号」は、サプライヤーが「ご注文番号」や「注文番号」とラベル付けしていても、その参照情報を見つけます。入力した列名が、出力スプレッドシートのヘッダーになります。この列セットをテンプレートとして保存してください。一度定義すれば、すべてのサプライヤーで使用できます。
その日の納品書をすべて1つのバッチとしてアップロードする
受け取り場で紙の納品書をスキャンします。メールの添付ファイルからサプライヤーのPDFをアップロードします。トラックのドアでスマートフォンを使ってカーボンコピーを撮影します。すべてを1つのバッチにドロップします。AIはPDF、スマホカメラのJPEG、スキャン画像を同じ実行で処理します。混合フォーマット、混合サプライヤー、1回のアップロードで完了です。
AIはフィールドの位置ではなく、フィールドの意味に基づいて各納品書を読み取る
各ドキュメントについて、AIはページ全体を読み取り、各列定義に対応するテキストの部分を特定し、値を抽出します。ヘッダーレベルのフィールド（サプライヤー名、納品書番号、納品日）は、スプレッドシートがリレーショナルな状態を保つように、すべての明細行に繰り返し入力されます。明細レベルのフィールド（品名、数量、単価）は、ドキュメントが使用する表やリスト構造から行ごとに抽出されます。6列の表を持つ弥生フォーマットも、縦型リストに3つのフィールドがある手書きのメモも、同じように機能します。
確認してExcelにエクスポートする
出力は構造化されたテーブルとして表示されます。明細ごとに1行、ヘッダーフィールドが繰り返され、すべての値が標準形式で表示されます。エッジケースを確認します。曖昧だった手書きの数量、AIが手動確認用にフラグを立てた日付などです。検証が完了したら、XLSXとしてエクスポートします。このファイルは、WMSやERPへのインポート、またはスプレッドシートでの発注書との照合にすぐに使用できます。システムがCSVを受け付ける場合は、代わりにCSVをエクスポートしてください。フォーマット変換も、手動での再入力も不要です。
この方法が機能するのは、AIがテンプレートを照合しているのではなく、意味を照合しているからです。弥生販売の納品書でヘッダーに「納品日」とあるものも、freeeの納品書でフッターに「発行日」とあるものも、どちらも納品日を含んでいます。「納品日」列は、ページ上のどこを探せばよいかを誰もツールに指示しなくても、両方を見つけ出します。バッチ処理による納品書処理の詳細なチュートリアルについては、納品書と納品書を1つの受領スプレッドシートにまとめるガイドをご覧ください。
ファイルは安全に処理され、保存されません。
日本特有の抽出課題への対応
日本の納品書には、一般的なツールでは対応できない4つの抽出課題があります。これはOCRの精度の問題ではなく、ツールに読み取った内容を解釈するための日本特有の文脈が欠けているためです。
和暦の日付（和暦）
令和7年6月10日付の納品書は、西暦では2025年6月10日です。令和は2019年5月に始まりました。その前は平成（1989年1月～2019年4月）、さらにその前は昭和（1926年12月～1989年1月）です。長年の取引先からの納品書には、テンプレートが作成された時期に応じて、これらの元号のいずれかが記載されている場合があります。「令和7年6月10日」をテキストとして抽出するだけのツールでは、スプレッドシートの利用者がすべての日付を手動で変換する必要があります。日本対応の抽出ツールは、元号を認識し、変換を行い、標準的な日付形式（2025-06-10 または June 10, 2025）を自動的に出力する必要があります。手動で行うと1枚あたり30秒の修正が必要です。100枚の納品書では、日付だけで50分かかります。
複数税率（複数税率）
2019年10月以降、日本では標準税率10%と、食品（酒類と外食を除く）および新聞購読に対する軽減税率8%が適用されています。食品卸売業者からの1枚の納品書に両方の税率が記載される場合があります。野菜の箱は8%、清掃用品は10%です。納品書には、各税率区分ごとに小計と税額が記載されています。すべてを1つの「合計」列に合算する抽出ツールでは、税区分が失われ、消費税申告に使用できないデータになります。列定義には、「10%対象」「8%対象」「10%消費税」「8%消費税」という別々のフィールドを含める必要があります。
手書き・複写式の納品書
手書き納品書は日本では今も一般的です。修理サービス、建設資材サプライヤー、小規模メーカー、個人事業主などで使用されています。複写式納品書は複数の層を生成します。1枚目は受取人に渡り、2枚目はサプライヤーが保管します。倉庫に届く頃には、3世代目のカーボン複写で文字が薄れ、インクがにじみ、印鑑が文字の上に押されている場合があります。きれいな欧米レイアウトで学習された一般的なOCRは、不規則な手書き文字、劣化したカーボン転写、赤インクの印鑑の重なりという3つの課題すべてに苦戦します。文書を画像全体として読み取り、テキストを孤立した文字グリッドではなく文書コンテキストの一部として理解するビジュアルAIモデルは、これらのフィールドを抽出できます。手書き日本語の精度は印刷テキストよりも低いため、手書きの納品書には簡単な確認パスを予算に組み込んでください。しかし、「AIが80%正しく読み取り、残り20%を修正する」ことと「ゼロから100%手入力する」ことの差こそが重要な差です。手書き文書の処理について詳しくは、手書き納品書をExcelに抽出するガイドをご覧ください。
会社印と角印（印鑑 / 角印）
ほとんどの日本の納品書には会社印が押されています。通常は赤いインクの角印で、発行者名と住所の上に押されます。印鑑は真正性の証でありデータ項目ではありませんが、赤いインクの重なりがOCRエンジンの下のテキスト読み取りを妨げます。さらに悪いことに、一部の仕入先は納品日や合計金額の行の上に印鑑を押します。これらはまさに最も必要な項目です。文書構造でトレーニングされた視覚AIモデルは、重なった印影とその下のテキストを区別し、印鑑を無視しながら元のテキストを抽出できます。この機能は日本の文書抽出において必須です。印鑑を処理できないツールは、日本の納品書を処理できません。
日本の文書処理エコシステムがこれらの課題にどう対応しているか、freeeの内蔵OCRから専用AI抽出サービスまでのツールのコスト比較を含む詳細は、日本の中堅・中小企業向けの手頃な抽出オプションの分析をご覧ください。
FAQ
手書きの日本の納品書でも機能しますか？
はい。列名抽出の基盤となる視覚AIモデルは、印刷された日本語テキストと手書きの両方を読み取ります。筆記体や漢字かな混じり文も対応します。手書きフィールドの精度は印刷テキストと完全に同じではありません。特に画数の多い複雑な漢字や劣化したカーボンコピーの場合は精度が落ちますが、レビュー手順でエッジケースを補足するため、完全な手入力の再入力は不要です。納品書が完全に手書きの場合は、抽出結果を盲目的に信頼せず、検証することをお勧めします。
日付で和暦（令和/平成/昭和）に対応できますか？
はい。「納品日」のような列を定義すると、AIが和暦の日付を認識し、出力で西暦に変換します。令和7年6月10日は、お好みの形式に応じて2025年6月10日または2025-06-10になります。この変換は抽出中に自動的に行われ、後でExcelで日付を手動修正する必要はありません。
金額が記載されている納品書と記載されていない納品書がある場合はどうすればよいですか？
日本の調達業務では、納品書に価格の記載は必須ではありません。単価や行ごとの金額を記載する仕入先もあれば、月締めで一括請求書を発行する仕入先は価格を省略し、品名と数量のみを記載することもあります。列定義に「単価」や「金額」のフィールドを含めることで、AIは記載がある場合は抽出し、ない場合はセルを空のままにします。スプレッドシートの整合性は保たれ、価格の突合は後工程で請求書と照合して行います。
適格請求書を兼ねた納品書からもデータを抽出できますか？
はい。適格請求書の登録番号、10%対象額・10%消費税額、8%対象額・8%消費税額の列を定義してください。AIはすべてのフィールドを同じスプレッドシートの行に抽出します。適格請求書の項目がない納品書の場合、それらの列は空のままになります。抽出処理は別々のテンプレートを用意することなく、両方のタイプの納品書を同じバッチで処理できます。
縦書きの納品書も抽出できますか？
一部の日本の納品書、特に伝統的な形式のものは縦書きで、右側に宛先情報、左側に発行元情報が配置されています。AIの視覚言語モデルは文書を画像として読み取り、テキストの流れる方向だけでなくレイアウト構造も理解します。フィールドの意味的な役割に基づいて、向きに関係なく位置を特定します。ただし、横書きのレイアウトの方が精度は高くなります。縦書きを一貫して使用する仕入先がいる場合は、初期テストバッチにサンプルを数件含めて、その仕入先の特定のレイアウトでの精度を評価してください。
freeeやMoney Forwardに組み込まれているOCRとの違いは何ですか？
freee、Money Forward、弥生に組み込まれているOCRエンジンは、主にレシート（短く、単一形式の感熱紙で、構造が既知のもの）向けに設計されています。コンビニのレシートを読み取って経費を自動分類するのは得意です。しかし、複数形式の仕入先納品書、特に明細テーブル、複数の税率、横書き・縦書きが混在するレイアウトを含むものは、根本的に異なる文書です。組み込みのOCRでは一部のフィールドは正しく抽出できるかもしれませんが、明細テーブルの構造、和暦の変換、税率の区分には対応できないことが一般的です。文書テンプレートではなくフィールドの意味に基づいて読み取る専用の納品書抽出は、まさにこのシナリオ向けに設計されています。
Excel出力はどのWMSまたはERPシステムにインポートできますか？
XLSXまたはCSV出力は、入庫伝票のスプレッドシートインポートをサポートするあらゆるシステムにインポートできます。SAP、Sage、Microsoft Dynamics、および日本の調達で広く使用されている日本固有のプラットフォーム（弥生販売、freee、Money Forward、楽々シリーズ）を含みます。受領記録のCSVインポートをサポートしているシステムであれば、追加の変換なしで出力をそのまま使用できます。
日本の納品書は、他の納品書よりも読みにくいわけではありません。難しいのは、ほとんどの抽出ツールが、納品書の見た目、日付の形式、ページに記載される税情報について、異なる前提でトレーニングされていることです。ツールがフィールドの位置ではなく意味で読み取る場合、それらの前提は重要ではなくなります。弥生販売のPDFからデータを抽出するのと同じ列定義が、freeeの印刷物、Money Forwardのエクスポート、および会社印と万年筆を使用するサプライヤーからの手書きのカーボンコピーにも機能します。スプレッドシートが先に来ます。手入力はなくなります。三者照合が始まります。