Choose an e-invoice format from the receiving customer’s actual requirements, then check that your software implements the required document and delivery process. A familiar file extension or a polished preview is not enough. Confirm the format, profile, version, required fields and route before preparing a final export.
You can prepare supported invoice data locally with the creator, but its current outputs are printable output, application-owned JSON and line-item CSV. Browser printing may offer Save as PDF. The app does not generate standards XML, a hybrid PDF with embedded invoice data or a formally validated recipient profile.
Begin with the recipient’s instruction
Ask the customer which organisation and system will receive the invoice. A purchasing contact may want a readable copy while an accounts platform needs a particular structured document. These can be related requirements without being the same file or action.
Obtain the actual instruction rather than relying on a phrase such as “send an electronic invoice”. Record the named format and profile, accepted version, destination, required identifiers and any validation expectations. If the instruction is incomplete, ask the responsible receiving team to clarify it.
Keep the source and confirmation date. Requirements can change, and a sample from another customer may not describe this receiver’s configuration. A successful previous delivery is useful evidence of that earlier event, not a guarantee for every later invoice.
Separate readable output from structured data
A PDF commonly presents a document for people to read. Structured invoice data gives defined roles to values so receiving software can process them. Neither property should be inferred solely from the file name. A PDF may contain a hybrid payload, while an XML file may contain arbitrary unrelated structure.
The PDF and XML comparison explains those purposes. Use a readable preview to check names, scope and visible amounts, but do not treat visual similarity as proof that a machine-readable representation exists or follows the required model.
The current creator’s print output has no embedded structured invoice XML. Saving it through a browser as a PDF does not turn it into Factur-X or ZUGFeRD. Its JSON is structured application data, not an implementation of a recognised invoice format merely because fields have labels.
Identify the standard, syntax and profile
Some instructions name a semantic model, while others name an XML syntax, a national specification or a business-process profile. These layers answer different questions. A request naming one layer may still need clarification about the others.
The EN 16931, UBL and CII comparison explains how meanings and message structures fit together. A mapper needs to implement the applicable binding, not simply create XML elements whose names resemble invoice fields. The recipient’s required profile can add constraints to the broader model.
Record the specification edition and syntax version together. Do not assume the newest published syntax is accepted by a profile bound to another version. Edition migration also needs checking with the actual recipient rather than being inferred from a general standards announcement.
Check hybrid document requirements
Factur-X and ZUGFeRD involve a readable PDF and structured invoice data under specified packaging and profile requirements. An ordinary PDF plus an unrelated XML attachment is not automatically the same implementation. The two representations also need the appropriate consistency review.
Use the Factur-X versus ordinary PDF explanation when a receiver requests a hybrid file. Confirm the required profile and version, then use software that genuinely creates and checks that output. A badge or renamed file cannot supply the absent payload or packaging rules.
Do not assume every profile carries identical data coverage or satisfies every destination. The useful question is whether the particular output implements what this recipient requires. Preserve missing data requirements before choosing a conversion or export tool.
Separate the document from its route
A receiving system may accept a document through a portal, an agreed file transfer or a network process. Producing the right document does not perform that transmission. Conversely, using a recognised delivery route does not make arbitrary contents valid.
The Peppol document and delivery comparison keeps those responsibilities distinct. Confirm the recipient identifier, service capability and required provider arrangement where relevant. The current creator has no Peppol connection, government submission or automatic email-sending integration.
Assign who performs delivery and what evidence confirms submission or acceptance. A file appearing in the browser’s downloads proves an export occurred locally. It does not prove that the customer received it, processed it or accepted the underlying transaction.
Check your actual export capability
Read the software’s implemented output matrix and inspect a representative file. Establish the exact format, profile and version it produces, which fields it supports and which validation it performs. Do not infer the answer from an XML or PDF option alone.
The creator’s existing formats page describes current boundaries. If it cannot produce the required output, retain the supported source data and use an appropriate final system. Do not tell the customer that application JSON is a standards document or that a printed PDF meets a hybrid requirement.
Treat any conversion as a mapping project with input assumptions, unsupported-field handling and validation. A converter cannot recover a buyer endpoint, exemption code or service period that was never collected. A visually correct source can still lack information the target requires.
Test with a representative example
Use fictional data to test the intended workflow before preparing a long real invoice. Include the kinds of lines, references, tax categories and payment instructions your transaction needs. An example containing only one simple line may not expose missing conditional fields.
Inspect the actual exported structure and the validation report appropriate to the destination. Compare the readable representation with the same source facts. Keep the tested file and configuration together so a later report can be traced to the exact version reviewed.
Do not upload customer invoices to an unfamiliar online validator without an appropriate decision about data handling. Browser-local preparation and external validation are separate processes with separate privacy implications. Use trusted software and fictional test files where practical.
Complete the selection before delivery
Use the format-selection checklist to record the recipient instruction, chosen implementation, remaining data gaps, validation owner and delivery owner. Resolve unsupported requirements before representing the document as ready. A format choice is useful only when the workflow can actually produce and send the required output.
After final edits, generate a fresh version and repeat the relevant checks. Existing downloaded files and earlier validation reports do not update themselves. Keep the intended final output distinguishable from working drafts and previous attempts.
The goal is a supported, reviewable decision based on what the recipient needs. The creator can help prepare fields and review calculations within its current model; formal format support, profile validation and transmission need genuine implementation and evidence. No selection by itself guarantees legal validity, tax-authority approval or customer acceptance.
For a fictional first-customer test, create a decision sheet with five headings: receiver instruction, source facts, implemented output, validation evidence and delivery evidence. Put an owner and current status beside each. The instruction might require a specific structured profile while the current creator supplies only application preparation data. Record that gap before any real invoice is shared. This prevents a locally successful export from being mistaken for completion of the customer’s end-to-end requirement.
Review the sheet again when a provider or requirement changes. A software update, new recipient identifier or revised profile can affect only part of the workflow. Keeping the stages separate lets you repeat the relevant checks without treating the entire earlier decision as either permanently valid or entirely useless.