E-Invoice Parser · XRechnung, ZUGFeRD, Factur-X, UBL avatar

E-Invoice Parser · XRechnung, ZUGFeRD, Factur-X, UBL

Pricing

$50.00 / 1,000 invoice parseds

Go to Apify Store
E-Invoice Parser · XRechnung, ZUGFeRD, Factur-X, UBL

E-Invoice Parser · XRechnung, ZUGFeRD, Factur-X, UBL

Parse EU e-invoices (XRechnung, ZUGFeRD/Factur-X PDFs, EN 16931 UBL & CII, Peppol BIS) into clean JSON — parties, line items, totals, VAT, IBAN — plus EN 16931 validation findings. Deterministic: no OCR, no LLM, no guessed numbers. Only successfully parsed invoices are charged.

Pricing

$50.00 / 1,000 invoice parseds

Rating

0.0

(0)

Developer

Chris S

Chris S

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 hours ago

Last modified

Share

E-Invoice Parser — XRechnung, ZUGFeRD, Factur-X & UBL to clean JSON

Turn EU e-invoices into clean, structured JSON: seller and buyer (with VAT IDs and addresses), invoice number and dates, line items, VAT breakdown, totals, IBAN and payment terms. Feed it XML (XRechnung, EN 16931 UBL or CII, Peppol BIS) or hybrid PDFs (ZUGFeRD / Factur-X — the embedded XML is extracted automatically), get back data your accounting pipeline, RPA flow, or AI agent can use directly.

E-invoicing is now mandatory across Europe — Germany (receiving since 2025, issuing 2027/28), France (from Sept 2026), Belgium (since Jan 2026), Italy, Poland, and more. Every business and every automation pipeline suddenly receives XML invoices that generic PDF tools and LLMs handle badly: this parser is deterministic — no hallucinated amounts, no OCR guessing. It reads the structured data the law requires to be there.

What you get per invoice

{
"fileName": "invoice-4711.pdf",
"fileType": "pdf",
"parsed": true,
"format": "ZUGFeRD/Factur-X (EN16931)",
"invoice": {
"number": "471102",
"issueDate": "2024-11-15",
"typeLabel": "Invoice",
"currency": "EUR",
"seller": { "name": "Lieferant GmbH", "vatId": "DE123456789", "city": "Berlin", "country": "DE" },
"buyer": { "name": "Kunde AG" },
"payment": { "iban": "DE02120300000000202051", "terms": "30 days net", "dueDate": "2024-12-15" },
"lineCount": 4,
"lines": [{ "name": "Widget A", "quantity": 10, "unitPrice": 12.5, "netAmount": 125.0, "vatRate": 19 }],
"vatBreakdown": [{ "category": "S", "rate": 19, "taxableAmount": 124.08, "taxAmount": 23.57 }],
"totals": { "netTotal": 124.08, "vatTotal": 23.57, "grossTotal": 147.65, "payable": 147.65 }
},
"findings": [],
"errorCount": 0,
"warningCount": 0
}

Files that are not e-invoices (e.g. a plain PDF without embedded XML) are reported with a clear explanation — and not charged.

Supported formats

FormatDetection
XRechnung (UBL & CII, all versions)via CustomizationID, version reported
ZUGFeRD 1.0 / 2.x & Factur-X (hybrid PDF)embedded XML extracted from PDF/A-3, profile reported (MINIMUM…EXTENDED)
EN 16931 UBL / CII XMLcore European norm invoices
Peppol BIS Billing 3.0UBL profile
Credit notes, correctionstype codes reported (380, 381, 384, …)

Validation included

Beyond parsing, each invoice is checked against EN 16931 calculation rules and German XRechnung business rules (BR-CO / BR-DE): total consistency, VAT-breakdown arithmetic, required fields like Leitweg-ID (buyer reference), IBAN presence for credit-transfer invoices, and more. Findings come with rule IDs and severity so you can gate your workflow on errorCount === 0. (Rule explanations are currently written in German — rule IDs are the international EN 16931 codes.)

E-invoicing mandates: why pipelines need this now

CountryMandate
Germanyreceiving mandatory since Jan 2025, issuing 2027/28 (XRechnung, ZUGFeRD)
Francefrom Sept 2026 (Factur-X)
Belgiumsince Jan 2026 (Peppol BIS)
Italy, Poland, …national mandates live or scheduled

Every accounts-payable inbox in the EU is filling up with structured XML invoices. Generic PDF tools show them as gibberish and LLMs guess at them — this parser converts XRechnung to JSON, Factur-X to JSON and UBL to JSON deterministically, with the norm's own validation rules applied.

How to use it

  1. Pass direct URLs to your invoice files (fileUrls) — presigned S3/GCS/Azure links or Apify key-value-store URLs work.
  2. Run the Actor; each file becomes one dataset item.
  3. Read the dataset from the API, Make, Zapier, Google Sheets — or let an AI agent call this Actor as an MCP tool ("parse this invoice and give me the IBAN and total").

Typical pipelines: e-invoice inbox automation (mail attachment → parse → ERP), accounts-payable pre-checks before import, bulk migration of received XML invoices into a bookkeeping system, agent-driven invoice triage.

Example input

{
"fileUrls": [
"https://your-bucket.s3.amazonaws.com/invoices/2026-07/invoice-4711.pdf?X-Amz-Signature=...",
"https://example.com/invoices/rechnung-0815.xml"
]
}

One field is all there is: a list of file URLs, XML or PDF, mixed freely. Each file becomes one dataset item; files that turn out not to be e-invoices are reported and not charged.

Use with AI agents (MCP)

This Actor is available as a tool through the Apify MCP server, so agents in Claude, ChatGPT or any MCP client can parse invoices mid-workflow. Prompts that map onto this Actor:

  • "Parse this invoice and give me the IBAN, due date and total."
  • "Check whether these five XRechnung files pass validation and list every error with its rule ID."
  • "Extract all line items from this ZUGFeRD PDF into a table."

Because parsing is deterministic, the agent's answer is only ever as wrong as the invoice itself — every number in the output exists verbatim in the file.

FAQ

Why not just ask an LLM to read the invoice? LLMs hallucinate amounts and merge line items — a single silently wrong booking is disqualifying in accounting. This parser reads the machine-readable XML the EU norm mandates; every number in the output exists verbatim in the file.

Is my invoice data safe? Files are processed in memory inside your own Actor run and results go only to your own dataset. Nothing is sent to third parties — there is no LLM, no OCR cloud service, no analytics.

What about plain PDF invoices without embedded XML? They are detected and reported as "not an e-invoice" (free of charge). OCR of unstructured PDFs is a different, error-prone problem this Actor deliberately avoids.

Which countries' invoices work? Any invoice following EN 16931 (the EU norm) — German XRechnung and ZUGFeRD, French Factur-X, Peppol BIS used across the EU/EEA, and national CIUS variants that keep the core structure.

Pricing

$0.05 per successfully parsed invoice. Unparseable files cost nothing — you only pay for invoices that came back as structured JSON.

  • E-Invoice Validation API — validate EN 16931 / XRechnung / ZUGFeRD / Peppol BIS invoices via a single REST call, without running an Actor. Same validation engine as this parser.
  • rechnungssicht.de — free browser tool that renders e-invoices readable locally (German; nothing leaves your machine).

More from this publisher