If the creator cannot export the format your customer requires, keep the useful preparation work and move finalisation to software that genuinely supports the requirement. Do not rename the file, add a standards badge or tell the customer that a visually similar output is equivalent.

The format-selection workflow confirms the receiver’s requirement first. The current creator offers printable output, application JSON and line-item CSV. It does not export verified UBL, CII, XRechnung, ZUGFeRD, Factur-X or Peppol billing documents.

Write down the exact gap

Identify the required format, profile, version and delivery route. Then compare them with the implemented output matrix. “Needs XML” is too vague to guide the next step if the receiver expects a particular syntax and business-rule set.

Record whether the gap is an export adapter, a missing data field, a calculation model or transmission capability. These need different solutions. A converter might address representation while still lacking a required endpoint or unsupported financial adjustment.

Do not describe a planned feature as available. A future roadmap can identify the intended direction, but the current invoice needs a real implemented workflow. Keep the unsupported requirement visible until it has actually been completed and checked.

Preserve confirmed source data

Retain seller and buyer details, identifiers, document facts, lines and relevant tax and payment evidence. Keep unsupported typed facts separately in a preparation record rather than squeezing them into unrelated fields.

The creator’s application JSON can preserve supported data for its own editing workflow. Its import recalculates totals and accepts recognised fields; it is not a universal transfer contract for every final system. Confirm how another provider reads and maps it.

If manual re-entry is needed, use a source-to-target checklist. Check each role as well as its value. A correctly copied string in the wrong reference field remains a mapping error even when the document looks complete.

Choose final software by actual implementation

Ask the provider which exact format and profile releases it supports, which transaction scenarios it handles and what validation it performs. A generic XML option or screenshot does not establish the complete requirement.

Use the conversion review process if an adapter is proposed. Establish how it handles missing fields, unsupported adjustments, code lists and calculation differences. It should report gaps rather than silently drop information or invent defaults.

If the transaction requires credit notes, prepaid reconciliation, document allowances or another financial structure outside the current creator, use a final model that implements it. Do not change unit prices merely to force the current preview to a desired balance.

Test the handoff with fictional data

Create a representative example containing the kinds of references, tax categories, quantities and payment instructions the workflow needs. Include a known missing-field case so you can see whether the final system detects it clearly.

Inspect the actual mapped fields and final amounts against the confirmed source. A file opening successfully is not proof of correct semantics or profile conformance. Keep required technical validation and business-fact review as separate checks.

Protect invoice information during testing. Do not upload real customer records to an unfamiliar converter simply to discover its capabilities. Local preparation and external processing involve different data flows and need appropriate handling.

Complete validation and delivery

Obtain the required validation evidence for the exact final format and version. Keep the report with the tested file and configuration. A previous example’s success does not automatically cover the new invoice or a different recipient profile.

Identify who sends the final document and who checks the operational result. A local export does not submit through Peppol, a portal or a tax-authority system. Creation, transmission and acceptance should each have evidence appropriate to their scope.

If a readable copy accompanies the processing document, compare their content. Do not give the recipient contradictory representations and leave them to decide which values apply. Preserve the intended final versions together under your business process.

Keep the product role accurate

You can prepare and revise supported fields locally before the handoff. That remains useful work even when the final output requires another system. Explain the boundary clearly rather than disguising preparation as completed formal export.

Record the source-data owner, mapping owner, validator and delivery owner in the handoff. This makes remaining actions concrete and prevents a required stage from being left as an assumption. Mark unresolved facts as unresolved until confirmed.

After corrections, generate fresh files and repeat affected checks. Earlier downloads do not update automatically. The practical result should be an accurate source record and an implemented final workflow, not a reassuring format name attached to an output the creator never supported.

A concrete handoff note can identify the supported source fields, confirmed missing facts and final provider responsible for each gap. Include the required format/profile/version and who will retain the test report. This lets another person continue preparation without mistaking a complete-looking preview for a completed standards export, or assuming that the customer will supply every missing fact after delivery.

Retain the source-to-target comparison with the exact final export.