E-Invoice Attachment Extraction API
E-invoices carry more than invoice data. Delivery notes, timesheets, and the original order often travel base64-encoded inside the XML itself, invisible to anyone reading the file. One REST call decodes every embedded supporting document (BG-24) and hands you the original files as a ZIP.
Upload an XRechnung, UBL, or CII XML invoice, or a Factur-X / ZUGFeRD hybrid PDF. The API locates each additional supporting document with an embedded payload (BT-125), decodes it byte-for-byte, and streams the originals back with safe, de-duplicated filenames. No parsing, no rendering, no data left behind in the XML.
curl -X POST https://api.invoicexml.com/v1/extract/attachments \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]" \ -o invoice-attachments.zip
// invoice-attachments-2026-001.zip ├── delivery-note-4711.pdf ├── timesheet-june.xlsx ├── purchase-order-0815.pdf └── site-photo.jpg // each file decoded from BT-125, byte-for-byte
This is not the XML extractor
Hybrid invoices embed in two directions, and the two are easy to confuse. A Factur-X or ZUGFeRD PDF carries the invoice XML inside the PDF; pulling that out is the job of POST /v1/extract/xml. This endpoint goes the other way: it reads the documents inside the invoice XML, the delivery notes, timesheets, and orders that EN 16931 lets a sender base64-encode into the additional supporting document group (BG-24). Upload a hybrid PDF here and the API even chains the two steps for you: it unwraps the invoice XML first, then decodes the attachments declared inside it.
Extract the attachments from your e-invoice now
This demo calls the same POST /v1/extract/attachments endpoint your integration will use. Drop an e-invoice XML or a hybrid PDF and the ZIP with every embedded supporting document downloads immediately.
Drop an e-invoice to test the API
or browse files to upload
REST API demo · POST /v1/extract/attachments · XML or PDF · Max 20 MB
Your file is processed in memory and deleted immediately. Nothing is stored, and attachment content is never opened or parsed.
The documents hiding inside invoice XML
EN 16931 gives senders exactly one standard place to ship supporting documents with an invoice: the BG-24 group, one entry per document, the file itself base64-encoded in BT-125. In B2G channels that only transport a single XML file, everything important rides there.
Proof of delivery and receipt
Delivery notes, acceptance protocols, and signed receipts that justify the invoice amount. Public-sector buyers in particular require them, and suppliers embed them because the submission portal accepts only the invoice file itself.
Timesheets and activity records
Service invoices commonly attach the hourly breakdown as a spreadsheet or PDF. Without BG-24 extraction, the AP clerk approving the invoice never sees the evidence behind the line items.
Orders and contracts
The original purchase order or the framework contract the invoice bills against, embedded so the receiving side can three-way match without hunting through a second system.
What is deliberately excluded
BG-24 entries that only reference an external URL (BT-124) are not downloaded: the file is not part of the invoice, and fetching arbitrary third-party URLs server-side would be a security liability. Your application can follow those links directly.
From buried base64 to a clean ZIP
Locate every BG-24 group
The invoice XML is parsed (for hybrid PDFs, after unwrapping the embedded invoice) and every additional supporting document with a base64 payload is collected, regardless of UBL or CII syntax.
Decode, never interpret
Each BT-125 payload is base64-decoded and written into the archive byte-for-byte. The server never opens, sniffs, or renders the attachment content; a payload that is not valid base64 fails loudly with errorCode 4014.
Ship a safe archive
Declared filenames are sanitised (no directories, no path traversal, no hidden files), duplicates get numeric suffixes, and unnamed payloads become attachment-N with an extension from the declared mime code. One predictable ZIP, ready for your DMS.
Where attachment extraction earns its keep
AP approval workflows
Route the delivery note and timesheet to the approver alongside the invoice instead of asking them to trust the line items. One extraction call at intake puts the evidence next to the amounts.
Complete archiving
An archive that stores only the invoice XML silently keeps the attachments locked in base64. Extracting them at ingest makes every supporting document indexable, searchable, and auditable on its own.
XRechnung intake pipelines
ZRE, OZG-RE, and Peppol deliver exactly one XML file, so German suppliers embed everything else inside it. A receiving pipeline without BG-24 extraction is quietly discarding documents the sender was required to provide.
One request, every attachment
Send the e-invoice as multipart/form-data. The response body is a ZIP archive with one entry per embedded supporting document.
$ curl -X POST https://api.invoicexml.com/v1/extract/attachments \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]" \ -o invoice-attachments.zip
An invoice without embedded attachments returns a clean 404 (errorCode 4013), so the empty case is a simple branch, never an empty archive. Need the invoice data itself? Pair this with /v1/extract/json on the same upload.
Complete XRechnung Toolkit
Everything you need to create, convert, validate, and preview XRechnung invoices, via REST API or online.
Frequently Asked Questions
Where exactly do these attachments live?
Inside the invoice XML itself. EN 16931 defines the additional supporting document group (BG-24), and its attached document element (BT-125) can carry a whole file, a delivery note, a timesheet, the original order, base64-encoded directly in the XML. This endpoint decodes those payloads. It is not about the factur-x.xml inside a hybrid PDF; for that, use POST /v1/extract/xml.
Which invoice formats can I upload?
A standalone XML e-invoice (UBL 2.1, CII D16B, or XRechnung in either syntax) or a hybrid Factur-X / ZUGFeRD PDF. For a PDF, the API first pulls out the embedded invoice XML and then reads that XML's BG-24 groups. A PDF without embedded invoice XML is rejected with errorCode 4006.
Why do XRechnung invoices so often carry embedded attachments?
Because the German B2G transmission channels (ZRE, OZG-RE, Peppol) deliver exactly one file: the invoice XML. A supplier who must provide a proof of delivery or an hourly breakdown has no side channel, so the document is base64-embedded in BG-24. Receiving systems that ignore BG-24 silently lose those documents; this endpoint is the recovery path.
What about attachments referenced by URL instead of embedded?
BG-24 also allows an external reference (BT-124), a URI pointing at a document hosted elsewhere. Those are deliberately not downloaded: the file is not part of the invoice, and fetching third-party URLs server-side would be a security and privacy liability. The API extracts embedded payloads only; your application can follow BT-124 links itself.
How are the extracted files named?
Each ZIP entry uses the filename the sender declared (BT-125-2), sanitised to a flat, safe name with no directories or path tricks. Duplicates get a numeric suffix, and a payload without a declared filename becomes attachment-N with an extension derived from its declared mime code. The ZIP itself is named after your upload plus the invoice number, e.g. invoice-attachments-2026-001.zip.
What if the invoice has no attachments?
You get a clean 404 with errorCode 4013 (NoAttachments) rather than an empty ZIP, which makes the no-attachments case trivial to branch on in an automated pipeline. A corrupt base64 payload returns a 400 with errorCode 4014 naming the offending document reference.
Ready to automate your invoices?
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.