Choose the final invoice output only after confirming what the recipient needs and what your software actually implements. Record the format, profile, version, required data, validation and delivery route. A familiar extension or polished preview is not enough to establish compatibility.
Use this checklist after the format-selection workflow. The creator currently offers printable output, application JSON and line-item CSV. Recognised standards exports, formal validation and network submission are not implemented merely because the guides explain those concepts.
Confirm the actual receiver
Identify the billing entity and receiving system, not only the person placing the order. A purchasing contact may want a readable copy while a finance platform needs a particular processing document. Preserve both requirements if they are genuinely distinct.
Obtain the current instruction from the responsible receiver or its published documentation. Keep the source and confirmation date. Do not assume a sample from another customer or an earlier delivery describes the present requirement.
Resolve vague requests such as XML, electronic invoice or standard PDF before promising an output. Ask which specification and workflow those words refer to. The useful answer should identify an implemented target rather than a file icon.
Record format and profile precisely
Distinguish the semantic model, syntax, profile and version. A broad UBL claim is not evidence of every national or business-process profile. A hybrid PDF requirement is not met by an ordinary browser-generated PDF.
Check whether the receiver requires specific production releases or validation configurations. Do not record only “latest”. A draft publication or newer general syntax does not prove that the destination has migrated to it.
Use the version-confirmation check to retain a reproducible decision. Keep the tested combination identifiable so later changes can be assessed without guessing what the original provider meant by format support.
Compare implemented software capabilities
Read the actual output scope and inspect a representative fictional file. Ask which scenarios, fields and rules are supported. A screenshot or format badge is weaker evidence than an implemented exporter and its test results.
If the current creator cannot produce the required output, preserve useful source data and finalise elsewhere. Do not rename JSON as XML, add a hybrid label to printed output or imply that a country selector creates a verified profile.
If an adapter is proposed, establish its source contract, target mapping and unsupported-case behaviour. A converter cannot recover facts that were never collected or responsibly invent an identifier to pass a mandatory-field rule.
Check source completeness
Review seller and buyer identities, document facts, references, line scope, quantities, prices, treatment decisions and payment instructions. Confirm which facts have typed fields in the final target and which require collecting outside the current editor.
Keep source evidence and unresolved questions separate. A correct-looking total does not establish the right buyer endpoint, exemption reason or commercial quantity. Technical structure and factual accuracy need different review.
For a fictional test, give the buyer reference and payment reference different values and include a nontrivial quantity. Check whether the final system preserves their roles and calculation basis. A simple one-line sample may not exercise the requirements that matter to your transaction.
Assign validation and delivery
Identify the appropriate schema, business-rule and profile checks and who performs them. Retain the report with the exact file and configuration. A successful XML parse is not the same as complete formal validation.
Assign who submits the file and monitors its status. A local download is not portal submission, Peppol delivery or customer acceptance. Keep those events and their evidence separate rather than using one generic success message.
If a readable copy accompanies structured data, compare both against the same confirmed source facts. Do not give the receiver conflicting amounts or references and expect it to decide which representation should control.
Finalise and retain the decision
You can prepare supported invoice fields locally before completing a separate formal workflow. The creator remains useful for entry, live totals, field checks and current exports within its scope. It does not guarantee tax correctness, legal validity or acceptance.
After edits, generate fresh output and repeat the affected checks. Earlier files and validation reports do not update automatically. Keep the intended delivered version distinguishable from working drafts and superseded attempts.
A completed selection record should identify the receiver, exact requirement, implemented producer, data gaps, validation owner and delivery owner. If one of those remains unresolved, keep it as a concrete action before delivery. This makes format selection a reviewable product workflow rather than a reassuring label attached to a file whose actual compatibility has never been checked.
For a final release decision, ask a colleague to explain the selected workflow using only the requirement record and test evidence. They should be able to identify the accepted output, known limits and remaining operational actions without a private explanation from the original preparer. If they cannot, clarify the record before relying on it for a real customer invoice. This checks whether the selection is reproducible rather than merely familiar to its author.
Use the confirmed recipient record.