ドイツの請求書80件、1つのスプレッドシートに
手入力なしで一括Rechnung処理を実現する方法

80件の請求書が届いたとき — バッチ処理は「単純な80倍」ではない理由

1件ずつ処理する方法は、限界が来るまでは機能します。多くのドイツ企業では、月間の入金請求書が30～50件の間で転換点を迎えます — 「金曜の午後に片付けられる」と「週末が潰れる」の差が生まれる閾値です。80件の請求書の場合、問題は1件あたりのデータ入力速度ではありません。単一請求書のワークフローには4つの構造的問題があり、バッチ処理はそれを受け継ぎ増幅させます：

フォーマットのばらつき。 請求書を1件ずつ処理し、LexwareやsevDeskに手動でデータを入力する場合、脳はレイアウトの違いを補正します — Metroの請求書の「Rechnungs-Nr.」とTransgourmetの請求書の「Rechnungsnummer」が同じ項目だと認識します。自動バッチ抽出には、テンプレートの位置ではなく意味的な意味で何を探すべきかを教えていない限り、そのような直感はありません。8つの仕入先、8つのレイアウト、そしてそれらすべてを1つのスプレッドシートに混在させるバッチ出力。

VATの断片化。 ドイツの入金請求書は一律のVAT税率を使用しません。ホスピタリティ仕入先からの80件の請求書バッチでは、最大4つのVAT処理が出現します：標準19％（設備、清掃）、軽減7％（食品、書籍）、§13b逆チャージ（下請け建設作業）、§19小規模事業者（VATなし）。各請求書から数値を取得する単一の「税」列は無意味です — その数値は行ごとに異なる意味を持ち、Vorsteuerabzugの計算では種類ごとに分離する必要があるからです。各請求書の§14 UStG必須項目が抽出すべき内容を決定します — しかしバッチ処理では、その抽出を80行すべてで意味的に一貫させるという層が追加されます。

エラー伝播。80件の請求書を手入力する場合、各操作は独立しています。つまり、44番の請求書でタイプミスをしても、45番に影響することはありません。一方、一括抽出では、AIがロゴの位置ずれにより1件の請求書の仕入先名を誤認識した場合、全出力を確認するまで気づきません。また、列マッピングがずれている場合（たとえば、日付の形式が異なる仕入先で、Leistungsdatum列がRechnungsdatumを取得してしまった場合）、気づいた行だけでなく、すべての行をチェックする必要があります。

トレーサビリティの欠如。80行の結合スプレッドシートでは、各行がどのファイルから来たのかがわかる必要があります。元の請求書に戻ってUSt-IdNrを確認したり、割引行をチェックしたりするには、信頼できるファイル名と行のマッピングが必要です。ソース文書の列がないCSVを出力するバッチツールでは、監査がダウンロードフォルダの中の宝探しゲームになります。

これらの問題は、3件の請求書を処理する場合には発生しません。80件になると、4つすべてが同時にアクティブになります。そして、これらを解決することが、バッチ処理ワークフローを「単一抽出を80回繰り返すこと」から区別するポイントです。

仕入先フォーマット問題 — 1つのスプレッドシートに8つの異なるレイアウト

Metroの請求書とTransgourmetの請求書は、§14 UStGに基づく同じ法的構造を共有していますが、見た目はまったく異なります。MetroはRechnungsnummerを右上ブロックに配置し、Transgourmetはテーブルヘッダーに配置します。地元のパン屋は、仕入先住所ブロックに明示的なラベルがまったくなく、左上隅にあり通り名で始まるため認識する手書きの請求書を送るかもしれません。これが、ドイツの請求書に対するテンプレートベースの一括抽出に反対する核となる論拠です。新しい仕入先ごとに、新しい抽出テンプレートを構築し維持する必要があります。

わかりやすく言うと、中規模のドイツのレストラングループが受け取る請求書は、メトロ（食品卸）、トランスグルメ（飲料）、地元のGemüsehändler（青果）、複数のGetränkelieferanten（飲料販売業者）、清掃サービス、Wartungsfirma（設備保守）、マーケティング代理店、そして時々の単発サプライヤーから届きます。これだけで8種類もの請求書フォーマットがあり、さらにメトロ内でも標準請求書、納品書、ストルノ請求書でレイアウトは同じでもフィールド配置が異なります。テンプレートベースのツールでは、バリエーションごとに個別設定が必要です。セマンティック抽出なら、列名を一度定義するだけで済みます。

これが、列名アプローチとテンプレートアプローチの規模における違いです。カスタム列抽出 — ImageToTable.aiが採用する仕組み — は、座標ではなくフィールドの意味を理解して動作します。希望する列名「Rechnungsnummer」「Lieferant」「Rechnungsdatum」「Leistungsdatum」「Nettobetrag」「USt-Satz」「USt-Betrag」「Bruttobetrag」「USt-IdNr」を入力するだけで、AIがラベルの意味を理解し、ラベルテキストが「Rechnungs-Nr.」「Rechnungsnummer」「RNr.」と異なっていても、バッチ内のすべての請求書から各値を特定します。1つの列定義で、1回のバッチアップロードで8種類のサプライヤーレイアウトすべてをカバーします。

実務上のメリット：月間のEingangsrechnungenフォルダ全体 — 全サプライヤーからの80件のPDF、JPG、スキャン文書 — をアップロードするだけで、フォーマットに関係なく、各行が同じ列を持つ1つの統合スプレッドシートが得られます。サプライヤーごとのテンプレート不要、フォーマットの事前仕分け不要、「このサプライヤーの請求書はレイアウトが違うので別々にアップロード」も不要です。

80件の請求書におけるVAT税率の分割 — 「税」列1つでは破綻する理由

さて、バッチ抽出がうまくいったと仮定しましょう。80件すべての請求書が一貫した列でスプレッドシートに取り込まれています。次の問題は、USt-Satz列に19%、7%、0%（または空白）、そして「§13b」という4つの異なる値が含まれており、それぞれ異なる会計処理が必要なことです。単純にUSt-Betrag列をSUMで合計すると、§15 UStGに基づきVorsteuerabzug（仕入税額控除）の対象となる19%の通常税率、控除は可能だがUmsatzsteuervoranmeldungの66行目で個別報告が必要な7%の軽減税率、そして税務上の義務が受取側に移るため控除はなく別途報告義務が生じる§13bの金額が混ざってしまいます。

Umsatzsteuervoranmeldung（ドイツの月次または四半期ごとの付加価値税前納申告書、ELSTERを通じて提出）では、VAT額を特定の税コード（Kennzahlen）で報告する必要があります。

バッチ抽出でこれを扱う実用的な方法として、「推測列」を定義します。これは、ページに明示的に記載された値を抽出するのではなく、AIが請求書の内容に基づいて分類する列です。例えば、VATタイプ（選択肢：標準19％／軽減7％／§13b リバースチャージ／Kleinunternehmer §19）という名前の列は、AIに各請求書を読み取らせ、該当するVAT制度を判断させ、正しいカテゴリラベルを出力するよう指示します。これによりフィルタリング可能な列が得られ、そこからVATタイプごとにグループ化し、各グループのUSt-Betragを合計してVorsteuerabzugの申告に使用できます。抽出と分類は1回の処理で行われ、2回の別々の操作は必要ありません。

これは、Buchhaltungの経費側でも重要です。§13bの請求書のNettobetragは、仕入税額がゼロであっても、依然として営業費用（Aufwand）です。「税がない＝関係ない」として経費集計から除外すると、費用を過少報告することになります。バッチ抽出では、VAT関連の部分だけでなく、財務全体の状況を把握する必要があります。

バッチ抽出から税理士へ — 1回のエクスポートでDATEV対応

80件の請求書をスプレッドシートに抽出すれば、データ入力の問題は解決します。しかし、そのスプレッドシートを税理士がDATEVにインポートできる形に変換する「引き継ぎ」の問題は自動的には解決しません。ドイツの税理士はDATEVのKanzlei-RechnungswesenやUnternehmen Onlineプラットフォームを使用しており、これらは主に2つのバッチメカニズムを通じてデータをインポートします。

CSVインポート（DATEV形式） — Kanzlei-Rechnungswesen向けの固定長CSV。フィールド順序は「Belegdatum（伝票日付）」「Buchungstext（記帳テキスト）」「Gegenkonto（相手勘定）」「Betrag（金額）」「Soll/Haben（借方/貸方）」、オプションで「Buchungsschlüssel（転記キー）」と「Kontierung（SKR03またはSKR04の勘定科目番号）」です。区切り文字はセミコロン、エンコーディングはISO-8859-1、日付形式はDD.MM.YYYYを使用する必要があります。英語ツールからデフォルトのカンマ区切りやMM/DD/YYYY形式でCSVをエクスポートすると、エラーなく失敗します。

XMLインポート（dxso-Jobs） — DATEV Unternehmen Online向け。DATEV独自のXMLスキーマを使用したバッチジョブ送信です。dxso（DATA XML Send Online）メカニズムは、DATEVのXSDスキーマで検証されたXML文書として請求書データを受け入れます。Unternehmen OnlineではXMLが必須で、CSVはデスクトップ版Rechnungswesenアプリケーション用です。税理士はワークフローに応じてどちらか、または両方を使用する場合があります。

重要なポイント：抽出カラムは、対象システムが期待するインポートカラムと一致させるべきです。 税理士がBelegdatumをDD.MM.YYYY形式で必要とする場合、抽出カラムは「Invoice Date」ではなく「Belegdatum」と定義します。経費を勘定科目4930（SKR03：その他費用）に計上する場合、「SKR03 Konto」というカラムを設け、適切なコードを入力します。これにより、汎用的な抽出結果を会計ソフトのスキーマに合わせて再フォーマットする中間作業が不要になります。抽出がそのままインポートファイルとなります。

DATEVに送る80件の請求書バッチの場合、カラムセットは次のようになります：

• 伝票日付 — DD.MM.YYYY
• 仕訳テキスト — 仕入先 + 請求書番号の組み合わせ
• 相手勘定 — 仕入先の債務者番号（SKR04では70000番台）
• 金額 — 総額（税込）
• 借方/貸方 — 「S」は借方（費用）、「H」は貸方
• SKR03勘定 — 費用勘定（例：雑費は4930、商品は3400）
• 税率 — 19、7、または0
• 前払消費税額 — 還付可能な消費税額

Lexware OfficeやsevDeskは独自のCSVテンプレートを使用しますが、原則は同じです。抽出列をインポートスキーマに合わせて定義し、CSVとしてエクスポートして直接インポートします。バッチ処理の価値提案（80枚の請求書を数分で処理）は、出力後にさらに1時間のスプレッドシート再フォーマットが必要ない場合にのみ完全に実現されます。

ワークフロー — 80件の仕入請求書を一括処理する方法

構造上の課題（形式の多様性、消費税の分散、DATEV互換性）を踏まえた上で、80件の請求書フォルダから税理士対応のスプレッドシートまでのエンドツーエンドのバッチワークフローは次のとおりです。

特に検証工程において、バッチ内で最もリスクが高いのは「明らかに間違っている」ように見える項目ではありません。むしろ、一見正しく見えるものの、仕入先固有のフォーマット上の癖によって特定のフィールドが系統的に誤読されているケースです。例えば、他の79件の請求書とは異なる方法でNettobetrag（正味金額）が配置されているMetroの請求書は、エラーとして表示されません。セルには数値が入り、その数値ももっともらしく見えます。これを捉えるチェックが「Bruttobetrag（総額）上位10件のスポットチェック」です。元のMetro請求書を開き、総額を抽出された総額と比較してください。一致すれば、抽出はおそらく正しいです。一致しなければ、調査すべきフォーマット上の癖があります。

GoBD準拠のバッチアーカイブ — Excelではなく原本を保存する

バッチ処理には魅力的な近道があります。80件の請求書を1つのきれいなスプレッドシートに抽出し、そのスプレッドシートをアーカイブして、乱雑な原本を削除することです。これは自動化された請求書処理における最も一般的なGoBDコンプライアンス違反であり、監査要件を複数の点で満たせなくなります。

GoBD（仕訳帳の適正な管理と保存に関する原則）は、2025年7月に改訂され、ドイツの電子請求書義務化に対応しています。これにより、税務関連文書は受領した原本の形式で保存することが求められ、派生版や変換版での保存は認められません。具体的には以下の通りです。

• 構造化電子インボイス（XRechnung XML、ZUGFeRDハイブリッドPDF）：XMLが税務上の正規記録です。ZUGFeRD PDFで受領した場合、埋め込まれたXMLを含むPDF/A-3ファイル全体を1つの単位として保存する必要があります。2025年7月の改正により、XMLに含まれない追加の税務関連情報（例：手書きの支払メモ）が視覚レイヤーにない限り、別途人が読めるPDFコピーは不要と確認されました。
• プレーンPDFおよびスキャン文書：原本ファイルは§147 AOに基づき10年間、改変せずに保存する必要があります。抽出したExcel行は作業用コピーであり、保存の代替にはなりません。
• 撮影した紙のインボイス：デジタル写真が記録となります。GoBDの不変性の原則により、写真ファイルはタイムスタンプ、ハッシュ化、または改訂ロックシステムで保存し、後からの改変を防ぐ方法で保管する必要があります。

抽出結果である80行のExcelスプレッドシートは、業務用文書であり保存用文書ではありません。日々の経理、仕入税額控除の計算、DATEVインポートに使用します。税務調査では、調査官は抽出スプレッドシートではなく、原本のインボイスファイルを要求します。抽出に必要なのは、それらの原本へのトレーサビリティを確保することだけです。つまり、スプレッドシートには各行のソースファイルを特定する列（ファイル名または参照番号）を含める必要があります。このトレーサビリティ列がないと、80件のインボイスを一括抽出しても、80のデータ行をソースと照合できず、抽出精度に関わらずGoBD違反となります。

実用的な一括アーカイブのワークフロー：原本ファイルを日付フォルダ（例：/Eingangsrechnungen/2026-05/）に保存し、一貫した命名規則（2026-05-03_Metro_INV-48291.pdf）に従い、抽出結果にファイル名を列として保持します。税理士がDATEV Unternehmen Onlineを使用している場合、Belegverwaltung（文書管理）機能を通じて、元の請求書ファイルを対応する仕訳に添付できます。これにより、スプレッドシートから原本、そしてDATEVの監査証跡に至るトレーサビリティが確保されます。

ドイツの段階的電子インボイス義務化（2025年1月から受領義務、2027年から売上高80万ユーロ超の企業に送付義務、2028年から全面義務化）により、「乱雑な原本」問題は徐々に解消されつつあります。サプライヤーがZUGFeRDやXRechnungに移行するにつれ、埋め込まれたXML層がOCRなしで構造化データを提供します。しかし移行期間中は、一括パイプラインでZUGFeRD PDF、プレーンPDF、2028年まで切り替えないサプライヤーからのスキャン済みRechnungenが混在します。抽出ワークフローはこれら3種類すべてに対応し、アーカイブワークフローはそれぞれの元の形式を保持する必要があります。

よくある質問

ドイツ語請求書のバッチ処理ワークフローを始める

ドイツのEingangsrechnungen（仕入請求書）のバッチ処理は、ある特定の分岐点に位置しています。それは、請求書の件数が「手入力は面倒だが何とかなる」から「手入力が構造的な時間の無駄になる」へと変わる地点です。多くのドイツの中小企業にとって、そのラインは月間40～60枚の間にあります。それ以下では、摩擦はワークフロー（DATEVを開き、フィールドに入力し、保存する）に起因します。それ以上では、摩擦はシステム全体に及びます。すなわち、フォーマットの多様性、VATの断片化、そして個別請求書のワークフローでは解決できないトレーサビリティの欠如です。

ここで説明するバッチ処理アプローチ（サプライヤー形式を問わず機能する列名ベースの抽出、自動VAT分類のための推論列、DATEV準拠のエクスポートスキーマ）は、1枚あたりの処理速度だけでなく、システム全体の問題に対処します。18倍の効率向上（手動で1枚3分→抽出で5～10秒）は見出しとなる数字です。しかし、より大きな運用上の変化はこれです。1ヶ月分のEingangsrechnungen全体が1つの操作になるということです。80の操作を素早く行うのではなく、1つの操作を1回行う。その違いは、「データ入力が速くなった」と「データ入力が月末の締め処理からなくなった」の違いです。