請求書データおよび各国が義務付けている電子請求書（e-invoice）のXML形式への変換

もし貴社が欧州連合内の顧客に請求書を発行している場合、その請求書は単なる書類ではなく、データファイルとしての役割を担うようになっています。2026年と2027年にかけて、各国で施行される規制により、請求書は税務当局や顧客の会計システムが人間が介在することなく読み取れるように、構造化されたXML形式で交換されることが求められています。

問題は、この要件がEU全体で適用されるものの、その形式が国によって異なることです。ドイツはXRechnungまたはZUGFeRDを希望しています。フランスはFactur-X、UBL、またはCIIを受け入れています。イタリアは長年FatturaPAを使用しています。ポーランドはKSeFを通じて申告を行っています。ベルギーはPeppolを使用しています。これら全てが、同じヨーロッパのセマンティック標準であるEN 16931に準拠していますが、それぞれ異なる形式でそれを表現しています。

その結果、企業は法令遵守にとどまらず、さまざまな課題に直面しています。例えば、企業のERPシステムが生成する請求書は、特定の国が要求する形式に再構成する必要があります。現在受け取る電子請求書はXML形式で提供され、データベースや会計システムにインポートする前に変換が必要です。また、すでに特定の形式に準拠した請求書を作成している企業に対して、別の形式での請求書作成を求められることもあります。例えば、XRechnungに対応しているサプライヤーに、ZUGFeRDで使用されるCII XML形式での請求書を要求されたり、イタリアの企業が国内でFatturaPA、国境を越えてPeppol BIS形式の請求書を送信したりするケースがあります。

これら3つの問題はすべて、ソースとターゲットが入れ替わった同じ問題であり、そのため、これらをまとめて1つにまとめる必要があるのです データマッピングソリューション 3つの別々のツールではなく、まとめて利用できるような仕組みです。

MapForceは、XML形式との間でデータの変換を行います

ほとんどの電子インボイス製品は、提供元が対応しているフォーマットのみをサポートしています。しかし、新しい規制が導入されたり、顧客から対応していないフォーマットでのデータ提供を求められたりすると、他の企業のロードマップに依存することになり、対応が遅れる可能性があります。

Altova MapForceは、別の角度からアプローチします。このツールでは、ソースとなる請求書データを、ロードしたスキーマ（UBL、CII、XRechnung、FatturaPA、または来年公開される国内フォーマットなど）に合わせてマッピングします。データマッピングのもう一方の側では、既存のデータの内容を読み取ります

ERPシステムや会計システムからのExcel形式およびCSV形式でのデータ出力
データベース、例えば請求システムで使用されているテーブルなど
APIや他のアプリケーションから提供されるXMLおよびJSONデータ
MapForceのPDF抽出機能を使用して、PDF形式のデータソースを処理します
EDI（Electronic Data Interchange：電子データ交換）では、請求書がEDIFACTやX12といった形式のメッセージとして送受信されます

その組み合わせこそが、この問題を「変換問題」ではなく「マッピング問題」たらしめている理由です。請求データは、通常、一箇所に綺麗にまとめられているわけではありません。その一部はERPシステムに、また一部は子会社が管理するスプレッドシートに、さらに一部はサプライヤーのPDFファイルに存在します。さらに、電子インボイスのXML形式は、国によって異なる場合があります。

MapForceでは、データマッピングプロジェクトを視覚的に構築できますそのため、請求書データの内容を理解している担当者は、コードを記述することなくマッピングを作成できます。また、2つ目の国向けの構築は、最初の国に比べて大幅にコストを抑えられます。なぜなら、社内システムとの連携はすでに構築されているため、そのマッピングをコピーし、新しい電子請求書フォーマットに置き換え、実際にフォーマットが異なる箇所のみを調整するだけで済みます。そのため、国ごとに別のツールを用意する必要はありません。

国ごとの電子インボイス基準

以下に、主要なEU市場における現状を示します。記載されているすべての形式は、EN 16931規格に準拠していますが、各国が受け入れる構文や、請求書が経由する経路が異なります。

|国|必要な形式|それが何であるか|状態| |---|---|---|---| |フランス|Factur-X、UBL、またはCII| Factur-Xはハイブリッド形式であり、PDF/A-3ファイルの中にXMLデータが埋め込まれています。 UBLとCIIは、どちらも純粋なXML形式です。請求書は、承認されたプラットフォーム（PDP）を通じて処理されます。国内においては、電子請求が導入されます。対象となるすべての企業は、2026年9月1日以降、電子請求を受け付けることができるようにする必要があります。電子インボイスの発行と電子報告：大企業および中小企業は2026年9月以降、中小企業およびマイクロ企業は2027年9月以降に適用されます。 |ドイツ|XRechnungまたはZUGFeRD 2.1+|XRechnungは、純粋なXML形式です。 ZUGFeRDは、CII XMLを埋め込んだPDF/A-3形式のハイブリッドファイルです。地域内での電子請求書の使用。2025年1月1日以降、利用が義務付けられます。 2027年1月1日より、年間売上高が80万ユーロを超える企業に適用され、2028年1月1日からはすべての企業に適用されます。 イタリア：FatturaPA 純粋なXML形式で、SdI（Sistema di Interscambio）のプラットフォームを通じて交換されます。 (地域情報) 電子インボイス。| ライブ配信。 2019年以降、国内B2B取引において必須。 |ポーランド|KSeF形式の請求書|KSeFプラットフォームを通じて提出される、全国共通のXMLスキーマ。 (地元の情報) 請求書は構造化されています。| ライブ配信中。 2026年2月1日より、最大の納税者およびすべての企業間取引（B2B）に対して適用（2026年4月1日より）。 |ベルギー|Peppol BIS Billing 3.0|純粋なXML形式で、直接送信するのではなく、Peppolネットワークを通じて交換されます。|2026年1月1日より運用開始。| |イギリス（UK）|Peppolベース|EU圏外であり、異なるスケジュールで導入されます。|まだ義務化されていません。| 2029年4月より、Peppol規格に基づく企業間取引（B2B）の導入が正式に決定されました

ハイブリッド形式の電子インボイスの取り扱いについて

純粋なXML形式とは異なり、ZUGFeRDとFactur-Xは、PDF/A-3形式のファイルであり、請求書の内容がXML形式で添付ファイルとして埋め込まれています。表示されるページは、人間が読みやすくするためのものであり、もし内容に相違がある場合は、埋め込まれたXMLファイルの内容が優先されます。

1つのファイルを受け取った場合： この場合、PDFファイルからデータを抽出しないでください。そうすると、データではなく、参考資料として提供されたコピーが取得されてしまいます。添付ファイルとXMLファイルからデータを分離してください。オープンソースのpoppler-utilsパッケージを使用すると、1つのコマンドでこれを行うことができます

pdfdetach -list invoice.pdf # show embedded files

pdfdetach -saveall invoice.pdf # extract all attachments

ファイル名からその形式がわかります。例えば、ZUGFeRD 1.0 の場合は "ZUGFeRD-invoice.xml"、ZUGFeRD 2.x および Factur-X の場合は "factur-x.xml"、そして XRechnung の参照プロファイルの場合は "xrechnung.xml" となります。Poppler-utils は、Windows、Linux、macOS で利用可能です。この手順は、FlowForce Server のジョブの最初の段階として自動的に実行され、マッピング処理はすぐに実行されます。

1つのファイルを送信する場合： MapForceはPDFファイルをデータソースとして読み込みますが、書き込みは行いません。そのため、MapForceはZUGFeRDまたはFactur-Xファイル内に含まれるXMLデータを生成しますが、ハイブリッドPDFファイルそのものを生成するわけではありません。コンテナ部分は、お客様が使用するPDF関連のツールによって構築されます。

ただし、いずれの場合でも注意点があります。ZUGFeRDとFactur-Xは、いくつかのプロファイルを定義しており、下位のプロファイルでは、埋め込まれたXMLにはヘッダー情報のみが含まれており、詳細な品目情報はPDFのレイヤーに残り、ソフトウェアでは読み取ることができません。マッピングでどのような情報を記述するかを決定する前に、顧客またはプラットフォームがどのプロファイルを必要としているかを確認してください。

電子インボイスの作成

システムから顧客への請求書発行には、4つの異なる工程が含まれます。これらの工程は、しばしば「電子請求書」という一つの概念として扱われがちです。その結果、チームはプロジェクトの途中で、自社のソフトウェアが実際に行っていることに対して、予期せぬ事態に遭遇することがあります いいえ 実行する。

データ抽出：請求書データを、現在保存されている場所（ERPシステムからのエクスポート、データベース、スプレッドシート、またはサプライヤーからのPDFなど）から取り出します
マッピングと変換：ターゲット形式で定義されている項目に合わせて構造を再構築し、その過程でコード、日付、および税金カテゴリを変換します
検証：送信を試みる前に、結果がスキーマに準拠していることを確認する
送信：Peppol経由、フランスのPDP（サービスプロバイダー）を通じて、またはSdIやKSeFのような国内プラットフォームに送信します

データの抽出、マッピング、変換は、データマッピングの作業であり、MapForceはこれらの作業を行うとともに、出力結果が対象となるスキーマに準拠しているかを確認します。これにより、ファイルが構造的に正しいことを、ファイルが処理を完了する前に確認できます。

その外に存在する要素は2つあります。まず、EN 16931は、XSDで表現できないビジネスルールを実行します。これらのルールは、Schematronバリデータによって検証されます。EUはこれらのルールセットを無料で公開しており、多くの配送プラットフォームも、受信時にこれらのルールを実行しています。配送自体は、Peppolアクセスポイントまたは承認されたプラットフォームプロバイダーに対するネットワーク接続と認証の問題です。

作業範囲を決定する前に、その境界線がどこにあるのかを把握することが、計画と予期せぬ事態の差を生む要因となります。

実例：PDFファイルをXML形式の電子インボイスに変換する

これは、経理部門にとってよくある問題です。請求システムがPDF形式でのみ請求書を発行する場合や、異なるソフトウェアを使用している子会社から請求書が送られてくる場合があり、今後はXRechnung形式での対応が必要になります。

マッピングについて詳しく見る前に、まず理解しておくべきことがあります。EN 16931は、セマンティックモデルであり、請求書に何を含めるべきかを定義するもので、XMLの見た目を規定するものではありません。このモデルを実装する構文として、UBLとCIIの2つがあり、準拠した電子請求書は、どちらかの構文に準拠することができます。したがって、「EN 16931ファイル」というファイル形式は存在しません。代わりに、EN 16931に準拠したXMLベースのUBL請求書やCII請求書が存在します。

XRechnungは、どちらの構文もサポートしているため、これは同じ要件を実現するための2つの有効な方法の1つです。UBLのスキーマはOASISが無料で公開しており、CII D16BのスキーマはUN/CEFACTが公開しています。これらのスキーマは、MapForceのXMLスキーママネージャーを使って、簡単にインストールできます。

以下に例を示しますが、これはXML形式のUBL電子インボイスを対象としています。

マップフォースのPDF抽出機能を使用して、以下のルールを定義しました PDFファイルからデータを抽出する請求書。これにより、テンプレートが作成され、これがソースコンポーネントとして、ターゲットとなるUBLスキーマにマッピングされます。MapForceはスキーマから構造を読み取るため、ターゲットのツリー表示は、一般的なXML構造ではなく、そのフォーマットが定義する正確な要素を表示します。私たちは、まず...から始めました Altova AI （オプションの追加機能として）PDFファイルとUBLインボイスのXMLスキーマ間の関連性を自動的に提案する機能がありますが、手動で関連付けすることも可能です。

すべての対象フィールドが直接的な対応関係にあるわけではありません。一部のフィールドは直接マッピングできますが、他のフィールドは計算や変換が必要であり、また、一部の値は元のデータに全く存在しない場合もあります。

MapForceには、これらの様々な状況に対応するための豊富なデータ処理機能が組み込まれています。具体的には、計算された値に対する算術演算や丸め処理、日付の書式変更や、住所の項目を番地、都市、郵便番号、国といった複数の項目に分割する文字列処理、そして、ソースデータに含まれていない値を参照するための定数や参照機能などが含まれています。

マッピングが有効なファイルを作成すると、その利点は、それが継続的にファイルを作成し続けることです。次月の輸出データに向けて設定すると、変換処理は変更なしに実行されます。 MapForce Serverでコンパイルし、FlowForce Serverでスケジュール設定することで、請求書はデータが到着するたびに自動的に変換されます。

電子インボイスの受領

この義務は双方向です。ドイツでは、企業は2025年1月以降、構造化された電子インボイスを受け取れるように求められており、フランスでも2026年9月以降、同様の義務が企業に課せられます。この流れは、一方通行です

受信：ファイルは、アクセスポイント、PDP、または国内プラットフォームを通じて受信されます
マップと変換：受信したXMLデータを、貴社のERPシステム、データベース、または会計システムが要求する形式に再構築します
インポート：実際に使用するシステムにデータを取り込みます

今回も、MapForceがその役割を担います。さらに、MapForce ServerとFlowForce Serverを使用することで、この作業フローを完全に自動化することができます。

e-インボイスにおけるMapForceの具体的な利点

一つのツールで、方向ごとに異なるものを使いません。 データが国標準の形式に変換される場合でも、データベースにインポートされる場合でも、あるいはある準拠形式から別の準拠形式に変換される場合でも、いずれも同じ種類のデータ変換処理です。
指示はスケジュールに基づいて届きます。 保存された設定は、次回の指定日に合わせて活用できる資産であり、繰り返して行うプロジェクトではありません。
正確性は、後から見つけるのではなく、最初から設計に組み込むものです。 データマッピングにおいて、フィールドやコードリストを正しく設定することが、ファイルが却下されるのを防ぐ鍵となります。そして、却下された請求書は、支払い遅延とそれに伴う手作業での調査を意味します。
この対応関係は確認可能です。 監査人が、ある税額がどのように算出されたのかを尋ねた場合、その答えは理解しやすい図として提示されます。

• これはお客様ご自身のインフラ環境上で動作します。 請求書には、ビジネスおよび個人情報が含まれています。MapForceは、お客様のコンピューター上でこれらの情報を処理し、MapForce ServerおよびFlowForce Serverは、お客様が管理するサーバー上で動作します。

ご自身の請求データで試してみてください

この方法がお客様のシステムに適合するかどうかを確認する最も簡単な方法は、実際の輸出データと、目標とするスキーマを一つずつ用意し、それらを対応付けることです。もし、単一の請求書に対して変換がうまくいった場合、バッチ処理でも問題なく機能するはずです。

あなたは～することができます無料で30日間の試用版をダウンロードできます MapForceの使い方について、まずはここから始めてみてください。