Before handing invoice data to a formal exporter, confirm the target context, source meanings, mapping decisions and unresolved gaps. A completed form is not enough. The final provider needs accurate facts and a clear implementation brief, not an assumption that every visible value already has a verified standard role.
Use this checklist after the mapping preparation workflow. It assesses readiness for an implemented mapping and validation process. The current creator does not itself export or formally validate an EN 16931 document.
Confirm the target combination
Record the required specification edition, profile, syntax version and recipient instruction. Keep production requirements separate from drafts and archived examples. Do not use latest as the only version description.
Identify the relevant schema, business-rule and recipient-specific checks. A general XML parser result cannot establish that the intended profile was tested. The final provider should state which rules it actually implements.
Assign delivery separately. A standards file still needs an authorised route and recipient information. A locally downloaded output is not evidence of submission, receipt or business acceptance.
Confirm source meanings and evidence
Review seller and buyer roles, identifiers, addresses and contact information. Keep names and values attached to the correct parties. A valid-looking identifier can still belong to another entity.
Check invoice identity and date roles against the appropriate records. An issue date, due date and service period are different facts. Use distinguishable values in tests so an accidental exchange is visible.
Keep references separate by purpose: buyer routing, order, payment matching and preceding documents are not interchangeable. The current app’s limited reference model may need additional source records for the formal target.
Confirm line and financial relationships
For every line, preserve the supplied scope, quantity, unit and price basis. Check required precision and whether the target needs coded units or a separate base quantity. Do not silently truncate source data to fit a narrower field.
Identify allowances, charges and payments according to their accepted roles. The creator’s percentage line discount is not a complete financial model for every transaction. Use appropriate final software for unsupported adjustments or payable reconciliation.
Confirm treatment decisions with the responsible reviewer and preserve category, rate, reason and required grouping facts. Mapping expresses the decision; it does not establish tax applicability from a country’s name or a zero result.
Review capability gaps explicitly
Use the model-gap register to distinguish missing source facts, absent fields, absent adapters and absent validation. Each gap should have an owner and a concrete completion check. Do not hide required data inside unrelated fields.
A typed endpoint, exemption code or line period is not implemented merely because a note mentions it. Preserve confirmed components separately and give them to a system that genuinely maps the required role.
Keep planned capabilities separate from current output claims. The creator remains printable output, application JSON and line-item CSV with application field checks. Naming the target standard in a draft does not change those outputs.
Review mapping and test evidence
The mapping record should connect source fact, intended term or group, target representation, transformation and applicable condition. Read definitions rather than relying only on similar labels. A source and target both accepting text does not establish semantic equivalence.
Use fictional cases with different party and reference values, meaningful quantities and relevant conditional data. Include missing-field and unsupported-case tests. Check that the final workflow reports gaps rather than silently inventing values.
Inspect the actual exported data and required validation report. Keep the exact input, file and configuration together. A screenshot or previous example’s success is not evidence for the current revision.
Complete a clear handoff
Give the final provider confirmed facts, mapping decisions, gap actions and target instructions. Identify who reviews the resulting document and who performs delivery. A useful handoff makes responsibilities explicit instead of leaving compliance as an undefined final task.
After any source or implementation revision, repeat the affected checks and generate a fresh final output. Earlier files and reports retain their earlier scope. Keep the intended delivered version distinguishable from drafts.
A readiness review can establish that preparation is organised and remaining requirements are assigned. It does not by itself certify conformance, legal validity or acceptance. Those claims need the appropriate implemented representation, validation and real operational evidence in the final workflow.
A final packet can contain the receiver instruction, source-evidence index, mapping sheet, gap register, fictional test results and exact final-file validation record. These documents serve different purposes. The receiver instruction establishes the target; source evidence supports facts; the mapping sheet explains representation; the gap register identifies remaining work; tests show implemented behaviour; the final report covers the specific output. Review the packet for contradictions before treating the handoff as ready.
A colleague should be able to identify which file will be delivered and which unresolved action could still block it. If that answer depends on a private conversation, make the record explicit. This is a practical readiness check that helps preserve quality when responsibility passes between the preparer, adviser, software provider and delivery operator.