A hybrid invoice is one file that is two documents: a PDF that a person can read, with a complete structured invoice embedded inside it as an attachment. Open it in any reader and you see an invoice. Open it with software and you get the data.
It is the most pragmatic idea in European e-invoicing and it deserves both the credit and the scrutiny.
The problem it solves
Every business changing to structured invoicing hits the same wall on the receiving side. Their customers' processes assume a human looks at an invoice. Approval routing, coding, queries, filing, the conversation with the site manager who wants to see what was delivered — all of it assumes a page.
A pure XML invoice takes the page away. That is the correct long-term answer, and on the day the mandate starts it is an answer that requires every one of your customers to have finished their own project. They have not.
The hybrid file lets you comply without waiting for them. Customers who can consume the structured data do. Customers who cannot open the PDF and carry on as before, and neither party is blocked by the other. As a transition instrument it is close to ideal, which is why it took hold fastest in the market with the largest population of small suppliers, and why it features so heavily in the German mandate.
How it is built
The container is a PDF variant designed for long-term archiving, which permits file attachments and requires the document to be self-contained — no external fonts, no external colour profiles, nothing that would stop it rendering identically in twenty years. The structured invoice is attached to it with a defined name, and metadata inside the PDF declares that the attachment is present and which profile it follows.
Two consequences that matter.
The archiving properties are a feature, not incidental. The container format was chosen because it is designed to be readable for decades, which aligns with the retention obligations discussed in archiving a structured invoice.
The profile is declared inside. A receiver reads the metadata, finds the attachment, and validates it against the declared profile — the same specification identifier mechanism used everywhere else.
The dangerous failure mode
The structured data is the invoice. The PDF is a rendering. If they disagree, the invoice says what the structured data says, and your customer is looking at something else.
This is not hypothetical. It happens in four recurring ways:
| Cause | What the reader sees | What the data says |
|---|---|---|
| Two generation paths | The PDF from the print program | The XML from an export routine, run at a different moment |
| Rounding differences | A total rounded for display | An unrounded total, or one rounded differently |
| Late edits | A regenerated PDF | The original attachment, unchanged |
| Selective content | Notes, terms and annexes on the page | A core invoice that never carried them |
The last row is the subtle one. A supplier who puts payment conditions in the PDF's footer and not in the structured data has issued an invoice with no payment conditions. The customer's automated process, reading the data, will apply its default.
Extract the attachment, render the PDF, and compare the totals, the dates, the currency and the payment terms mechanically. Do it in the build, on every release. It takes an afternoon to write and it is the only thing standing between you and a document that contradicts itself.
Where hybrid files fit, and where they do not
They fit direct exchange: email, a supplier portal, a customer who has asked for a PDF and a mandate that requires structure. They fit a transition period, and they fit a supplier base that is not ready.
They fit less well on a four-corner network, where the profile expects the structured document and the rendering adds weight without adding function. See Peppol BIS Billing 3.0.
They do not fit a clearance model, where the platform wants the data and has no use for your page layout.
They are expensive to store. A hybrid file is many times the size of the equivalent XML, and you are keeping it for years. At low volume this is irrelevant. At a million invoices a year over a decade it is a line in a budget, and it is worth calculating before it becomes one.
Practical guidance
Generate both layers from one source, in one operation. Not two programs, not two schedules. This single decision removes most of the divergence risk.
Do not treat the PDF as the place for anything that matters. If a piece of information affects payment, treatment or entitlement, it goes in the structured data. The page is a courtesy.
Decide what an attachment is for. The structured invoice can itself carry attachments — a timesheet, a delivery note. That is a different mechanism from the hybrid container, and conflating the two produces files that nest confusingly.
Plan the exit. Hybrid is a transition. As your customers become able to consume structured data, the rendering stops earning its weight. Know what your trigger is for switching a given customer to pure XML, and make it a routine operational change rather than a project. That belongs with supplier onboarding at scale, which is the same exercise in the other direction.
One thing it does not change
A hybrid file is still a structured invoice for the purposes of validation. The attachment goes through the same gates as any other instance: schema, European rules, profile rules, receiver rules. The PDF wrapper buys goodwill from your customers. It buys nothing from a validator.
