Can an e-invoice live inside a PDF?

Yes, in exactly one way. A hybrid PDF/A-3 carries the structured XML as an embedded attachment. A PDF on its own is not an e-invoice.

Yes, and this is the most useful thing about the format family, so it is worth being precise about what it means. A hybrid e-invoice is a PDF/A-3 document with the structured invoice embedded inside it as an XML attachment. One file, two readers: a person opens the PDF, software reads the XML.

Emailing a PDF invoice is not e-invoicing under any European mandate, however neatly the PDF is laid out. The mandates are about structured data: a machine has to be able to read the invoice without character recognition or guesswork. A PDF is a description of how to draw a page. Nothing in it says which number is the VAT amount.

Nor does attaching an XML file to an email alongside a PDF solve it. Two files travel separately, get separated, and disagree. The hybrid exists precisely to stop that: the structured data is inside the readable document, so it cannot arrive without it.

ZUGFeRD and Factur-X, which are the same format under two national labels, define it. The container is PDF/A-3, an archival PDF profile whose defining feature here is that it permits arbitrary embedded files. Inside it goes the invoice as UN/CEFACT CII XML, under a fixed attachment name, factur-x.xml, so a receiving system knows what to look for without inspecting every attachment.

The visual page and the embedded XML are meant to be the same invoice. The XML is the part that carries legal and compliance weight; the rendering is what a human reads.

Hybrid PDF output is specific to ZUGFeRD and Factur-X. Peppol BIS Billing 3.0, XRechnung and the national XML formats are structured XML documents with no PDF envelope, because their receiving channels expect XML.

That is not the same as saying they get no PDF. Beliq can return a visualization PDF for those standards too: a human-readable rendering built from the same data, with no XML embedded in it. It is a presentation artifact, useful for a customer copy or an archive, and it is not the e-invoice: the XML is. The x-pdf-kind response header says which of the two you received, so an integration never has to infer it.

Three failure modes are worth knowing, because they are invisible until a receiver rejects the file.

The PDF is not valid PDF/A-3b. The XML can be perfect and the envelope still wrong: a missing font embedding, transparency, an unsupported colour space. A receiving system validating the container refuses the file, and nothing in the invoice content explains why. Beliq runs veraPDF on every hybrid it builds, the ones POST /v1/generate returns and the ones POST /v1/convert re-wraps around converted XML, and returns the file only when veraPDF reports no violation of its PDF/A-3b profile. A test-mode PDF is watermarked after the check and does not pass that profile. By default POST /v1/generate also validates the XML before it assembles the hybrid; with verify: false it does not, and the veraPDF check still runs. A hybrid PDF from anywhere else is not checked as a PDF: POST /v1/validate judges its embedded XML only, and POST /v1/convert hands one back as you sent it when its XML already is the target. A PDF/A check still belongs in your pipeline for those.

The attachment is there under the wrong name, or not embedded at the PDF/A-3 relationship level. The receiver looks for the standard attachment and finds a PDF with a file stapled to it.

The rendering and the XML disagree. Generating them from one source of data is the only real defence. Producing a PDF in one system and XML in another, then combining them, guarantees a divergence eventually.

The hybrid is also a convenient thing to receive. POST /v1/parse takes a ZUGFeRD or Factur-X PDF and returns the embedded invoice as canonical fields, so an inbound hybrid does not need special handling on your side. POST /v1/validate accepts the PDF directly too, and validates the invoice inside it.