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, so one file is readable by a person and by a machine. 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.
A PDF on its own is not an e-invoice
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.
What the hybrid actually is
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.
Only two formats do this
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 compliant document. The x-pdf-kind response header says which of the two you received, so an integration never has to infer it.
What goes wrong
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. This is why Beliq runs a PDF/A validator over the assembled document before returning it, rather than trusting the assembly step.
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.
Reading one back
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.