ドイツの請求書（Rechnung）データを
Excelに抽出する方法

なぜドイツの請求書は汎用抽出ツールでは対応できないのか

ドイツのRechnung（請求書）は、アメリカの請求書を翻訳したものではありません。これは、ドイツ付加価値税法（Umsatzsteuergesetz, UStG）第14条に準拠した法的文書であり、10の必須項目の有無が、企業が仕入税額控除（Vorsteuerabzug）を請求できるかどうかを決定します。項目が欠落していたり、形式が正しくない場合、税務署（Finanzamt）は仕入税額控除を否認する可能性があります。売り手はどちらにせよ支払いを受け取ります。リスクを負うのはあなたの企業です。

これが、英語の請求書では優れた性能を発揮する汎用OCRツールでも、ドイツの請求書では機能しない理由でもあります。これらのツールは、ドイツ法で法的に区別されるRechnungsdatum（請求書発行日）とLeistungsdatum（役務提供日）を区別するようには設計されていません。また、USt-IdNrがDE123456789の形式に従っているかどうかを検証しません。19%と7%の異なる付加価値税率を単一の「税額」列にまとめてしまい、ELSTERを通じて付加価値税予納申告書（Umsatzsteuervoranmeldung）を提出する際に使用できなくなります。

月に3件の国内請求書を処理し、すべてを手動でLexwareに入力しているのであれば、これらの問題は重要ではありません。しかし、月に80件のRechnungを25のドイツの仕入先から処理し、それぞれレイアウトが異なり、PDFの場合もあれば、写真に撮られた紙のコピーの場合もあり、§13bの逆課税方式が適用され、付加価値税の抽出が不要で異なる計上ロジックが必要な場合もあるとなると、これらの問題は非常に重要になります。

§14 UStGがドイツの請求書に実際に求めるもの

§14 Abs. 4 UStGには、完全なドイツの請求書に必ず記載すべき10の必須項目（Pflichtangaben）が定められています。会計目的でデータをExcelに抽出する場合、これらの各項目はスプレッドシートの列に対応します。1つでも欠けると、DATEVへのインポートや仕入税額控除の申請にデータが使えなくなる可能性があります。

2つの実務上の例外により、必須項目数は減ります。総額250ユーロ未満の請求書は、§33 UStDVに基づき少額請求書に該当し、必要なのは以下のみです：供給者名と住所、請求書発行日、商品・サービスの説明、総額、該当するVAT税率または§19の適用除外文言。また、§19 UStGに基づく小規模事業者（前年度の売上高が22,000ユーロを超えない事業者）の場合、請求書にVATを表示してはならず、代わりに§19に基づきVATが課されない旨の記載が必要です。抽出ルールは、請求書がどの区分に該当するかによって変わります。

ドイツVATの迷路：「税率」列1つでは足りない理由

ドイツの請求書の抽出ロジックは、適用されるVAT制度によって大きく変わります。単一の「VAT税率」と「VAT金額」の列ペアは、最も単純なケースでしか機能しません。ドイツの請求書は以下の4つのシナリオのいずれかに該当し、それぞれ異なる列定義が必要です：

複数のVAT区分にまたがるドイツの仕入先から請求書を受け取る企業（例：食品（7%）と備品（19%）をメトロやトランスグルメから購入するホスピタリティグループ）にとって、抽出ツールは請求書の種類ごとに異なる列構成を出力できる柔軟性が必要であり、すべての請求書を同じテンプレートに強制するものではありません。

AI抽出がドイツの請求書フォーマットを処理する仕組み

ここで、テンプレートベースのOCRとAI駆動型抽出の違いが明確になります。テンプレートベースのツールでは、仕入先ごとにフィールドの座標を定義する必要があります。メトロの請求書レイアウトはトランスグルメのものと異なり、さらに地元の手工業者の請求書とも異なります。新しい仕入先が増えるたびにメンテナンス負荷が増大します。

ImageToTable.aiは別のアプローチを採用しています。カスタム列抽出です。ツールにフィールドの位置を教える代わりに、「Rechnungsnummer」「Leistungsdatum」「Nettobetrag 19%」「USt-Betrag 19%」「Nettobetrag 7%」「USt-Betrag 7%」「USt-IdNr」といった列名を入力するだけで、AIがページ上のどこにあっても各値を、その意味を理解して特定します。これは仕入先のフォーマットを問わず機能し、ベンダーごとの設定は不要です。1つの列定義でメトロ、トランスグルメ、セルグロス、そして隣の独立した木工所にも対応します。

上のデモでドイツのRechnungをアップロードしてみてください。§14 UStGのフィールドに合わせて列を定義します — まずはRechnungsnummer、Rechnungsdatum、Leistungsdatum、Lieferant、Nettobetrag、USt-Satz、USt-Betrag、Bruttobetrag、USt-IdNr — そしてAIが抽出する内容を確認してください。同じ列定義は、別の仕入先の請求書レイアウトに切り替えても機能します。AIは位置ではなく意味を読み取るからです。

バッチ処理（MetroやTransgourmetの請求書を1か月分まとめてアップロード）では、ツールが各請求書を抽出し、マージされたスプレッドシートの1行に変換します。すべてのRechnungが1行として表示された1つのExcelファイルが作成され、仕入先、日付範囲、またはVAT税率でフィルタリングした後、Steuerberaterに引き渡す準備が整います。

抽出から会計処理へ：DATEV、Lexware、sevDeskのワークフローに求められるもの

データの抽出は作業の前半に過ぎません。ドイツでは、後半はそのデータを会計ソフトウェアに取り込み、Steuerberaterが手直しせずに使用できる形式にすることが求められます。各プラットフォームの要件は異なるため、出力先を考慮することが重要です。

DATEV — ドイツの税理士の推定60～70%が使用 — は、Kanzlei-Rechnungswesen（DATEV形式のCSV）またはUnternehmen Online（XML）を介したデータ入力を想定しています。CSV形式には、Belegdatum、Buchungstext、Gegenkonto、Betrag、そして最も重要な正しいBuchungsschlüssel（転記キー）とKontierung（SKR03またはSKR04に基づく勘定割り当て）という特定の列が必要です。Steuerberaterが事前にコード化された勘定科目を期待する場合、抽出出力にDATEV勘定科目番号の列を追加する必要があります。Kontierungを自分で行う場合は省略可能ですが、事前に確認してください。

Lexware Office（旧lexoffice） — 月額7.90ユーロで、ドイツの中小企業で最も広く使用されているクラウド会計プラットフォーム — は、独自のCSV構造または直接の銀行フィードを介してインポートします。取引を自動的に分類しますが、仕入先請求書データにはVAT検証のための仕入先のUSt-IdNrが含まれている必要があります。そのフィールドが抽出データにない場合、Lexwareはその請求書を手動レビュー用にフラグ付けします。

sevDesk — 月額€12.90のモダンなチャレンジャー — は、独自テンプレートを使用してCSVで取引先とBelege（書類）をインポートします。CSVアップロードは簡単ですが、Belegart（書類種別）の分類（Eingangsrechnung、Ausgangsrechnung、Gutschrift）が必要です。抽出でこれらを区別しない場合、インポート後に手動で行を再分類する必要があります。

共通点：ドイツの会計ソフトは、ドイツの請求書データ構造を前提としています。「仕入先」「日付」「合計」のみを出力する汎用的な抽出では、これらのプラットフォームがインポートを受け付ける前に、大幅な手動再フォーマットが必要になります。抽出列をターゲットソフトのスキーマに直接合わせる — 例えば、列名を「VAT Number」ではなくUSt-IdNr、「Date」ではなくBelegdatumにする — ことで、再フォーマットの手間が省けます。

同じ抽出アプローチは、複数の言語や形式で届く国際的な請求書にも有効です。列名の意味は、請求書の元の言語に関係なく一貫しているためです。

GoBDと電子請求書：抽出データの監査対応を維持する

ドイツでは、請求書データの抽出は効率性の問題だけでなく、記録保存に関する法的義務も伴います。GoBD（Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern）は、デジタル帳簿管理に関する税務当局のフレームワークです。その中核原則 — Nachvollziehbarkeit（トレーサビリティ）、Unveränderbarkeit（不変性）、Verfügbarkeit（可用性） — により、抽出されたすべてのデータポイントは元の請求書に遡って追跡可能でなければならず、元の請求書は§147 AOに基づき元の形式で10年間保存する必要があります。

2025年7月のGoBD改正により、電子インボイスのアーカイブに関する重要なポイントが明確化されました。構造化電子インボイス（XRechnungおよびZUGFeRD PDFに埋め込まれたXMLレイヤー）の場合、機械可読なXMLが正式な記録となります。人間が読めるPDFは、XMLに含まれていない税関連情報（例：視覚レイヤーに手書きされた転記メモや支払条件）が追加で存在する場合にのみアーカイブが必要です。ほとんどの企業にとって、抽出されたExcelファイルが作業用データセットとなりますが、監査人が求めるのは元のXMLファイルです。

ドイツのB2B電子インボイス義務化（E-Rechnungspflicht）は、以下のように段階的に施行されます。

• 2025年1月1日 — すべてのドイツB2B企業は、EN 16931準拠形式（XRechnungまたはZUGFeRD 2.1）の電子インボイスを受領できる必要があります。
• 2027年1月1日 — 前年度売上高が80万ユーロ超の企業は、電子インボイスを送信する必要もあります。
• 2028年1月1日 — すべてのドイツB2B企業は電子インボイスを送信する必要があります。国内B2B取引では、250ユーロ未満の少額請求書（Kleinbetragsrechnungen）および§19に基づく小規模事業者（Kleinunternehmer）を除き、紙およびPDFの請求書は受理されなくなります。

データ抽出における実際的な影響：受信する請求書の構成はすでに変化しています。受信トレイに届くZUGFeRD PDFには、埋め込まれたXMLデータレイヤーが含まれており、対応可能な抽出ツールはそれを直接読み取り、該当フィールドではOCRを完全にバイパスして100%正確な構造化データを提供できます。まだプレーンなPDF請求書（Rechnungen）を送信しているサプライヤー（2027年までの移行期間中は許可）に対しては、AI抽出がギャップを埋め、視覚的なPDFを読み取って同じ構造化カラムを出力します。

コンプライアンス上重要なのは、抽出ワークフローが抽出データと元文書の関連性を保持していることです。40件のRechnungを1つのExcelファイルに一括抽出し、Excelファイルのみを保管した場合、GoBD違反となります。原本（XML、PDF、スキャンした紙文書）は10年間、アクセス可能かつ検索可能な状態で保管しなければなりません。

よくある質問

ドイツの請求書データを必要な場所へ

ドイツの請求書データ抽出は、通常は別々に扱われる3つの課題——データ精度、税務コンプライアンス、ソフトウェア互換性——の交点に位置しています。どれか一つに優れたツールは、他の要素を軽視しがちです。テンプレートベースのOCRは単一の仕入先フォーマットには正確ですが、新しい仕入先ごとに再構築が必要です。Lexwareへの手動入力はデータ構造を適切に保ちますが、月30件を超える請求書には対応できません。ZUGFeRD XMLのAI解析は電子請求書で100%の精度を発揮しますが、今なお印刷・郵送する地元の電気工事士からの紙のRechnungには無力です。

セマンティック抽出——テンプレートの位置ではなく列名で必要な項目を定義する——に基づくワークフローは、これら3つの課題を同時に解決します。§14 UStGで要求される項目を抽出し、Umsatzsteuervoranmeldungに必要なVAT構造を保持し、会計ソフトのインポートスキーマに合致する列を出力します。そして、請求書がZUGFeRD PDF、仕入先のスマホ写真、2023年の紙文書のスキャンのいずれであっても、同じように機能します。