Converting a PDF invoice into ZUGFeRD or Factur-X takes two steps: read the invoice data, then embed it as CII XML inside a PDF/A-3 container. InvoiceExtractor handles the first step at scale. Upload any vendor PDF, scan, or photo and get every header field and every line item back as structured JSON, CSV, or Excel, ready to hand to your Factur-X generator, your approved platform, or your ERP.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
France and Germany both set hard dates for structured B2B e-invoicing, and both accept the hybrid PDF formats. The gap is that almost every invoice a business already holds, and most of what still arrives from suppliers, is a plain PDF with no data inside it.
In France, every VAT-registered business must be able to receive e-invoices from 1 September 2026, with large and mid-sized companies also issuing from that date and smaller companies following on 1 September 2027. In Germany, businesses above 800,000 euros of turnover must issue from 1 January 2027 and everyone else from 1 January 2028.
A PDF is a picture of an invoice. Even a born-digital one carries no reliable machine-readable fields, so it cannot satisfy EN 16931 on its own. The structured data has to exist before any generator can build a compliant file.
The German Ministry of Finance guidance of 15 October 2024 accepts ZUGFeRD from version 2.0.1, but explicitly excludes the MINIMUM and BASIC WL profiles because they omit required fields. BASIC WL in particular carries no line items, so a profile choice made to save effort can fail the mandate.
Header capture is easy and most tools stop there. The EN 16931 profile expects the full line-item table: description, quantity, unit, unit price, line total, and the tax rate per line. Rebuilding that table by hand for a backlog of invoices is where the real cost sits.
We are deliberately clear about scope. InvoiceExtractor is the extraction layer, not a generator and not an approved platform. It turns unstructured PDFs into the clean, complete dataset that every downstream ZUGFeRD or Factur-X step depends on.
Seller and buyer details, VAT identifiers, invoice number, issue date, due date, currency, net and gross totals, tax breakdown by rate, and payment terms, pulled from any layout without templates.
The full table, not just the totals: description, quantity, unit of measure, unit price, line amount, and the tax rate on each row, which is exactly what the EN 16931 and EXTENDED profiles expect.
Export clean JSON and map it straight into Mustangproject, the factur-x Python library, iText, or whatever your platform uses to write the CII XML. No screen scraping and no regex over PDF text.
Point the API at an archive of thousands of legacy PDFs and get consistent structured output for each one, so a migration project runs as a batch job rather than a data-entry program.
Supplier invoices arrive as scans, phone photos, and faxes. AI extraction reads them the same way it reads a born-digital PDF, so the awkward end of the archive is not left behind.
Every extraction is shown as an editable table next to the source document, so a person can correct an odd VAT rate or a merged column before the data is embedded in a file you are legally responsible for.
Four steps take a folder of ordinary PDFs to the point where a generator can produce a compliant hybrid invoice.
Drop a single PDF or a whole batch into the converter at the top of this page, or send them through the API. Scans, photos, and multi-invoice PDFs are all accepted.
Tip: Start with twenty invoices from your five noisiest suppliers. Those layouts tell you more about the real accuracy you will get than a hundred clean ones.
The AI returns header fields and the full line-item table beside the original document. Scan the tax breakdown and the line totals, and fix anything the source document itself rendered ambiguously.
Tip: Confirm the net, tax, and gross figures add up per rate. A tax breakdown that does not foot is the single most common reason a generated file fails validation later.
Download structured JSON for a generator library, or CSV and Excel if the data is going into an ERP that will issue the e-invoice for you.
Tip: JSON keeps the line items nested under their invoice, which saves you rebuilding the parent-child relationship that a flat CSV loses.
Map the fields into your ZUGFeRD or Factur-X generator, which embeds the CII XML in a PDF/A-3 container, then run the result through a validator before anything goes to a customer or an approved platform.
Tip: Target the EN 16931 profile or higher. It is the level Germany accepts and it carries the line-item detail that MINIMUM and BASIC WL leave out.
The deadline pressure lands hardest on finance teams with a large PDF archive and on the developers asked to build the pipeline.
You have a generator library picked out and no reliable source of structured data to feed it.
A US parent with a French or German subsidiary inherits the mandate through that entity.
Clients arrive with archives of PDFs and a date on the calendar they cannot move.
Customers begin asking for a hybrid file instead of the PDF you have always emailed them.
Technically, yes. Since ZUGFeRD 2.0 the French and German specifications have been the same standard published under two names, and from version 2.1 they are identical. Both embed UN/CEFACT Cross Industry Invoice XML inside a PDF/A-3 container, both use the same profiles, and a file built to one specification is readable by tools built for the other. The names reflect national governance, not different technology.
That matters commercially, because it means one extraction and mapping project can serve both the French and the German obligation. You are not building two pipelines.
A ZUGFeRD or Factur-X invoice is one file that two different readers can use. A person opens it and sees a normal invoice page. A machine opens the same file, ignores the page, and reads the XML attachment. Nothing is duplicated in the sense of being sent twice, but the same facts do have to be present and consistent in both layers.
| Layer | What it is | Who reads it |
|---|---|---|
| Visual layer | A PDF/A-3 page, the archival PDF profile defined in ISO 19005-3, which permits arbitrary file attachments | People: AP clerks, approvers, auditors |
| Data layer | An embedded CII XML file carrying the invoice fields as structured data | Software: ERPs, AP systems, tax platforms |
| Metadata | XMP metadata declaring which specification and profile the file conforms to | Validators and receiving platforms |
The reason this format won adoption in France and Germany rather than pure XML is precisely that first row. Businesses did not want to give up a document a human can read, and small suppliers were never going to build XML pipelines on schedule.
Both specifications define the same ladder of profiles, from a bare minimum up to a fully extended set of fields. The choice is not cosmetic: it decides whether the file satisfies the mandate.
| Profile | Carries line items | Accepted for the German B2B mandate |
|---|---|---|
| MINIMUM | No | No, explicitly excluded |
| BASIC WL | No, header and totals only | No, explicitly excluded |
| BASIC | Yes, a simplified set | Yes |
| EN 16931 (COMFORT) | Yes, the full standard set | Yes, and the sensible default |
| EXTENDED | Yes, plus additional fields | Yes |
| XRECHNUNG | Yes | Yes, the German public-sector implementation |
The German Ministry of Finance guidance issued on 15 October 2024 confirms ZUGFeRD from version 2.0.1 meets the requirements, with MINIMUM and BASIC WL excluded. Practically, that pushes almost everyone to the EN 16931 profile, which is the profile that needs a real line-item table. If your extraction step only returns vendor, date, and total, you cannot reach it.
| France | Germany | |
|---|---|---|
| Must be able to receive | 1 September 2026, all VAT-registered businesses | 1 January 2025, receivers cannot refuse an e-invoice |
| Must issue, larger businesses | 1 September 2026, large and mid-sized companies | 1 January 2027, turnover above 800,000 euros |
| Must issue, smaller businesses | 1 September 2027, SMEs and micro-enterprises | 1 January 2028 |
| Accepted formats | Factur-X, UBL 2.1, CII, aligned to EN 16931 | XRechnung, ZUGFeRD 2.0.1 and above excluding MINIMUM and BASIC WL, and other EN 16931 syntaxes including Factur-X and Peppol BIS Billing 3.0 |
| Routing | Through certified Approved Platforms, renamed from PDP to Plateforme Agreee in July 2025, connected to the public portal | No central platform mandated for the B2B exchange itself |
Germany is the quieter obligation that already applies. Since January 2025 a German business cannot refuse a compliant e-invoice from a supplier, which means the receiving side of your process needs to work now, well before the 2027 issuing date.
Teams tend to discover this split about a week into the project. Generating a ZUGFeRD file is the easy half. There are mature open-source libraries for it, and the packaging step is deterministic: take a set of fields, write CII XML, attach it to a PDF/A-3, set the XMP metadata. Mustangproject on the Java side and the factur-x library on the Python side both do this well, and commercial PDF toolkits such as iText and PDFlib support it too.
The hard half is having correct fields to give the generator. That is a document-understanding problem across hundreds of supplier layouts, and it is the part that does not have a tidy library. This is where we sit: AI invoice data extraction reads any layout without per-vendor templates and returns the header fields and the complete line-item table as clean data. Developers usually take the structured JSON output and map it into the generator, and teams building it as a service call the invoice data extraction API directly.
Being blunt about the boundary: InvoiceExtractor does not write the PDF/A-3 file for you and is not a certified approved platform in France. If a vendor tells you one product does extraction, generation, transmission, and certification, ask which of those is actually certified, because those are four different things with four different failure modes.
Most coverage of this topic is about issuing. Receiving is the side that hits sooner and is easier to underestimate. From September 2026 in France and already today in Germany, some of your inbound invoices arrive as hybrid files while the rest stay ordinary PDFs, and both land in the same mailbox for months or years.
That mixed reality is awkward for an AP process built on one assumption. A hybrid file has perfect data inside it and should be read from the XML, never re-keyed and never put through OCR. A plain PDF has no data and needs extraction. The workable pattern is a single intake that checks for an embedded XML attachment first, uses it when it exists, and falls back to automated invoice data capture when it does not. Both paths then feed the same fields into your ledger, so downstream matching and approval do not care which route an invoice took.
It applies through your customers and your entities, not through US law. There is no federal e-invoicing mandate in the United States, and the DBNAlliance exchange framework is voluntary. But a US company with a French or German subsidiary is inside those rules through that entity, and a US exporter selling to European business customers will be asked for compliant invoices by customers who now have their own obligation.
The practical trigger is usually a customer email rather than a regulator. Someone in a French accounts payable department writes to say that from September they need a Factur-X file instead of the PDF you have emailed for years. At that point the work is the same as it is for any European business, and it starts with getting your invoice data into structured form. For the wider picture of how these networks fit together, see our overview of e-invoicing and how it compares with the EDI 810 invoice that dominates in the US.
Converting a PDF to ZUGFeRD takes two steps. First extract the invoice data from the PDF: seller, buyer, invoice number, dates, tax breakdown, totals, and every line item. Then pass those fields to a ZUGFeRD generator, which writes them as CII XML and embeds that XML in a PDF/A-3 container. The extraction step is the one that needs AI, because supplier layouts vary endlessly. The packaging step is handled by libraries such as Mustangproject or the factur-x Python library.
Yes, technically they are the same standard under two national names. Since ZUGFeRD 2.0 the specifications have been aligned, and from version 2.1 they are identical. Both embed UN/CEFACT Cross Industry Invoice XML in a PDF/A-3 file and share the same profiles, so a single pipeline serves both the French and the German requirement.
ZUGFeRD is a hybrid format: one PDF file that a person can read with structured XML embedded inside it. XRechnung is pure XML with no visual document at all, and it is the German implementation of EN 16931 used for public-sector invoicing. Both are accepted under the German B2B mandate. Choose ZUGFeRD when recipients still want to see a readable invoice, and XRechnung when the receiving system is fully automated.
Not for transactions in scope. A plain PDF is not an electronic invoice under EN 16931 because it carries no structured data, and emailing one will not satisfy the French or German requirement once your issuing date arrives. The hybrid formats exist precisely so you can keep sending something that looks like the PDF your customers know while the compliant data travels inside it.
Use the EN 16931 profile, sometimes called COMFORT, unless you have a specific reason to go higher. German guidance accepts ZUGFeRD 2.0.1 and above but explicitly excludes the MINIMUM and BASIC WL profiles, and BASIC WL carries no line items at all. EN 16931 is the level that holds the full line-item detail, which is why your extraction step has to return the whole table and not just the totals.
Yes. The visual layer must conform to PDF/A-3, the archival PDF standard defined in ISO 19005-3, because that is the version of PDF/A that allows arbitrary file attachments such as the invoice XML. All three conformance levels, PDF/A-3a, PDF/A-3b, and PDF/A-3u, are permitted. A validator will reject a hybrid invoice built on an ordinary PDF container.
There is no US federal e-invoicing mandate, so domestic US invoicing is unaffected and the DBNAlliance framework is voluntary. You are pulled in through a French or German subsidiary, or through European business customers who now have their own obligation and start asking for a compliant file instead of an emailed PDF. In practice the request usually arrives from a customer before it arrives from a regulator.
Peppol, EDI, and the PDF invoices that arrive anyway.
Extract invoice data programmatically at scale.
Turn any PDF invoice into structured JSON.
Capture full line-item tables, not just the totals.
AI extraction that reads any vendor layout.
Import invoice data into any accounting system cleanly.
Start turning your invoices into clean, structured spreadsheet data.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale invoice extraction across your whole team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise‑grade invoice extraction, security, and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
