ドイツのE-Rechnung義務化：2027年1月1日までに自社システムから構造化インボイスを発行する
2027年1月1日から、2026年の売上高が80万ユーロを超えるドイツの事業者は、ほかのドイツの事業者に紙やPDFの請求書を送れなくなります。請求書は構造化された電子インボイス、つまり欧州規格EN 16931に沿って作られたデータファイルでなければなりません。2028年1月1日にはこの基準額がなくなり、ごく限られた例外を除いて、すべての事業者にこのルールが適用されます。
小規模な会社にとっては、ソフトウェアのアップデートとしてやってくる変化です。自社の請求システム、業界向けパッケージ、あるいは15年かけてカスタマイズしてきたERPから請求書を出している会社にとっては、ソフトウェアのプロジェクトであり、残りは約13週間です。この記事は後者の会社のためのものです。
法律の規定
定義は§ 14 UStGにあります。電子インボイスとは、構造化された電子形式で発行・送信・受領され、電子的な処理を可能にする請求書（「die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht」）です。フォーマットは、指令2014/55/EUに基づく欧州規格（実務上はEN 16931）に準拠しているか、当事者間で合意したものでなければなりません。後者の場合は、必要なデータをその規格と互換性のある形に、正しく漏れなく抽出できることが条件です。PDFは、どれほど整っていても該当しません。
義務の対象は、双方がドイツ国内に拠点を置く事業者間の供給です。経過措置は§ 27 Abs. 38 UStGに定められています。
- 2025年と2026年に行った供給は、請求書を2026年12月31日までに送る限り、引き続き紙で、または顧客が同意すれば別の電子形式で請求できます。
- 2027年に行った供給にも2027年12月31日まで同じ猶予がありますが、発行者の前暦年の総売上高が80万ユーロ以下の場合に限られます。
- 規格を満たさないEDIは、顧客の同意があれば、事業規模にかかわらず2027年に行った供給について継続できます。
見た目以上に重要な点が3つあります。
基準額は前年の売上高で判定します。 2027年にどちら側に入るかは2026年の数字で決まり、その数字は決算が締まるまで誰にも正確には分かりません。80万ユーロに少しでも近いなら、超えている前提で構築してください。
猶予は送付日で終わります。 文言どおりに読めば、最初の経過措置が紙とPDFを認めるのは2026年12月31日までで、2026年に行った作業の分も同じです。基準額を超えていて後払いで請求しているなら、12月分の作業について1月の第1週に送る請求書は、すでに構造化されていなければなりません。税理士に確認すべき点ですが、1月半ばの稼働開始を計画するのはやめてください。
対象外のままの請求書もあります。 消費者向けの請求書、国境を越える取引の請求書、税込250ユーロまでの少額請求書、請求書とみなされる乗車券類、Kleinunternehmer（小規模事業者）の請求書、そして§ 4 Nr. 8から29 UStGにより非課税とされる供給です。
これらの日付を動かす法案は、当社の知る限りありません。日付は変わらないものとして計画してください。
受信は2025年から義務。新しいのは発行です
2025年1月1日から、すべてのドイツの事業者は電子インボイスを受信できなければならなくなっています。そのために何が必要かについて、連邦財務省の電子インボイスに関するFAQは率直です。「Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.」つまり、メールの受信箱があれば足ります。
§ 14そのものにある一文にも注意してください。電子インボイスの義務が適用される場合、受領者の同意は必要ありません。ドイツの事業者である顧客は、構造化された請求書の受け取りを拒めません。
発行は別の問題です。受信では、ツールが他社の作ったファイルを読みます。発行では、自社のシステムが作成者です。元のデータが間違っていれば、その先の誰にも直せません。そして顧客側の検証で不合格になった請求書は、支払われないまま放置されます。
アップデートで済む会社
はっきり言うと、DATEV、lexoffice、sevDeskなどのパッケージで請求している小規模な会社なら、フォーマットはベンダーが提供します。マスタデータ（VAT ID、顧客の住所、銀行口座情報）を確認し、機能を有効にして、テスト請求書を1通送ってください。プロジェクトは要りませんし、ソフトウェア会社に頼む必要もありません。
標準からあまり離れていない主要なERPも、ほぼ同じです。出力はベンダーやパートナーが用意し、作業は設定とテストです。
この記事の残りは、自社が保有するコード、あるいはもう誰も保守していないコードから請求書を出している会社向けです。
- サブスクリプション基盤、マーケットプレイス、公益事業の請求エンジン。プログラムで大量の請求書を発行しているもの。
- 卸売、建設、物流、フィールドサービス向けの業界ソフトウェアで、ベンダーが小さい、対応が遅い、あるいはもう存在しないもの。
- 何年も前に、請求書の出力を独自の印刷プログラム、帳票テンプレート、月末の差し込み印刷に書き換えたERP。
フォーマット：EN 16931、XRechnung、ZUGFeRD
EN 16931は欧州規格です。請求書の意味モデル（項目、その意味、どれが必須か、項目間の業務ルール）を定め、それをUBL 2.1とUN/CEFACT CIIという2つのXML構文に対応づけています。
XRechnungは、EN 16931の上に乗るドイツの仕様で、KoSITが管理しています。どちらかの構文による純粋なXMLで、公的機関が求める形式ですが、事業者間でも同じく有効です。KoSITのXRechnungのページによれば、バージョン3.0は2024年2月1日から有効で、少なくとも2027年7月31日までは有効です。4.0の暫定版は2026年9月に公開され、正式版は2027年春の予定です。稼働開始は3.0で行い、1年目のうちにアップグレードすることになります。
ZUGFeRDはハイブリッド形式です。CIIのXMLを埋め込んだPDF/A-3ファイルで、人はPDFを読み、機械はXMLを読みます。フランスでは同じ形式がFactur-Xと呼ばれ、両者は技術的に同一です。FeRDは2026年8月4日にバージョン2.5.2を公開しました。ZUGFeRDにはプロファイル（MINIMUM、BASIC WL、BASIC、EN 16931、EXTENDED）があり、財務省のFAQは、バージョン2.0.1以降のZUGFeRDを「mit Ausnahme der Profile MINIMUM und BASIC-WL」（MINIMUMとBASIC-WLのプロファイルを除いて）認めています。
ハイブリッドの請求書では、XMLが正本です。FAQは構造化部分を「führender Teil」（主たる部分）と呼んでいます。PDFとXMLが食い違えば、間違っているのはPDFです。
ドイツのB2B発行者の多くにとって妥当な既定値は、EN 16931プロファイルのZUGFeRDです。目で請求書を読んでいる顧客は、そのまま読み続けられます。これに加えて、公的機関と希望する相手にはXRechnungを出します。どちらも、2つのコード経路ではなく、社内の1つの請求書オブジェクトから生成すべきです。
システムで変えなければならないこと
請求書はレイアウトではなくデータになる
古いシステムの多くは、印刷する時点で請求書を組み立てます。テンプレートに文字列をつなぎ込み、合計は帳票の中で集計し、VATの注記は固定の段落です。そのどれもEN 16931では通用しません。すべての項目を保持する請求書オブジェクトを保存し、XMLとPDFの両方をそこから生成する必要があります。
欠けている、あるいは誤っていることが多い項目は次のとおりです。
- 取引当事者のデータ。 ISO国コード付きの構造化された住所と、VAT IDまたは税番号。自由テキストの住所欄は分割しなければなりません。
- 供給日またはサービス期間。 ヘッダーの一文としてではなく、データとして保持します。
- 単位。 数量にはそれぞれUN/ECE勧告第20号のコード（個はH87、キログラムはKGM、日はDAY）が必要です。「Stk.」や「pauschal」は対応づけなければなりません。
- VAT。 すべての明細行がVAT区分と税率を持ちます。請求書は区分と税率の組み合わせごとにVATの内訳を1つずつ持ち、合計は小数点以下2桁で正確に一致しなければなりません。行ごとにVATを丸めるシステムは、ここで引っかかります。
- 非課税とリバースチャージの文言。 PDFの末尾にあった一文が、VAT区分コードと非課税理由になります。
- 支払。 支払手段、IBAN、支払条件を構造化された形で持ちます。
- 参照番号。 顧客の買掛金担当者が照合に使う注文番号や購入者参照です。保存してこなかったなら、いまから取り込み始めてください。
テキストだけの明細行（「合意どおり納品」など）は、よくあるつまずきどころです。構造化された請求書では明細行は請求対象の行なので、そうしたテキストは注記に移します。
訂正、クレジットノート、自己請求
FAQは明確です。電子インボイスの義務が適用される場合、訂正も、訂正用の請求書種別を使った電子インボイスでなければなりません。EN 16931では、訂正は先行する請求書を番号と発行日で参照するので、システムはそのつながりをデータとして保持する必要があります。
用語には注意してください。ドイツのVAT法で「Gutschrift」とは自己請求書のことで、事前の合意に基づいて顧客が発行するものです（§ 14 Abs. 2 UStG）。英語圏でクレジットノートと呼ばれるもの（値引きや取消し）は、ドイツでは訂正にあたります。多くのシステムは、両方に1つの文書種別を使っています。マッピングの前に分けてください。仕入先に対して自己請求をしているなら、それらの文書は自社システムが発行する請求書として扱います。
最終請求書では、構造化部分が添付を参照していれば、それまでの一部支払を添付に記載できます。FAQは、この扱いが2027年以降も続くことを確認しています。
送信前の検証
KoSITは、スキーマとSchematronルールに照らしてXMLを検査するオープンソースのバリデーターを公開しており、XRechnung用の公開設定もあります。コマンドライン、HTTPデーモン、ライブラリのいずれとしても動きます。これを送信経路に組み込んでください。すべての請求書を送る前に検証し、不合格になったものは担当者が決まっているキューに入れ、どの項目がどのルールに違反したかを示すようにします。
ZUGFeRDの場合は、埋め込まれたXMLをプロファイルのルールで検証し、PDF/A-3のコンテナは別に検査し、PDFに表示される合計がXMLと同じであることを確認します。
送信
FAQによれば、法律は「sieht keinen bestimmten Weg vor」、つまり送信経路を定めていません。ファイルを添付したメールで構いません。API、ダウンロード用のポータル、グループ内の共有ストレージでもよく、（財務省自身が挙げている例ですが）USBメモリでも構いません。ドイツ国内のB2BではPeppolは必須ではありません。
技術的な作業は顧客ごとに発生します。請求書の送付先アドレス、希望するフォーマット、何をどこに送ったかの記録です。送信に失敗した後の再送では、同じ請求書番号の同じ文書を送ります。1つの供給に2つの番号が付けば、それはソフトウェアではなく税務の問題です。
保存
少なくとも構造化部分は「unversehrt in seiner ursprünglichen Form」、つまり元の形のまま損なわずに保存しなければならず、§ 14b UStGは保存期間を発行年の末から8年と定めています。送ったバイト列をそのまま、ハッシュ値とともに保存してください。後でデータベースから請求書を再生成するつもりで計画してはいけません。その頃にはデータもコードも変わっています。受け取った電子インボイスも同じです。
2026年10月から12月の計画
元データがそれなりに整っていれば、13週間は集中して構築するには足ります。請求システムを置き換えるには足りません。
第1週から第2週：棚卸しと決定。 請求書が作られる場所をすべて洗い出します。手作業のクレジットノート、プロジェクトの最終請求書、大口顧客1社のためのスプレッドシートも含めます。2026年の売上高を基準額と照らし合わせます。既定のフォーマットを選び、生成機能を自社で作るか、電子インボイス事業者のAPIに請求データを送るかを決めます。
第2週から第4週：データのギャップ分析。 実際の請求書3か月分を、項目ごとにEN 16931と対応づけます。欠けているもの、コードにしなければならないもの、計算方法が違うものに印を付けます。プロジェクトの本当の規模が見えるのはここです。
第4週から第9週：構築。 請求書オブジェクト、マッピング、XMLとPDF/A-3の生成、送信経路のバリデーター、失敗キュー、アーカイブです。並行して、誰かがマスタデータを整え、顧客から請求書の送付先アドレスを集めます。
第9週から第11週：再実行とパイロット。 直近3か月の請求書を新しい生成機能に通し、1通残らず検証します。そのうえで、協力的な顧客数社とパイロットを行い、先方のシステムでファイルを読めるかを尋ねます。
第11週から第13週：凍結と運用手順書。 12月は変更を凍結します。失敗キューの担当者は誰か、訂正をどう発行するか、顧客が請求書を差し戻したら何をするかを書き留めます。12月分の作業に対する1月の請求書は、すでに対象です。
2027年1月。 稼働を開始し、最初の月末と最初のVAT申告が終わるまで、キューを毎日確認します。
2027年を通じて。 3.0が無効になる前にXRechnung 4.0へのアップグレードを計画し、基準額を下回るグループ会社も2028年1月1日より前に移行させます。
着手が遅れた場合は、出力の有効性ではなく自動化を削ってください。件数の多い請求書種別から自動化し、まれな文書は数週間、電子インボイスのツールを使って手作業で送ります。
ご相談先
当社は、請求書を作るシステムと法律が求めるフォーマットとの間をつなぐ仕組みを、お客様のコードベースの中で、チームと並走しながら構築しています。データモデルの変更、マッピング、検証、送信、アーカイブです。こうしたプロジェクトの進め方は電子インボイス連携サービスでご説明しています。義務化がERPの入れ替えの途中に重なる場合は、ERPモダナイゼーションをご覧ください。全体の日程は2026年EUデジタル規制ガイドにまとめています。
当社は税理士ではなくエンジニアです。対象範囲の判断はお客様のSteuerberater（税理士）に委ね、当社はその回答に沿って構築します。いま何が請求書を作っていて、毎月おおよそ何通を送っているかを、office@c9group.devまでお知らせください。