Read an incoming e-invoice and pass it on
XML or a ZUGFeRD PDF turns into fields your bookkeeping can take over.
The inbox holds a mixture: XRechnung as XML, ZUGFeRD as PDF, and still PDFs with no structure at all. The parse endpoint takes the file Base64-encoded, detects the format and returns the invoice data as structure — number, parties, line items, tax amounts. What happens next is your system's decision: a sheet, an ERP or an approval flow.
What comes in
XRechnung as UBL or CII XML
A ZUGFeRD or Factur-X PDF with embedded XML
The filename, so the format is detected reliably
The email attachment from the inbox, unchanged
What this solves
The format is detected, not guessed
You do not have to know in advance whether an XRechnung or a ZUGFeRD PDF arrives. The endpoint takes both and answers with the same structure.
With ZUGFeRD the embedded XML is what counts
The truth is in the attachment, not on the visible page. Reading the PDF with OCR risks taking a number from a layout column instead of from the document.
Invoice data arrives as fields
invoiceNumber, seller, buyer, items, taxSummary, total: named fields instead of text fragments. Handing them to a sheet, an ERP or bookkeeping is a mapping afterwards, not text recognition.
No processing by a language model
The extraction is a mapping of the document, not a guessing game: invoice data is not sent to a language model. What the parser reports is in the document.
One real example
An excerpt from the XRechnung the recipe “Read an incoming e-invoice” sends to the parser.
<cbc:ID>RE-2025-001</cbc:ID><cbc:IssueDate>2025-01-15</cbc:IssueDate><cbc:Name>Muster GmbH</cbc:Name><cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount><cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount><cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>POST /api/v1/invoice/parse
Response: the invoice data as JSON — invoiceNumber RE-2025-001, seller Muster GmbH, 1,000.00 € net plus 190.00 € tax, 1,190.00 € payable. The same values that appear in the document above.
The full recipeCompared to the alternative
The alternative is running a library yourself — Mustang, for instance. That works, but it costs upkeep on every format version and a Java process next to your application.
Read the comparisonHow it runs
- 1
Take the attachment from the inbox and Base64-encode it.
- 2
POST /api/v1/invoice/parse with data and filename.
- 3
Write the fields from the response into a sheet, an ERP or an approval flow.
What it costs at this volume
Around 1,000 invoices per month fit the Starter plan at 23 € per month.
All prices net, plus VAT · 20 % off when billed annually · Free tier without a credit card
All plansLimits
- A PDF without embedded XML holds no structured data — the parser cannot invent any.
- The response says what is in the document, not whether it matches your order. The business comparison stays your step.
- Audit-proof archiving is not part of the API (Archive API planned 2027); the n8n template shows the workflow route to storage.
Frequently asked questions
Which formats can the parser read?
XRechnung as UBL and CII, plus ZUGFeRD and Factur-X PDFs with embedded XML. The formats API reports the current state.
What happens to the file?
It is processed to produce the response and is not passed to a language model. The security page describes the processing in detail.
How do I get from the response into a spreadsheet?
The n8n template “parse-email-to-sheets” walks exactly that route: watch the inbox, send the attachment to the parser, write a row into the sheet.