日本の納品書から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、マネーフォワードの印刷物、手書きカーボンコピー、そしてサプライヤー内部システムが生成する独自フォーマットまで、様々な納品書を扱います。抽出方法は1つのカラム定義ですべてに対応する必要があります。30ものテンプレートを管理するのは自動化の目的に反するからです。
抽出列を一度定義する
必要なフィールドに名前を付けます。ピクセル位置ではなく、意味で指定します。「納品日」と定義すれば、画面上のどこにあってもAIが日付を見つけます。「品名」は、表、縦書きリスト、バーコード横の印刷など、あらゆる明細行の説明を特定します。「発注番号」は、仕入先が「ご注文番号」や「注文番号」と表記しても、該当する参照情報を探し出します。入力した列名がそのまま出力スプレッドシートのヘッダーになります。この列セットをテンプレートとして保存すれば、一度定義するだけで全仕入先に使い回せます。
その日の納品書をまとめてアップロード
受け入れドックで紙の納品書をスキャン。メール添付の仕入先PDFをアップロード。トラックのドアでスマホを使ってカーボン複写の納品書を撮影。すべてを1つのバッチにまとめるだけで、AIがPDF、スマホカメラのJPEG、スキャン画像を一括処理します。形式も仕入先も混在したまま、1回のアップロードで完了です。
AIがフィールドの意味に基づいて各納品書を読み取る
AIは各帳票のページ全体を読み取り、どのテキストが各列定義に該当するかを識別して値を抽出します。ヘッダーレベルのフィールド（仕入先名、納品書番号、納品日）はすべての明細行に繰り返し入力され、スプレッドシートの関係性が維持されます。明細行のフィールド（品名、数量、単価）は、帳票が使用する表やリスト構造から1行ずつ抽出されます。6列の表を持つ弥生フォーマットでも、3つのフィールドが縦書きリストになった手書きのメモでも、同様に処理されます。
確認してExcelにエクスポート
出力は構造化された表として表示されます。1行が1明細行に対応し、ヘッダーフィールドは繰り返し表示され、すべての値は標準形式です。エッジケースを確認します。手書きで曖昧だった数量、AIが手動確認を求めた日付など。確認後、XLSXとしてエクスポートします。ファイルはWMSやERPへのインポート、またはスプレッドシートでの発注書との照合にすぐ使えます。システムが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抽出サービスまでのコスト比較を含めた詳細は、日本の中小企業向け手頃な抽出オプションの分析をご覧ください。
よくある質問
手書きの日本の納品書にも対応できますか？
はい——列名抽出の基盤となる視覚AIモデルは、印刷された日本語テキストと手書き文字（筆記体や漢字・かな混じり文を含む）の両方を読み取ります。手書きフィールドの精度は印刷テキストと同一ではありません（特に画数の多い複雑な漢字や劣化したカーボンコピーの場合）が、確認ステップで例外ケースを拾うため、完全な手動再入力は不要です。納品書がすべて手書きの場合は、抽出結果を盲信せずに検証することをお勧めします。
日付の和暦（令和/平成/昭和）に対応できますか？
はい。「納品日」のような列を定義すると、AIが和暦の日付を認識し、西暦に変換して出力します。令和7年6月10日は、お好みの形式に応じてJune 10, 2025または2025-06-10になります。この変換は抽出時に自動で行われ、後でExcelで手動修正する必要はありません。
納品書に金額が記載されているものとされていないものがあるのはなぜですか？
日本の調達業務では、納品書への価格記載は必須ではありません。単価や金額を行ごとに記載する業者もいれば、月締めで合算請求書を発行する業者は、価格を一切記載せず品名と数量のみを記載する場合があります。列定義に「単価」や「金額」フィールドを含めておけば、AIはデータが存在する場合に抽出し、存在しない場合はセルを空欄のままにします。スプレッドシートの形式は統一され、価格の突合は後工程で請求書を基に行われます。
適格請求書を兼ねた納品書からもデータを抽出できますか？
はい。適格請求書の登録番号、10%税区分（10%対象額、10%消費税額）、8%税区分（8%対象額、8%消費税額）の列を定義してください。AIはすべてのフィールドを同じスプレッドシート行に抽出します。適格請求書の項目がない納品書の場合、該当列は空欄のままです。この抽出方法では、異なる種類の納品書を同じバッチで処理でき、個別のテンプレートは不要です。
縦書きの納品書にも対応していますか？
一部の日本の納品書、特に伝統的な形式のものは縦書きで、右側に宛先情報、左側に差出人情報が配置されています。AIの視覚言語モデルは文書を画像として読み取り、単なるテキストの流れ方向ではなくレイアウト構造を理解します。そのため、向きに関係なく、フィールドの意味的な役割に基づいて位置を特定します。ただし、横書きのレイアウトの方が精度は高くなります。特定の業者が常に縦書き形式を使用する場合は、初期テストバッチに数サンプルを含めて、その業者固有のレイアウトに対する精度を評価することをお勧めします。
freeeやマネーフォワードのOCR機能との違いは何ですか？
freee、マネーフォワード、弥生に組み込まれているOCRエンジンは、主にレシート（短く、単一形式で、構造が既知の感熱紙）向けに設計されています。コンビニのレシートを読み取り、経費を自動分類するのは得意です。しかし、複数形式の業者からの納品書、特に明細行テーブル、複数税率、横書き・縦書きが混在したレイアウトのものは、根本的に異なる文書です。組み込みOCRでは一部のフィールドを正しく抽出できる場合もありますが、明細行テーブルの構造、和暦の変換、税率の按分では、一般的に失敗します。文書テンプレートではなくフィールドの意味に基づいて読み取る専用の納品書抽出は、まさにこのようなシナリオのために設計されています。
Excel出力はどのWMSやERPシステムにインポートできますか？
XLSXまたはCSV出力は、SAP、Sage、Microsoft Dynamics、および日本の調達で広く使われている弥生販売、freee、Money Forward、楽々シリーズなど、入庫のためのスプレッドシートインポートをサポートするあらゆるシステムにインポートできます。受領記録のCSVインポートに対応しているシステムであれば、追加変換なしでそのまま使用できます。
日本の納品書は他の納品書より読みにくいわけではありません。難しいのは、ほとんどの抽出ツールが納品書の見た目、日付の形式、ページ上の税情報の配置について異なる前提で学習されているからです。ツールがフィールドの位置ではなく意味で読み取る場合、そうした前提は問題になりません。弥生販売のPDFからデータを抽出するのと同じ列定義が、freeeの印刷物、Money Forwardのエクスポート、そして今なお会社印と万年筆を使う仕入先からの手書きカーボンコピーでも機能します。スプレッドシートが先です。手入力は終わります。三者照合が始まります。