最高のZUGFeRD抽出ツールが
請求書の半分を見逃す理由
2026年の最高のZUGFeRD抽出ツールを検索すると、ほぼすべてのリストが同じテストから始まります。埋め込まれたXMLを解析できるかどうか。これは完全なXMLペイロードを備えたファイルにとっては正しい質問です。しかし、買掛金管理チームにとっては間違った最初の質問です。なぜなら、その答えは仕入先が実際に送信するものに依存するからです。ドイツでは2025年1月から企業に構造化された電子請求書の受領能力が義務付けられましたが、発行義務は2028年まで段階的に導入されており、移行期間中に受信トレイに届くものの多くは依然として通常のPDFです。本物のZUGFeRDファイルでも、XML添付が薄すぎて仕訳できない場合があります。XMLのみを読み取るツールは、請求書の半分が問いかけていない質問に対する優れた答えにすぎません。

重要なポイント
- 2026年のZUGFeRDツールランキングは、実は1つのスキルのランキングです。それは、PDF内に埋め込まれたXMLをどれだけうまく解析できるかです。
- ドイツの買掛金管理受信トレイにある請求書の半分はプレーンなPDFまたはスキャンであり、本物のZUGFeRDファイルでも明細行のないMINIMUMまたはBASIC WLプロファイルが含まれる場合があります。
- 適切な候補リストは、リストの最上位にあるパーサーではなく、仕入先の構成から始まります。
ZUGFeRDファイルの中身とは
ZUGFeRD(Zentraler User Guide des Forums elektronische Rechnung Deutschland)は、ドイツのハイブリッド電子請求書形式です。ISO 19005-3に基づくPDF/A-3文書という1つのファイルに、同じ請求書の2つのコピーが格納されています。人が読み、印刷するための表示ページと、埋め込みファイルを許可するアーカイブ規則に従ってPDF内に添付されたXML文書です。このXMLはUN/CEFACT Cross Industry Invoice(CII)構文に従い、ドイツでは法的に決定的な層となります。Factur-Xは同じ標準のフランスでの名称であり、ZUGFeRD 2.1以降、両者は技術的に同一で、ドイツとフランスで2つの名称で公開されている1つの仕様です。
XMLは複数のプロファイルのいずれかで作成され、プロファイルによって構造化レイヤーに請求書のどの程度が実際に含まれるかが決まります。これは、APテーブルを構築する人にとって何を意味するかを説明せずに、ほとんどのツール比較が列挙するだけの部分です。
| プロファイル | XML内の明細行 | EN 16931準拠 | §14 UStGに基づく有効な電子請求書 |
|---|---|---|---|
| MINIMUM | なし | なし | なし |
| BASIC WL(明細行なし) | なし | なし | なし |
| BASIC | あり | あり | あり |
| EN 16931(COMFORT) | あり | あり | あり |
| EXTENDED | あり | あり | あり |
| XRECHNUNG(参照プロファイル) | あり | あり(CIUSとして) | あり |

ドイツ連邦財務省はZUGFeRDをバージョン2.0.1以降で受け入れていますが、MINIMUMとBASIC WLは準拠した電子請求書として数えるには浅すぎるため除外しています。現在の仕様は、FeRDがフランスのFNFE-MPEと共同で維持しており、プロファイルがXML内で宣言された状態で公開され、バリデータと会計システムの両方で読み取られます。正確なプロファイル規則とファイル命名規則は、公式のZUGFeRD情報サイトに記載されています。
XML添付の有無ではなく、プロファイルが、ZUGFeRDファイルがAPテーブルに必要な明細行を保持しているかどうかを決定します。MINIMUMとBASIC WLにはまったく明細行が含まれていません。
XRechnungは、実用的な目的のほとんどにおいてZUGFeRDの隣に位置し、その内部にはありません。これは純粋なXML形式であり、CIIまたはUBL構文のいずれかで、人間が読めるPDFレイヤーはまったくなく、KoSITによって維持され、ドイツの公共部門の請求書に必須です。ZUGFeRDはまた、XRECHNUNG参照プロファイルを定義しており、ハイブリッドPDF内にXRechnung準拠のXMLをラップします。この違いは後で重要になります。なぜなら、どのツールがファイルを開けるかを決定するからです。
XMLネイティブツールとビジュアルツールは異なる課題を解決する
ほぼすべてのZUGFeRD比較は2つの技術ファミリーに集約される。重要なのは、どちらがより高度に聞こえるかではなく、それぞれが何を読み取るかを理解することだ。
XMLネイティブツールは、埋め込まれたCII XMLを特定して直接解析する。認識ステップがないため、フィールド値は決定的である。つまり、ツールはバリデータが読むのと同じバイトを読み取る。XMLペイロードがPDFに添付されている場合でも、スタンドアロンのXRechnungファイルとして配信される場合でも、そのXMLを処理する。このツールの盲点は、利用可能なXMLがない請求書、つまりプレーンなPDF、スキャン、写真、およびXMLに行項目がない低プロファイルのファイルである。
ビジュアルレイヤーツールは、人が見るようにレンダリングされたページを読み取り、OCRとビジョンモデルを使用して各値の意味を理解する。読み取り可能なページを持つあらゆるファイル(本物のZUGFeRD PDF、フラットなサプライヤーPDF、スキャン、スマホの写真)を処理できる。このツールの盲点は、読み取るページがまったくない生のXRechnung XMLであり、解析のようなバイトレベルの確実性を提供できないことだ。
| 受け取る入力 | XMLネイティブツール | ビジュアルレイヤーツール |
|---|---|---|
| ZUGFeRD PDF、EN 16931 (COMFORT) または EXTENDED | 埋め込まれたXMLを正確に読み取る | レンダリングされたページを読み取る |
| ZUGFeRD PDF、MINIMUM または BASIC WL | ヘッダーデータのみ読み取り、行項目はなし | ページに表示されているものを読み取る |
| プレーンなPDFまたはスキャンされた請求書 | 解析するものがない | ページを読み取る |
| 生のXRechnung XML(PDFなし) | XMLを直接読み取る | 読み取るページがない |

この2つのファミリーは互いにランク付けされるものではない。入力に合わせて選択されるものであり、実際の受信トレイのほとんどは、ある時点で両方のタイプのカバレッジを必要とする。
実際のAP受信トレイで「XMLを解析するだけ」が機能しない理由

XMLファーストの考え方にギャップが生じる理由は、具体的に3つの現実によって説明され、そのそれぞれが今日のドイツおよびEUの買掛金業務に現れています。
移行期間はまだ終わっていません。 2025年1月1日以降、ドイツのすべての企業はEN 16931電子請求書を受領できなければならず、欧州委員会のドイツ電子請求書ページには段階的な開始が定められています:売上高が800,000ユーロ超のサプライヤーは2027年1月1日から、それ以外のすべてのサプライヤーは2028年1月1日から電子請求書の発行が義務付けられます。それまでの間、および移行規則に基づく中小企業については、サプライヤーは受領者の同意を得て、紙またはプレーンなPDF請求書を引き続き送付できます。「電子請求書が今や義務化された」という理由で2026年にPDF処理を撤去したチームは、切り替えていないすべてのサプライヤーを置き去りにすることになります。XRechnungとZUGFeRDの区分を含む完全な法的スケジュールは、ドイツの電子請求書義務化に関するガイドで説明しています。
すべてのXMLが解析する価値があるわけではありません。 上記のプロファイル表は些細なことではありません。MINIMUMとBASIC WLは義務から明確に除外されており、それらを送信するサプライヤーは要件を満たしていないことになりますが、それでもそれらのファイルは届き、完全なものであるかのようにAPに転送されることがよくあります。出力テーブルに明細行の数量、単価、税コードが必要な場合、BASIC WLファイルを忠実に読み取るパーサーはヘッダー合計を返して停止します。XMLは存在します。必要なデータは存在しません。EN 16931より前のもので異なるルート要素を使用するレガシーなZUGFeRD 1.0ファイルも、アーカイブされた請求書に対して同じ問題を引き起こします。
XMLとPDFは矛盾することがあります。 これはツールリストが完全に省略している点であり、公式のZUGFeRDガイダンスが直接指摘している点です。ハイブリッドファイルは2つの表現を保持するため、不正または誤った請求書では、ページに表示される数値とXML内の数値が異なる場合があります。ZUGFeRDのFAQは、PDFのみを確認してXMLバージョンを支払うことに対して警告し、逸脱を自動的に検出するにはOCRと請求書認識が必要であり、その結果はおそらく完璧ではないと述べています。実際にはこれは両刃の剣です:XMLが存在する場合でも視覚レイヤーは読む価値があり、視覚的またはXMLのいずれの方法も完璧を主張することはできません。
この問題の実際の姿は、それほど技術的には聞こえません。ドイツの電子請求書を非ドイツ製ERPで処理することに関するr/Accountingのスレッドで、ある実務者は状況を率直に説明しています:「ほとんどのドイツのサプライヤーは、電子請求書の誇大広告にもかかわらず、依然として通常のPDFを送ってきます。そして当社のERP(SAPではない)は基本的にXRechnungを外国語のように扱うため、はい、まだ大量の手入力が発生しています。試したOCRツールは、良い日でおそらく70%の精度でした」(r/Accounting)。PDFを送るサプライヤー、XMLを解釈しないERP、フィールドを見逃すツールが、すべて同じ文に登場します。
結果を左右する問いは「XMLを解析するかどうか」ではありません。「サプライヤーが送るあらゆる種類のファイルから、出力に必要な列を生成できるかどうか」です。
2026年に最適なZUGFeRD抽出ツール、アプローチ別に分類
2026年のZUGFeRD抽出ツールに単一の勝者はいません。ツールはそれぞれ異なる入力に最適化されているためです。単一のランキングリストよりも、アプローチ別に分類する方が有用です。以下の項目は、真剣なショートリストに頻繁に登場する名前と、ビジュアルレイヤーオプションをカバーしています。より広いカテゴリで基準を定義中の場合は、請求書データ抽出ソフトウェアの比較がより広範囲にわたります。
| ツール | アプローチ | 最適な用途 | 注意点 |
|---|---|---|---|
| FormX | XMLネイティブREST API、無料の単一ドキュメントツール | 完全なXMLを含むファイルを持ち、API経由でJSONを求める開発者 | ホスト型のみ。データ所在地に関する規制に適合するか確認が必要 |
| InvoiceXML | 抽出、作成、検証、変換のためのXMLネイティブAPI | 電子請求書の生成や検証も必要なチーム | 開発者向け。APレビュー用インターフェースではない |
| Rossum | エンタープライズ向けドキュメントAI、ワークフロールール付きML抽出 | ZUGFeRDが多数ある形式のうちの1つである混合ポートフォリオ | ZUGFeRD入力がXML経由かビジュアルレイヤー経由かを確認 |
| Klippa (Doxis) | レビューUIとAPIを備えたEUのドキュメント処理プラットフォーム | 自動化とともに人間によるレビューを求める中堅EUチーム | ベンダー主導のオンボーディングと価格設定 |
| ABBYY | エンタープライズIDP、XML向けに設定可能 | すでにABBYYを標準化している組織 | ZUGFeRDのみのスコープに対する設定と実装のオーバーヘッド |
| Docsumo | 財務ドキュメント向けドキュメントAI、OCRファースト | 銀行明細書、請求書、発注書を1つのプラットフォームで扱う場合 | ZUGFeRD XMLが直接読み取られるか、再認識されないかを確認 |
| Mustang | CII XML用のオープンソースJavaライブラリ | Javaチーム、ライセンス費用ゼロ、セルフホスティングとデータ所在地 | サービスを自社で構築・運用する必要あり。型付きオブジェクト、UIなし |
| ImageToTable.ai | PDFまたはスキャンのビジュアルレイヤー抽出、XML解析なし | プレーンなPDF、スキャン、およびExcelやSheetsに出力する低プロファイルのZUGFeRDファイルが混在する受信トレイ | 生のXRechnung XMLファイルは読み取れません。XMLが情報源の場合はXMLネイティブツールを使用してください |
この表を読む際の注意点をいくつか。 「最適な用途」は、ツールが構築された入力プロファイルを説明するものであり、全体的な品質ランキングではありません。ツールの機能は変更されるため、導入前に最新のドキュメントを確認してください。また、正しい答えは多くの場合、1つではなく2つのツールです。完全な構造化データを含むファイル用のXMLネイティブパーサーと、そもそも利用可能なXMLがなかったプレーンなPDF、スキャン、不完全なファイル用のビジュアルレイヤーツールです。この2番目のカテゴリは、ドイツの移行期間中にツールリストが示すよりも大きくなっています。
実際に取引先が送ってくる形式に基づく選び方
実際に機能する判断基準は、機能比較表ではなく、件数から始まります。直近の取引先からの請求書100件を確認し、4つの山に分類してください。EN 16931またはEXTENDEDプロファイルに対応した本物のZUGFeRDまたはFactur-X PDF、生のXRechnung XML、通常のPDF、スキャンまたは写真です。それぞれの山の大きさが、選択の答えの大部分を示しています。
ほぼすべてに完全なXMLが含まれている場合
XMLネイティブのパーサーまたはAPIを選択してください。確定的なフィールドが得られ、EN 16931ルールに照らして検証でき、生のXMLはアーカイブ用にそのまま保持できます。これは、ドイツの記録保存規則が原本として保持することを求めているものです。ビジュアルツールはここではあまり役に立ちません。
無視できない割合がプレーンなPDFまたはスキャンの場合
ビジュアルレイヤーツール、または2つのツールの組み合わせが必要です。これは2026年によくあるケースです。取引先が、電子請求書を早期に導入した企業と、移行期間中にまだいる企業に分かれている場合です。ビジュアルツールは、本物のZUGFeRDページとフラットなPDFの両方を同じパイプラインで読み取ります。
生のXRechnung XMLを読み取る必要がある場合
XMLネイティブツールのみが選択肢です。純粋なXMLファイルには、ビジュアルツールが読み取るページがありません。ドイツの公共部門のバイヤーから請求書を受け取るチームは、これを好みではなく必須要件として扱う必要があります。
データの格納先を決める
DATEV、Lexware、SAPは埋め込まれたXMLを直接インポートするため、そのパスがすでに機能している場合、残りのギャップはPDFです。格納先がスプレッドシートまたはインポートテンプレートの場合、ExcelまたはCSVを出力し、オプションでGoogle Sheetsに書き込むビジュアルツールが、再入力の手間を最も削減します。
ツールをボリュームと明細の深さに合わせる
1日に数件の請求書を超える場合、または個々の請求書が複数ページにわたる数百行の明細になる場合、バッチ処理が重要になります。ドキュメント単位のAPI呼び出しモデルとバッチアップロードモデルは、デモでは同等に見えますが、月末のボリュームでは大きく異なります。
形式とは無関係のもう1つの考慮事項があります。国境を越えた電子請求書は拡大する一方です。EUのVAT in the Digital Ageパッケージでは、EU域内のB2B取引に対する構造化電子請求書とデジタルレポートが2030年7月1日から義務化され、欧州委員会はすでに加盟国に対し、特別な免除なしで国内の電子請求書を義務付けることを認めています。XMLの割合は今後も増加し続けるでしょう。長く使えるツールは、構造化されたパスをカバーしつつ、依然としてドキュメントとして届くファイルも見捨てないものです。
ZUGFeRDに対するPDFレイヤー抽出でできることとできないこと
ここが当ツールの境界線であり、明確に述べる価値があります。ImageToTable.aiは請求書の視覚レイヤーを読み取ります。埋め込まれたXMLは解析しません。この単一の事実が、何が得意で何ができないかを決定づけます。
その仕組みはカスタム列抽出です。「仕入先」「請求書番号」「請求日」「正味金額」「消費税額」「明細行の説明」などの列名を入力すると、AIがページ上の位置ではなく意味を理解して各値を特定します。描くべきテンプレートも、学習用のサンプルも不要で、入力した列名が出力テーブルのヘッダーになります。これにより、フラットなサプライヤーPDFと本物のZUGFeRD PDFが同じリクエストで処理されるのです。どちらにも読み取るページがあるからです。
AP業務では、さらに3つの機能がZUGFeRDの現実に沿っています。バッチ処理は、複数のファイルを一度にアップロードし、一貫した列を持つ単一のExcelテーブルに統合します。ZUGFeRD PDFとスキャンが混在するフォルダーでも、サプライヤーごとのファイルではなく1つのデータセットが生成されます。マルチページマージは、同じ論理ドキュメントに属する結果をグループ化するため、複数ページにわたる長い請求書や、ページごとに撮影されたドキュメントも、散らばらずに1行または連続した行のセットにまとまります。bbox検証付きレビューモードでは、抽出されたセルにホバーまたはクリックすると、元のページのどこから値が来たかを正確に確認できます。これは、1桁の誤読が誤った支払いにつながる財務業務で重要です。入力にはPDF(パスワード保護されたファイルを含む)に加え、JPG、PNG、WebP、AVIF、スクリーンショットが対応し、出力はExcel、CSV、JSON、Wordのいずれかです。
速度について、このツールは印刷された請求書ページを5〜10秒で処理します。手動入力の平均約3分に対してであり、印刷された表データでは最大99%の認識精度に達します。密集した手書き文字や低品質のスキャンは、より高い処理ティア(Standard、Advanced、Premiumとして提供)で処理するのが適しています。
限界も同様に具体的です。埋め込まれたCII XMLの読み取り、出力、検証は行わないため、構造化された原本を保持または検証する必要があるチームにとって、XMLネイティブパーサーの代わりにはなりません。読み取るページがないため、生のXRechnung XMLファイルは処理できません。EN 16931ルールに対するファイルのチェックも行わず、DATEV、Lexware、SAPへの転記も行いません。このツールが行うのは、利用可能な構造化データを持たないドキュメントを、残りのプロセスが消費するスプレッドシートの行に変換することです。この仕組みは、ファイルがZUGFeRDであるかどうかに関係なく、通常のドイツの請求書(Rechnung)抽出にも適用されます。
視覚抽出は、受け取るすべての請求書に存在するレイヤーをカバーします。XML解析は、時々しか完全でないレイヤーをカバーします。どちらも他方を置き換えるものではなく、どのファイルがどちらかを知ることが、ツールのリストが省略しているスキルです。
よくある質問
2026年で最適なZUGFeRD抽出ツールは何ですか?
仕入先が送信するファイルの種類によって異なります。受信ファイルに完全なEN 16931またはEXTENDED XMLが確実に含まれている場合は、APIベースの抽出サービスなどのXMLネイティブパーサーを使用すると、決定的なフィールドを取得できます。一方、プレーンなPDF、スキャン、または簡易的なZUGFeRDファイルが一定数含まれる場合は、レンダリングされたページを読み取るビジュアルレイヤーツールが必要です。多くのチームは、最終的に両方を使用することになります。
ZUGFeRD抽出ツールはXMLレイヤーとPDFレイヤーのどちらを読み取るべきですか?
どちらのアプローチも有効であり、それぞれ異なる状況に対応します。XMLを読み取る方法は正確で、標準に照らして検証できますが、XMLが存在し完全である場合にのみ機能します。PDFまたはスキャンを読み取る方法は、読み取り可能なページを持つすべてのファイルで機能し、ドイツの移行期間中に多くの受信トレイで依然として主流であるプレーンな請求書にも対応できます。誤りは、単一のアプローチが仕入先全体をカバーできると想定することです。
ImageToTable.aiはZUGFeRD PDFからデータを抽出できますか?
はい、表示可能なPDFページから抽出できます。ZUGFeRDはハイブリッドファイルであるため、常に人間が読み取れるレイヤーがあり、ImageToTable.aiは定義した列を使用してそのレイヤーを読み取ります。埋め込まれたXMLの解析や出力は行わないため、明細項目やヘッダーフィールドをスプレッドシートに取得するためのツールとしては適していますが、構造化された原本の検証やアーカイブには適していません。
ImageToTable.aiはXRechnung請求書で動作しますか?
XRechnungが読み取り可能なページを持つPDFまたはスキャンとして届く場合にのみ動作します。生のXRechnungファイルは視覚レイヤーのない純粋なXMLであり、ImageToTable.aiはXMLを入力として受け付けません。裸のXRechnungファイルには、XMLネイティブパーサーが必要です。
多数のZUGFeRD請求書を一度にバッチ処理できますか?
はい。ImageToTable.aiはバッチファースト処理を前提に構築されています。複数のファイルをアップロードすると、同じ列を持つ1つのExcelテーブルにマージされます。これは、本物のZUGFeRD PDF、フラットな仕入先PDF、スキャンが混在するフォルダーでも機能します。抽出は各ファイルの形式ではなく、設定した列名によって駆動されるためです。
無料のZUGFeRD抽出ツールはありますか?
無料の選択肢は存在し、最初の確認には利用価値がある。オープンソースのMustangライブラリは、ライセンス費用なしでZUGFeRDおよびFactur-XのXMLを実際に解析できるが、その周囲にサービスを構築して実行する必要がある。いくつかの商用ベンダーは、テスト用の無料の単一ドキュメントオンラインツールまたはトライアルを提供しているが、通常はバッチやAPIアクセスは含まれない。大量の作業には、有料プランまたはセルフホストの対応が必要になる。
ZUGFeRDとFactur-Xの違いは何ですか?
これらは、2つの名称を持つ同じ技術標準である。ZUGFeRDはドイツでの呼称で、Factur-Xはフランスでの呼称であり、ZUGFeRD 2.1以降は共同で維持され、同一のPDF/A-3コンテナ、同一のCII XML、同じプロファイルを持つ。一方を処理できるツールは他方も処理できるはずである。ファイルがfactur-x.xml添付ファイルと、古いzugferd-invoice.xmlという名前のどちらで扱われるかについて、具体的に確認することをお勧めする。
「最高のZUGFeRD抽出ツール」のリストは、実際には「どのツールが埋め込まれたXMLを解析するか」という1つの狭い質問への回答のリストに過ぎない。その質問は検討に値し、完全に構造化されたサプライヤーデータセットには、XMLネイティブの回答が正しい選択である。しかし、ドイツの義務化はまだ段階的に導入されており、プレーンなPDFも当分は法的に有効であり、下位のZUGFeRDプロファイルには、APテーブルに必要な明細項目を含まないXMLが含まれている。どの請求書に完全な構造化データが実際に含まれているかを把握しているチームは、最も評価の高いパーサーを選ぶチームよりも優れたツールを選択できる。