ドイツの納品書（Lieferschein）からExcelへデータを抽出する方法 — 複数のサプライヤー形式に対応

ドイツの納品書に含まれる内容 — そしてなぜ請求書ではないのか

ドイツの納品書 — サプライヤーによって Lieferschein（納品書）または Warenbegleitschein（商品同行書類）と呼ばれます — は、請求書（Rechnung）とは根本的に異なります。Lieferschein には何が出荷されたかが記載されます。請求書には何を支払う必要があるかが記載されます。Lieferschein を請求書のように扱い、金額フィールドだけを抽出すると、受領数量、品目レベルの詳細、受領側の注記といった、経理と運用の両方が必要とする記録が残りません。

ヘッダーセクション。すべての Lieferschein は送信者と受信者の詳細から始まります：Absender（送信者/サプライヤー）— 会社名、住所、多くの場合 Lieferantennummer（サプライヤー番号）— そして Empfänger（受信者）と Lieferadresse（配送先住所）。これらの下に、3つの識別フィールドが文書を支えます：Lieferscheinnummer（納品書番号、サプライヤーが割り当てる一意の識別子）、Lieferdatum（納品日 — 商品が出荷または到着した日）、Bestellnummer（発注番号、あなたの内部発注参照）。一部の Lieferschein には Kundennummer（顧客番号）と、Bestellnummer とは異なる Auftragsnummer（注文番号）も記載されています — どちらがどちらかを知ることで、下流での照合エラーを防げます。

品目テーブル。文書の中核です。各行には通常、以下が含まれます：Positionsnummer（明細行番号）、Artikelnummer（品目/SKU番号）、Artikelbezeichnung（品目説明）、Menge（納品数量）、Einheit（単位 — Stück/個、kg、m、l、Karton/カートン、Palette/パレット）。一部のサプライヤーは、トレーサビリティ対象商品に Chargennummer（バッチ/ロット番号）、Gewicht（重量、kg）、Packstücke（明細行ごとの荷物数）を追加します。複数パレットの納品では、品目を特定のパレットに紐付ける Packstücknummer（荷物番号）列が表示されることがあります。

フッターと署名。Lieferschein の下部には通常、Gesamtmenge（総数量）、Anzahl Packstücke（荷物/パレットの総数）、そして受領者が受け取りを確認する Unterschriftsfeld（署名欄）が表示されます。この領域の手書きメモ — 「2 Kartons beschädigt/2 cartons damaged」、「Nachlieferung folgt/follow-up delivery pending」、「1 Palette fehlt/1 pallet missing」 — には、スプレッドシートに取り込む必要のある運用情報が含まれています。

納品書のフォーマット変動がほとんどの抽出アプローチを破綻させる理由

テンプレートベースのOCRは、最も一般的なドキュメント抽出方法ですが、1つのドキュメントレイアウトで学習し、その後のすべてのドキュメントでそのレイアウトを照合しようとします。SAPが生成したPDF上の座標（x=140, y=95）に「Lieferscheinnummer」を囲む境界ボックスを描くと、システムは以降、その正確なピクセル位置にあるテキストを探します。これは標準化された政府の帳票では機能します。しかしドイツのLieferscheinでは機能しません。理由は次のとおりです。

SAP S/4HANAのLieferschein（中規模メーカー発行）では、ヘッダーブロックが左上に密集したグリッドで配置され、明細テーブルは8列以上でページ幅いっぱいに広がり、フッターは右下に位置します。Lexware FakturaのLieferschein（小規模なHandwerksbetrieb発行）では、すべてが縦に積み重なります。送付元は左上、宛先は右上、明細はシンプルな4列テーブル（Pos.、Artikel、Menge、Einheit）、合計は下部です。sevDeskのLieferscheinは、ブランドロゴ入りのヘッダー、縦に積まれた住所ブロック、すっきりした5列の明細テーブルを備えた、より横長のレイアウトです。紙のLieferschein（まだデジタル化していないサプライヤー発行、たとえばDurchschreibesatz（カーボン複写式）を使う小規模なSpediteur）では、Lieferscheinnummerが右上隅に手書きされ、明細は手描きの表に、下部には署名が走り書きされているかもしれません。4つのフォーマット、共通する座標はゼロです。

AIベースの抽出はこれを別の方法で解決します。ピクセル座標を照合する代わりに、視覚言語モデルが各テキストが文脈上で何を意味するかを理解してドキュメントを読み取ります。あなたは列名——たとえば「Lieferscheinnummer」「Lieferdatum」「Artikel」「Menge」など、取得したいデータフィールド——を定義し、AIはページ上の位置ではなく、フィールドの意味（ドキュメント上部付近にある納品書番号、ドイツ語形式の日付で「Lieferdatum」や「Datum」というラベルの近くにあるもの）を認識して、各ドキュメント上の対応する値を特定します。これがカスタム列抽出です。欲しいフィールド名を入力すれば、AIがレイアウトに関係なくそれぞれを正しい値に照合します。

このアプローチは、テンプレートシステムがつまずく命名のばらつきにも対応します。あるサプライヤーは納品日を「Lieferdatum」と表記し、別のサプライヤーは「Versanddatum」と書き、3社目は「Datum」を使います。あるサプライヤーは明細番号の列ヘッダーに「Pos.」を使い、別のサプライヤーは「Nr.」と書き、3社目は「Position」と書きます。3つすべてが同じ概念を指すと抽出が理解できれば、出力には1つの統合された列が得られます。サプライヤーごとのマッピングは不要です。

GoBDとHGBの枠組み：正確な抽出が効率化以上に重要な理由

Lieferscheinデータを抽出する理由は、単なる時間短縮ではありません。ドイツの商法および税法には、納品書データを構造化し、検索可能にし、アーカイブする必要がある構造的な理由があります。

ドイツ商法典（HGB）の特に第408条では、運送状に荷送人と荷受人の識別情報、荷物数、総重量、引き渡しまたは発送日、納品書または注文番号を記載する必要があります。HGB第408条はLieferscheinそのものではなく運送契約（Frachtvertrag）を規定するものですが、ドイツの物流でLieferscheinが通常従う情報基準を定義しています。

より実務的に関連するのはGoBD（Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form）— 連邦財務省（BMF）が発行した、電子形式での適正な簿記と記録保持に関するドイツの原則です。GoBDでは、納品書は商業通信文（Geschäftsbriefe）に該当し、改変不可能で追跡可能な形式で6年間保存する必要があります。LieferscheinをPDFで受け取った場合、PDFのままアーカイブする必要があります。データを抽出する場合、抽出されたデータは元のドキュメントまで追跡可能でなければなりません。すべてのLieferscheinを構造化したExcelアーカイブ — Lieferscheinnummer、Lieferdatum、仕入先で検索可能 — は、名前を変更したPDFのフォルダよりもはるかに監査要件を満たします。

ドイツのバーコードおよびサプライチェーン標準を担う標準化団体GS1 Germanyは、デジタル納品書（dLS）仕様を公開しています — 機械可読なXMLを埋め込んだPDF/A-3形式（請求書におけるZUGFeRDに類似）。dLS標準は、LieferscheinnummerやBestellnummerから荷物単位の詳細やFahrer（ドライバー）情報まで、30以上のフィールドを持つ構造化データモデルを定義しています。大手小売業者とそのFMCGサプライヤーの間で採用が進んでいますが、ドイツのサプライヤーの大多数 — 特に中小企業 — は依然としてPDFまたは紙のLieferscheinを発行しています。ほとんどの受領チームにとっての現実は混在です：大手サプライヤーからの構造化されたDESADV EDIメッセージ、中堅サプライヤーからの非構造化PDF、小規模なHandwerksbetriebeからの紙の伝票。この3つすべてに対応する抽出が、今日のフォーマットの混沌と明日の標準化されたデジタル納品書をつなぐ架け橋となります。

ステップバイステップ：PDF Lieferscheinから構造化Excelへ

このワークフローは、SAP、Lexware、sevDesk、DATEV、またはスキャンした紙から得たドイツの納品書PDFの束があり、Lieferscheinの明細行ごとに1行、すべてのサプライヤーで一貫した列を持つ1つのExcelファイルを作成したい場合を想定しています。

ステップ1：抽出列を定義します。 入力した列名が出力スプレッドシートのヘッダーになります。包括的なドイツのLieferschein抽出には、まず以下から始めてください：

列名がドイツ語なのは、ドキュメントに表示されているのがドイツ語だからです。AIはPDF上の「Lieferscheinnummer」を読み取り、あなたの「Lieferscheinnummer」列にマッピングします — 意味が一致しています。出力の列ヘッダーを英語（例：「Delivery Note Number」）にしたい場合は、そちらを入力しても構いません。AIは「Delivery Note Number」と「Lieferscheinnummer」が同じ概念を指すことを理解しているため、ドキュメント上の対応するドイツ語フィールドを引き続き見つけ出します。

ステップ2：即時の差異チェックのために計算列を追加します。 生のフィールドが揃ったら、抽出中に結果を計算する列を定義できます — 後でExcelで数式を組む必要はありません。例えば：

• Differenz（Bestellt − Geliefert） — Bestellnummer参照に保存された発注数量から納品数量を差し引きます。Lieferscheinに「bestellte Menge」（発注数量）列が含まれている場合に便利です。
• Lieferstatus — オプション（Vollständig、Teillieferung、Überlieferung）を使用した推論列で、発注数量と納品数量に基づいて各納品を分類します。
• MHD-Status — 食品/医薬品の納品では、LieferscheinにMindesthaltbarkeitsdatum（賞味期限）が含まれている場合、期限が近い、または過ぎた品目にフラグを立てます。

これが計算列の役割です：生の数値を抽出してからExcelの数式を実行する代わりに、ロジックを列定義として一度定義すれば、AIが抽出中に比較を実行します。差異がすでにフラグ付けされた完成済みのスプレッドシートが得られます。

ステップ3：すべてのLieferscheinを一度にアップロードします。 PDFをアップロードエリアにドラッグしてください — 大口サプライヤーのSAP Lieferschein、HandwerksbetriebeのLexware Lieferschein、オンライン小売業者のsevDesk Lieferschein、デジタル化していないサプライヤーのスキャンした紙のコピーなど。AIは各ドキュメントを個別に読み取り、どのソフトウェアがどのPDFを生成したかに関係なく、同じ列セットにデータを入力します。

ステップ4：Excelにエクスポートします。 出力は1つの構造化されたスプレッドシートです — すべてのLieferscheinにわたる明細行ごとに1行で、各行にLieferscheinnummerが繰り返されるため、すべての明細行を元のドキュメントまで追跡できます。すべての金額と数量は一貫した形式で、すべての日付は単一の標準に正規化され、WMSへのインポート、発注書と請求書に対する三者照合、またはGoBD準拠のアーカイブにすぐに対応できます。

各行に納品書番号と発注書参照が含まれるLieferscheinスプレッドシートがあれば、サプライヤー別、日付別、注文別にフィルタリングでき、すべてのセルは元のPDF上の正確な位置まで追跡できます。

手書きの注記、複数ページのLieferschein、部分納品への対応

ドイツの物流では、単純な「印刷されたフィールドを抽出する」アプローチを破綻させる、繰り返し発生するエッジケースがいくつかあります。それぞれに独自の対応戦略が必要です。

手書きの注記と署名。Lieferscheinには手書きの追記が頻繁にあります。倉庫作業員が破損した数量を丸で囲んで「beschädigt」（破損）と書き込んだり、ドライバーが余白に「2 Kartons fehlen」（2箱不足）とメモしたり、受領担当者が下部に署名と日付を記入したりします。これらの注記には業務上の意味があります。AIは手書き文字を読み取ります。注記のあるLieferscheinを明るい照明で撮影した写真は、原本とほぼ同様に機能します。ただし、手書き文字の精度は印刷文字よりも本質的に低くなります。主要な印刷フィールド（Lieferscheinnummer、Artikel、Menge）については、鮮明なPDFや写真での精度は印刷文書の標準と同等です。走り書きの余白メモについては、精度は低下しますが実用可能な結果が得られます。ワークフローが手書きの注記に依存している場合は、「Anmerkungen」（注記）専用の列を追加し、その行を手動で確認することを検討してください。

複数ページのLieferschein。40品目の納品はA4用紙1枚には収まりません。Lieferscheinは2ページ、3ページ、あるいはそれ以上に及び、ヘッダーは1ページ目のみに記載され、明細テーブルはページをまたいで続きます。AIは文書全体を1つの論理単位として読み取ります。1ページ目のLieferscheinnummerは、2ページ目や3ページ目の明細に関連付けられます。出力では、ヘッダーフィールドが物理的に1回しか出現しない場合でも、すべての明細行にヘッダーフィールドが正しく繰り返されます。

部分納品（Teillieferungen）。サプライヤーが注文の一部を先に発送し、残りを後で発送する場合、1つのBestellnummerに対して2つのLieferscheinが発行されます。最初のLieferscheinには「1. Teillieferung」（第1回部分納品）や「Rest folgt」（残りは後送）といった注記が付くことがあります。これらの注記をスプレッドシートに抽出することで、二重計上を避けたり、すべての部分納品が到着する前に注文を完了と誤ってマークすることを防ぐためのコンテキストが得られます。

Lieferscheinが、ドイツで事業を行いながらフィールドラベルに英語、フランス語、その他の言語を使用している国際的なサプライヤーから届く場合も、AIは多言語文書に対応します。「delivery note number」「numéro de bon de livraison」「Lieferscheinnummer」はすべて、お好みの言語で列を定義すれば同じフィールドにマッピングされます。ドイツのサプライチェーンで繰り返し発生する文書タイプの詳細については、梱包明細のフォーマットの不統一が倉庫の受領業務を破綻させる理由に関するガイドをご覧ください。

FAQ：ドイツの納品書データ抽出

AI抽出は手書きのLieferscheinや紙の写真コピーでも機能しますか？

はい、適切な入力品質であれば機能します。AIは画像からテキストを読み取るため、印刷されたLieferscheinを十分な明るさで撮影した写真は、元のPDFとほぼ同様に扱えます。手書きの追記 — ドライバーの余白メモ、受領担当者の署名、手書きで修正された数量 — も抽出できますが、手書きの精度は印刷テキストより本質的に低くなります。主要な印刷項目（Lieferscheinnummer、Artikel、Menge）については、PDFと同じ精度が期待できます。密集した手書きの注記については、精度は低下しますが実用的な結果が得られます。手書き項目は必ず原本と照合してください。

SAP、Lexware、sevDesk、紙のLieferscheinを同じバッチで処理できますか？

はい。抽出はテンプレートベースではなくセマンティックであるため、同じ列名のセット（Lieferscheinnummer、Lieferdatum、Artikel、Menge）が、どのソフトウェアで作成されたドキュメントでも正しい値を特定します。すべてのLieferscheinを1つのバッチでアップロードできます — SAPのサプライヤーから5件、Lexwareユーザーから8件、sevDeskから3件、スキャンした紙から2件 — 出力はすべてのソースで一貫した列を持つ1つの統合Excelファイルです。サプライヤーごとの設定も、テンプレートの切り替えも不要です。

抽出列には常にどの項目を含めるべきですか？

最低限：Lieferscheinnummer（各行を元のドキュメントに紐付け）、Lieferdatum（タイムライン追跡用の受領日）、Bestellnummer（三者照合のための発注書参照）、ArtikelnummerとArtikelbezeichnung（何が納品されたか）、Menge（数量）。トレーサビリティが必要な商品を扱う場合は、Chargennummer（ロット番号）とMHD（賞味期限）を追加してください。発注書と照合する場合は、Lieferscheinに記載があればbestellte Menge（発注数量）を追加し、計算列を使って差異を自動的にフラグ立てしてください。

ドイツのLieferschein抽出ではどの程度の精度が期待できますか？

印刷された判読可能なPDFの場合、主要な識別項目（Lieferscheinnummer、Lieferdatum、Bestellnummer）と数値項目（Menge、Einheit）は通常95%以上の精度に達します。品目説明、特に小さなフォントの長いドイツ語複合語は、精度がやや低くなる場合があります。手書きの注記は最も精度が低くなります。正直な推奨事項：最初の抽出実行を元のドキュメントと照合してスポットチェックしてください。特にLieferscheinnummerとMenge — この2つは照合の要となる項目です — を確認し、出力に誤りがあれば修正してください。1つのセルを修正しても、同じドキュメントの他の項目やバッチ全体には影響しません。

同じ注文からの部分納品（Teillieferungen）はどのように処理されますか？

各部分納品には固有のLieferscheinnummerがあります。両方のLieferscheineが同じBestellnummerを参照している場合、Bestellnummer列がスプレッドシート上でそれらをグループ化します。Bestellnummerでフィルタリングすれば、その注文のすべての部分納品を確認でき、計算列で行をまたいでgelieferte Mengeを合計し、納品合計が注文数量全体と一致するかチェックできます。AIは部分納品をマージしません — 各Lieferscheinの内容がそのまま表示されます — ただし構造化されたスプレッドシートなら集計は簡単です。

LieferscheinデータをExcelに抽出することはGoBDのアーカイブ要件に準拠していますか？

抽出されたデータは、元のPDFのアーカイブの代替にはなりません。GoBDでは、受け取った形式（PDF、スキャン、紙）で元のLieferscheinを保持する必要があります。抽出されたExcelは補助的な作業用コピーです。ただし、構造化されたExcelアーカイブ — Lieferscheinnummer、Lieferdatum、仕入先で検索可能 — は、Betriebsprüfung（税務調査）の際に元のドキュメントを特定・取得する能力を大幅に向上させます。抽出プロセスはアーカイブを置き換えるものではなく、アーカイブされたドキュメントを活用可能にします。