The difference in one sentence
A PDF presents an invoice to a person; a structured invoice identifies the business fields so software can validate and process them. The formats can coexist, but a PDF attachment alone does not prove that the recipient received structured data. The real test is what the buyer's system can consume without reconstructing fields from the page.
What each representation is good at
People often need a readable view for review, approval or dispute resolution. Systems need consistent field meaning, values and references for automated checks and posting. A PDF can contain text or even an embedded data file, but you must verify which part is authoritative and whether the recipient accepts that combination.
| Question | PDF or image document | Structured invoice data |
|---|---|---|
| What does the recipient see? | A page designed for visual reading. | Named business fields; a readable rendering may be generated. |
| How are values captured? | Manual entry or extraction may be needed. | Fields can be mapped directly into software. |
| How are errors checked? | Visual review or extraction checks. | Syntax, semantic and business rules can be applied to fields. |
| Is emailing enough? | It can deliver the file if the recipient accepts it. | The accepted format and exchange route still need agreement. |
Why searchable text is not the same as structure
A text-based PDF may let a user copy the invoice number, but it does not necessarily tell a receiving system which number is the invoice ID, which is a purchase-order reference, or how tax totals relate to individual lines. OCR tries to infer those relationships from an image. It can be useful for legacy intake, but confidence scores and human exception review remain relevant.
Can a structured invoice include a readable view?
Yes. A system can render the structured fields for human review. Some document arrangements pair machine-readable data with a visual representation. The implementation should say which data is authoritative, how the two remain consistent and what the recipient's specification accepts. Do not assume that any particular hybrid file satisfies a jurisdiction's rules.
A practical buyer-side example
Suppose a buyer receives 500 invoices a week. With emailed PDFs, its team may extract invoice numbers, supplier identifiers, tax amounts and order references before matching them. With a compatible structured feed, those fields can arrive in named positions and be checked against purchasing records. Exceptions still need owners: a missing order reference or disputed quantity will not disappear because the file is structured.
Which format should you send?
Ask the recipient for the exact format or profile, transport method, address or participant ID, validation rules and treatment of attachments. Then confirm any applicable legal requirements for the transaction. Start with the invoice data and validation guide if your source system cannot supply the required fields. The e-invoicing overview explains the broader workflow.
Related guides
- What is electronic invoicing? — How a structured e-invoice differs from a digital document and what happens between sender and recipient.
- Invoice data fields and validation — A practical field map and validation framework for structured invoice implementation.
- How an invoice moves between systems — Track the hand-offs, acknowledgements and failure states in a structured invoice exchange.
Primary sources and further reading
These official resources support the standards and regulatory context. Check their current versions before implementation.
- European Commission: What is eInvoicing? ↗ — Definition of a structured eInvoice
- European Commission: Compliance with the eInvoicing standard ↗ — Semantic model and UBL/CII syntax bindings