A PDF is commonly used to present an invoice for people to read. An XML invoice expresses data through a defined structure that software can process. The distinction concerns the actual content and implemented format, not simply which extension appears after the file name.
The format-selection workflow begins with the recipient’s needs. A customer may need a readable copy, a specific structured document or a hybrid containing both. Confirm the actual requirement before assuming that one file type can substitute for another.
What a readable document provides
A readable invoice lets someone inspect the seller, customer, supplies and amounts in an arranged page. It can help with approval, dispute resolution and human review. A clean layout makes those tasks easier, but it does not assign every value a formal machine-addressable meaning.
Software can sometimes extract information from a PDF, including through text interpretation or optical character recognition. That extraction is a separate process. It should not be confused with receiving values already mapped into a defined structured invoice model.
The current creator offers printable output through the browser. A browser may provide Save as PDF, depending on its environment. This is not a direct formal PDF export and does not embed structured invoice XML or establish a hybrid format.
What structured XML provides
XML supplies a framework for representing elements, attributes and their relationships. An invoice format gives those structures specific meaning and rules. A receiving application can then locate a seller identifier or line amount according to the implemented specification instead of inferring it from a page layout.
Not every XML file is an e-invoice, and not every invoice-shaped XML file implements the recipient’s format. The correct syntax version, binding, profile, codes and business rules still matter. An XML element named total does not establish which amount it represents or whether it reconciles correctly.
The European Commission’s guidance distinguishes semantic invoice meaning from the syntax carrying it. That is why choosing XML is only the beginning of an implementation decision. The receiving system needs the expected representation and rules, not arbitrary labelled data.
Recognise hybrid documents
Some formats combine a readable PDF with structured invoice data under specified packaging requirements. Factur-X is an example. Its existence means it would be inaccurate to say that every PDF lacks machine-readable invoice data.
The useful question is whether this particular file contains the required payload, uses the appropriate profile and satisfies its rules. A PDF with an unrelated attached text file is not automatically a valid hybrid invoice. The readable and structured information also need appropriate consistency checks.
The guide to Factur-X and ordinary PDFs explains that specific distinction. The current creator’s browser print output does not implement Factur-X or ZUGFeRD. Renaming or adding a badge to the printed file does not change that capability.
Compare what the customer can use
Ask whether the recipient wants a human review copy, an automated processing document or both. Record the actual format, profile and version where structured processing is required. A phrase such as “PDF is fine” may need clarification if another team operates the receiving platform.
If a recipient requests XML, obtain the named syntax and profile rather than sending any file with the right extension. UBL and CII are different structures, and a particular workflow may restrict versions or fields. A valid document for one destination is not automatically accepted elsewhere.
Keep delivery separate too. A document format does not specify that the creator has submitted it through a network or portal. The current application downloads supported outputs locally and has no government or Peppol transmission integration.
Review the right evidence
For a readable output, inspect the actual preview and print result. Check complete descriptions, amounts, payment text and pagination. Do not assume a good editor view guarantees identical printed wrapping in every browser configuration.
For a structured output produced elsewhere, inspect its mapped values and required validation report. A successful XML parse or schema check has a narrower scope than full business-rule and recipient-profile validation. Keep the tested file and configuration identifiable.
A representative fictional test should include the actual kinds of references, adjustments and tax information the workflow needs. A simple screenshot cannot establish that the underlying export contains those values, and a simple file extension cannot establish conformity.
Before delivery, choose software that genuinely implements the required output. The current creator can provide a readable preparation document and its own JSON or line-item CSV. It does not produce recognised standards XML or guarantee legal validity or acceptance. Preserve the distinction so the recipient receives the format they requested rather than a visually similar substitute.
A practical comparison can use one fictional invoice in a browser PDF and a separately mapped structured test file. Check the buyer reference in each. The visible PDF may show it clearly while the structured file omits it or assigns it to a payment field. This illustrates why readability and processing compatibility need their own evidence, even when both documents display the same total.