Ask the recipient which production version it accepts and record the answer precisely. Keep the specification edition, syntax version, profile release and validation configuration distinct. A new publication does not automatically prove that every receiver has migrated or that the newest general syntax is the right one to send.
The format-selection workflow makes version confirmation part of the decision before export. The current creator does not implement recognised format adapters, so its own application version is not evidence of support for a particular external standard release.
Identify which version is being discussed
A recipient’s instruction may name the invoice specification, the XML syntax or a software package release. These are not the same identifier. Ask what each number refers to before comparing it with another provider’s capability claim.
For example, a syntax version can remain fixed while a profile’s business rules or validation artefacts change. Conversely, a new syntax publication may not yet be included in the binding the receiver uses. Preserve the actual production combination rather than reducing it to one unexplained number.
The Commission’s syntax guidance notes that bindings target particular syntax versions. Use the applicable published binding and recipient confirmation instead of choosing a version because it appears newest in a general search result.
Distinguish production from draft material
Standards websites may retain older releases, future drafts and current production documents. Check the status and effective context of the source. A prominent new document is not necessarily the version currently required for sending invoices.
Keep a link or document reference and the date confirmed. Avoid writing only “latest version” in the preparation record, since that wording changes meaning over time. A reviewer needs to identify the actual combination used to generate and test the file.
Where migration arrangements exist, ask the receiver or responsible authority how they apply to the transaction. The Commission’s standard-access notice describes an edition transition; it should not be treated as proof that every customer has made the same migration decision.
Compare the software’s implemented scope
Ask the provider for the exact format and profile releases it produces, the syntax binding used and the validation configuration applied. A general claim of support may omit the version detail necessary to match the receiver’s requirement.
Do not infer support from the software’s own version number. A product update can concern interface changes without adding a new invoice format. Likewise, a small technical-rule update can affect validation without changing the main document specification number.
Request a representative fictional output and its validation evidence. Inspect the identifiers and actual fields rather than relying only on a screenshot or marketing description. Keep known limitations visible, particularly if some transaction types are not covered.
Pin the test context
Record the generated file, source-data version, exporter configuration and validator release together. That makes a later result reproducible. A report saying valid without identifying what was tested is weak evidence for troubleshooting or audit.
Use the profile requirement check to ensure the version record includes the actual profile, not just the broad syntax. A schema can permit structures that a specific business profile restricts. The relevant rule sets need to match the intended destination.
After a meaningful software or requirement change, rerun representative positive and negative cases. A previously successful file remains evidence of that earlier test. It does not automatically establish the new configuration’s behaviour or a different receiver’s acceptance.
Review the source data again
A version change can affect required fields, permitted values or relationships. Compare the updated requirement with the confirmed source record rather than assuming the same data is sufficient. Do not invent missing facts to make a new rule pass.
If the current creator lacks a required field, preserve the value separately and use an implemented final adapter. Its application JSON remains its own model, while printable output and CSV retain their documented scopes. Changing a note to name the new version does not add support.
Keep substantive tax and commercial review separate from technical migration. A software release does not establish that an entered tax treatment or party identifier is correct. The final workflow needs both accurate facts and compatible representation.
Confirm before delivery
Check that the file being sent is the one produced and validated under the recorded combination. Earlier downloads can remain in the same folder with similar names. Distinguish the intended final version and retain the relevant evidence.
Assign who performs delivery and who checks the actual result. A matching format version does not submit a document, guarantee legal validity or establish recipient acceptance. Those steps need their own implemented process and evidence.
A useful requirement record states the recipient, exact version combination, source confirmation, tested exporter and validation configuration. It replaces the vague promise of “latest” with a concrete, reviewable decision that can be checked again when either software or receiving requirements change.
If two provider documents cite different releases, stop and reconcile the discrepancy before choosing a final output. Preserve which source establishes the specification and which establishes the actual receiver configuration.