Map invoice identifiers and dates according to their business meanings, not by copying every reference or calendar value into a similarly named field. The invoice number, issue date, due date and supply-related dates describe different facts. Equal values in one example do not make their roles interchangeable.

The mapping preparation workflow starts with confirmed source facts and the actual target specification. The current creator provides supported invoice identifiers and dates in its application model, but it does not implement every date or reference role in a formal invoice binding.

Preserve document identity

Identify the invoice number that names the issued document under the seller’s numbering process. Keep it distinct from a customer account code, purchase order or payment reference. The source field needs a clear role before the target location is selected.

The creator does not check numbering uniqueness against previous invoices or an accounting ledger. A value passing its field check is not proof that the seller has not used it elsewhere. Review identity against the appropriate business records.

Do not add a format name to the invoice number as a substitute for a profile identifier. Those values describe different things. The final model may need an explicit specification context separate from the commercial document’s identifier.

Map the issue date accurately

The issue date represents when the invoice is issued, not necessarily when the service took place or payment is due. Use the actual intended fact and preserve its source. A convenient current date is not automatically correct for a revised or previously issued document.

Check the target date representation and required format. A locale-specific display such as day/month/year should not be parsed by guesswork if the source can supply a clear date value. Keep display formatting separate from semantic meaning.

A valid calendar string can still represent the wrong event. Technical validation may confirm its shape without proving that it is the intended issue date. Review the business fact independently of the XML or JSON type.

Keep payment timing separate

A due date states an expected payment date under the relevant arrangement. It is not automatically the invoice date plus a universal period. Confirm the actual terms and any required final representation rather than inventing a default to complete the mapping.

OpenPeppol’s invoice binding illustrates distinct issue-date and payment-timing roles. Treat its dependencies as profile-specific examples. Do not assume the same rule applies to every format or that a written sentence in notes creates a typed payment term.

If the agreement has staged dates or conditions outside the current model, record the gap and use a suitable final system. The creator’s single supported due date does not implement every settlement schedule.

A delivery date, service period and tax-related date may have different roles from document issue. Determine the actual required facts with the appropriate review. Mapping should preserve that decision rather than infer dates solely from the invoice’s layout.

The current creator lacks dedicated line-period and broader supply-date groups. A date written inside a description remains text in its application exports. Preserve components separately if the target requires typed start and end dates.

Do not copy one value into all date roles because a simple sample happens to use the same day. Use separate fictional values in testing so an accidental role reversal becomes visible.

Handle references as references

A preceding invoice reference identifies another document, while an order reference identifies a procurement record. Preserve the role and associated evidence. A correct string in the wrong reference group can be semantically wrong despite passing a text-type check.

Use the reference and supporting-document mapping guide to keep these relationships clear. The current application has limited reference fields and no formal correction chain, so some required relationships need another source record and implemented adapter.

Do not change an existing invoice number to simulate a credit note or corrective workflow. The current app supports ordinary positive invoice preparation. Required document-type and correction semantics need a suitable final implementation.

Test with distinguishable values

Use a fictional invoice with an issue date, later payment date and separately confirmed service period. Give its invoice number, buyer reference and payment reference different values. Trace each into the actual target field rather than checking only whether all strings appear somewhere.

Then revise one source value and regenerate the document. Confirm that the intended target changes without overwriting another role. This tests the mapping rule and revision behaviour together.

Retain the exact input, target output and validation configuration with the test. A schema can test representation, while factual review establishes the event and identity being represented. Both are needed where the final workflow requires them.

Before delivery, use the required implemented exporter and repeat affected checks after edits. The creator’s JSON, CSV and printable output do not establish a formal EN 16931 identifier/date mapping, legal issuance status or recipient acceptance. Accurate preparation keeps those limits visible while preserving the facts the final system needs.