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

なぜドイツの請求書は汎用抽出ツールを打ち負かすのか

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

このため、汎用の請求書OCRツール（英語の請求書をうまく処理できるものでも）がドイツの請求書で機能しなくなるのも、このためです。これらのツールは、ドイツ法で義務付けられている法的に異なる2つの日付であるRechnungsdatum（請求書発行日）とLeistungsdatum（サービス提供日）を区別するようには作られていません。また、USt-IdNrがDE123456789形式に従っているかどうかを検証しません。19%と7%のVAT税率の区別を単一の「税」列にまとめてしまい、ELSTERを通じたUmsatzsteuervoranmeldung（ドイツのVAT予納申告）の提出には使用できません。

国内の請求書を月に3件処理し、すべてをLexwareに手入力しているなら、これらのことは問題になりません。しかし、25社のドイツの仕入先から月に80件のRechnungを処理する場合（それぞれレイアウトが異なり、PDFもあれば、紙のコピーを撮影したものもあり、VAT抽出が不要でまったく異なる転記ロジックが必要な§13bの逆チャージ処理が適用されるものもある）には、非常に重要になります。

§14 UStGがすべてのドイツの請求書に実際に要求していること

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

実際には、2つの特例により必須項目の数が減ります。税込250ユーロ未満の請求書は、§33 UStDVに基づき少額請求書（Kleinbetragsrechnungen）として扱われ、必要なのは以下のみです：供給者の氏名・住所、請求日、商品・サービスの内容、税込金額、適用されるVAT税率または§19の免責事項。また、§19 UStGに基づく小規模事業者（Kleinunternehmer）—前年度の売上が22,000ユーロを超えなかった事業者—の場合、請求書にVATを一切表示してはならず、代わりに§19に基づきVATが課されない旨の記載を含める必要があります。抽出ルールは、請求書がどの区分に該当するかによって変わります。

ドイツVATの迷路：1つの「税」列では不十分な理由

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

複数のVAT区分にわたるドイツの供給者から請求書を受け取る企業—MetroやTransgourmetから食品（7%）と設備（19%）の両方を購入する飲食グループによくあるシナリオ—の場合、抽出ツールは請求書の種類ごとに異なる列構造を出力できる柔軟性が必要であり、すべての請求書を同じテンプレートに強制するべきではありません。

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

ここで、テンプレートベースのOCRとAI駆動の抽出の違いが具体的になります。テンプレートベースのツールでは、サプライヤーごとのレイアウトにフィールド座標を定義する必要があります。Metroの請求書レイアウトはTransgourmetのレイアウトとは異なり、地元のHandwerkerのRechnungともまた異なります。新しいサプライヤーが増えるたびにメンテナンスの負担が増大します。

ImageToTable.aiは異なるアプローチを取ります：カスタム列抽出。フィールドがページ上のどこにあるかをツールに教える代わりに、列名を入力して抽出したい内容を定義します — 「Rechnungsnummer」「Leistungsdatum」「Nettobetrag 19%」「USt-Betrag 19%」「Nettobetrag 7%」「USt-Betrag 7%」「USt-IdNr」— するとAIはフィールドがどこにあるかではなく、その意味を理解してページ上の任意の場所から各値を特定します。これはサプライヤーごとの設定なしでフォーマットを横断して機能します：1つの列定義でMetro、Transgourmet、Selgros、そして隣の独立系Tischlereiまでカバーできます。

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

バッチ処理の場合 — 1ヶ月分のMetroとTransgourmetの請求書を一度にアップロード — ツールは各請求書を結合されたスプレッドシートの1行に抽出します。すべてのRechnungが1行になった1つのExcelファイルが得られ、Steuerberaterに渡す前にサプライヤー、日付範囲、VAT率でフィルタリングする準備が整います。

抽出から会計へ：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構造または直接銀行フィードを介してインポートします。取引を自動分類しますが、仕入先のUSt-IdNrがVAT検証用に含まれていることを期待します。そのフィールドが抽出にない場合、Lexwareは請求書を手動レビュー用にフラグ付けします。

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

共通点：ドイツの会計ソフトウェアはドイツの請求書データ構造を期待します。「Supplier」「Date」「Total」を出力する一般的な抽出では、これらのプラットフォームのいずれかがインポートを受け入れる前に、かなりの手動再フォーマットが必要になります。抽出列をターゲットソフトウェアのスキーマに直接合わせて定義する — 例えば、列名を「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日 — 前年度売上高が€800,000を超える企業は、電子請求書を送信することも義務付けられます。
• 2028年1月1日 — すべてのドイツのB2B企業は電子請求書を送信する必要があります。国内B2B取引では紙およびPDF請求書はもはや受け入れられません。ただし、€250未満のKleinbetragsrechnungenおよび§19に基づくKleinunternehmerは例外です。

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

コンプライアンス上重要なのは、抽出ワークフローが抽出データとソース文書の間の関連性を維持することです。40件のRechnungを1つのExcelファイルに一括抽出し、Excelファイルのみをアーカイブした場合、GoBDに違反します。元の文書 — XML、PDF、スキャンされた紙のいずれであっても — は10年間アクセス可能で取り出し可能な状態を維持する必要があります。

よくある質問

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

ドイツの請求書抽出は、通常別々に扱われる3つの関心事、すなわちデータ精度、税務コンプライアンス、ソフトウェア互換性の交差点に位置します。1つをうまく処理するツールは、他のものを無視する傾向があります。テンプレートベースのOCRは単一のサプライヤーの形式には正確ですが、新しいサプライヤーごとに再構築が必要です。Lexwareへの手動入力はデータを正しい構造に保ちますが、月30件を超える請求書には対応できません。ZUGFeRD XMLのAI解析は電子請求書で100%の精度を実現しますが、印刷して郵送する地元の電気技師からの紙のRechnungには何も対応しません。

セマンティック抽出（テンプレートの位置ではなく列名で必要なものを定義する）を中心に構築されたワークフローは、3つの関心事すべてを同時に処理します。§14 UStGが要求するフィールドを抽出し、Umsatzsteuervoranmeldungに必要なVAT構造を保持し、会計ソフトウェアのインポートスキーマに一致する列を出力します。また、請求書がZUGFeRD PDF、サプライヤーのカメラ付き携帯電話からの写真、2023年のスキャン済み紙文書のいずれで届いても、同じように機能します。