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

ドイツの納品書に含まれるもの — なぜ請求書ではないのか

ドイツの納品書は、仕入先によって Lieferschein（納品書）または Warenbegleitschein（貨物添付書類）と呼ばれ、請求書（Rechnung）とは根本的に異なります。Lieferschein は 何が出荷されたか を記載します。請求書は 何を支払うべきか を記載します。Lieferschein を請求書のように扱い、金額フィールドだけを抽出すると、受領数量、品目レベルの詳細、財務部門と運用部門の両方が必要とする受領側の注釈が記録されなくなります。

ヘッダーセクション。 すべての Lieferschein は、送り主と受取人の詳細から始まります。Absender（送り主/仕入先）— 会社名、住所、多くの場合 Lieferantennummer（仕入先番号）— および Empfänger（受取人）と Lieferadresse（配送先住所）。これらの下に、3つの識別フィールドが文書を固定します。Lieferscheinnummer（納品書番号、仕入先が割り当てる一意の識別子）、Lieferdatum（納品日 — 商品が出荷または到着した日）、および Bestellnummer（発注番号、社内のPO参照番号）。一部の 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カートン破損」、「Nachlieferung folgt/後日納品予定」、「1 Palette fehlt/1パレット不足」— には、スプレッドシートで取得する必要がある運用情報が含まれています。

テンプレート抽出が失敗する理由：サプライヤーごとに異なる書式の問題

テンプレートベースのOCRは、最も一般的な文書抽出方法です。1つの文書レイアウトで学習し、以降のすべての文書でそのレイアウトに一致させようとします。SAPで生成されたPDF上の座標(x=140, y=95)に「Lieferscheinnummer」のバウンディングボックスを設定すると、システムはその後、それらの正確なピクセル位置でテキストを探します。これは標準化された政府のフォームでは機能しますが、ドイツのLieferschein（納品書）では機能しません。なぜなら：

中規模メーカーからのSAP S/4HANA Lieferscheinは、ヘッダーブロックを左上の密集したグリッドに配置し、明細テーブルは8列以上でページ幅いっぱいに広がり、フッターは右下にあります。小規模なHandwerksbetrieb（手工業事業所）からのLexware Faktura Lieferscheinは、すべてを縦に積み重ねます。送信元は左上、受信先は右上、明細はシンプルな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」と書きます。抽出システムがこれらすべてが同じ概念を指すことを理解すれば、出力に1つの統合された列が得られます。サプライヤーごとのマッピングは不要です。

GoBD・HGBの枠組み：効率性を超えて、正確な抽出が重要な理由

Lieferscheinデータを抽出する意義は、単なる時間節約にとどまりません。ドイツの商法・税法には、納品書データを構造化し、検索可能にし、アーカイブすることを求める構造的な理由があります。

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

より実務的に重要なのはGoBD（電子形式による帳簿、記録、書類の適正な管理・保存の原則）です。これは連邦財務省（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が山ほどあり、それを1つのExcelファイルにまとめたい場合を想定しています。各行がLieferscheinの明細項目に対応し、すべての仕入先で一貫した列構成にします。

ステップ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：すべてのLieferscheineを一括アップロード。アップロードエリアにPDFをドラッグ＆ドロップ — 大手サプライヤーのSAP Lieferscheine、手工業事業所のLexware Lieferscheine、オンライン小売業者のsevDesk Lieferscheine、未デジタル化のサプライヤーからのスキャン紙コピー。AIが各書類を個別に読み取り、どのソフトウェアで生成されたPDFでも同じ列セットを自動入力します。

ステップ4：Excelにエクスポート。出力は1つの構造化スプレッドシート — すべてのLieferscheineの明細行ごとに1行、各行にLieferscheinnummerが繰り返し表示され、各明細が元の書類にトレース可能です。すべての金額と数量は統一された形式、すべての日付は単一の標準に正規化され、WMSインポート、POや請求書との三者照合、またはGoDB準拠のアーカイブにすぐに使用できます。

各行に納品書番号とPO参照が含まれる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：ドイツ納品書データ抽出

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

はい、適切な入力品質があれば可能です。AIは画像からテキストを読み取るため、印刷されたLieferscheinを明るく撮影した写真は、元のPDFとほぼ同様に機能します。運転手のメモ、受取係の署名、手書きで修正された数量などの手書きの追記も抽出できますが、手書きの精度は印刷されたテキストよりも本質的に低くなります。主要な印刷フィールド（Lieferscheinnummer、Artikel、Menge）については、PDFと同等の精度が期待できます。手書きの注釈が多い場合は、精度は低下しますが使用可能な結果が得られます。手書きフィールドは常に原本と照合してください。

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

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

抽出列には常にどのフィールドを含めるべきですか？

最低限：Lieferscheinnummer（各行を元のドキュメントに紐付け）、Lieferdatum（タイムライン追跡のための受領日）、Bestellnummer（3ウェイマッチングのための発注書番号）、ArtikelnummerとArtikelbezeichnung（納品されたもの）、Menge（数量）。トレーサブルな商品を扱う場合は、Chargennummer（ロット番号）とMHD（賞味期限）を追加します。発注書と照合する場合は、Lieferscheinに含まれているときにbestellte Menge（注文数量）を追加し、計算列を使用して自動的に差異をフラグ付けします。

ドイツのLieferschein（納品書）の抽出精度はどの程度ですか？

印刷された鮮明なPDFの場合、主要な識別フィールド（Lieferscheinnummer、Lieferdatum、Bestellnummer）や数値フィールド（Menge、Einheit）は、通常95%以上の精度に達します。品目説明、特に小さなフォントで書かれた長いドイツ語の複合語は、やや精度が低下する可能性があります。手書きの注釈は最も精度が低くなります。正直なアドバイス：最初の抽出結果を元の文書と照合し、特にLieferscheinnummerとMenge（照合の2つの基準）の誤りを修正してください。1つのセルを修正しても、同じ文書やバッチ内の他のフィールドには影響しません。

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

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

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

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