How References and Supporting Documents Fit into Structured Invoices

Map each reference according to the document or process it identifies. A buyer routing value, purchase-order number, preceding invoice and supporting-document reference are not interchangeable. Copying a valid identifier into the wrong role can change the meaning even when the string is preserved exactly.

The mapping preparation workflow records reference purpose before target structure. The current creator has a limited reference model and no formal attachment or correction-chain implementation. Some required relationships therefore need a separate preparation record and suitable final software.

Identify who assigned the reference

Ask whether the value came from the buyer, seller, procurement system or another source. Record what it identifies and why the receiver needs it. Do not infer the role solely from a short label such as ref in an email.

A buyer reference can support internal routing, while an order number identifies a purchasing record. A payment reference supports matching a receipt. The same invoice may need all three roles with different values.

Keep the confirmed source instruction with the mapping entry. A sample from another customer can demonstrate a structure without supplying your customer’s actual value or requirement. Never copy its identifiers into a production invoice.

Preserve document relationships

A reference to a preceding invoice connects the new document to an earlier one under the applicable process. It is not merely another convenient place for the current invoice number. Keep the document identity and relationship explicit.

The current app does not implement formal credit notes or a correction chain. Renaming an ordinary positive invoice or adding an old number to notes does not create those document semantics. Use software that supports the required relationship.

An order, contract, delivery record and project can also have distinct reference roles. Do not place every identifier into one target field because the source form has only one general box. Preserve the missing components separately.

Separate references from supporting files

A document reference can identify evidence known to the receiver, while another workflow may include an external link or embedded file. Confirm the actual profile and receiver requirement. A reference string alone is not the supporting file itself.

OpenPeppol’s published invoice structure distinguishes several reference groups and supporting-document roles. Treat that as a specific binding example. The current creator does not formally generate those groups or attach documents by naming them in notes.

Use the source-model gap review to identify absent attachment and typed-reference features. A clear handoff should say which evidence exists, which document role it serves and how the final system will represent it.

Review privacy before sharing evidence

Supporting records may contain internal prices, personal information or unrelated correspondence. Include only evidence appropriate for the receiver and authorised workflow. An invoice reference should not expose a private access token or a link granting excessive permissions.

Use fictional attachments when testing a mapper. Confirm how the final system handles names, types and links without uploading real customer records to an unfamiliar service. Local invoice preparation does not authorise every external document upload.

Keep source evidence accessible to the responsible reviewer through the appropriate business process. Do not force confidential internal analysis into customer-facing notes solely because the final file lacks an attachment feature.

Specify target mapping rules

For each reference, record source, owner, purpose, target role and any required scheme or relationship. Confirm cardinality and conditional requirements under the actual profile. A generic text type does not establish semantic suitability.

If a required reference is missing, obtain it from the appropriate party. Do not fabricate a plausible order number or reuse the invoice identifier to make a validator stop reporting an error. That would hide a factual gap rather than resolve it.

Check revision behaviour too. A copied draft can retain a previous order or preceding-invoice value. Updating the current invoice number does not rewrite every reference or note. Review those relationships deliberately after a change.

Test with distinguishable identifiers

Use different fictional values for buyer routing, order, payment and preceding document. Trace them to their actual target roles and readable presentation. A test that uses one value everywhere is too weak to reveal an exchange.

Remove a conditionally required reference in a negative case and inspect the final workflow’s response. A structurally valid file can still violate a profile relationship, so retain the required business-rule evidence as well as schema results.

Keep the exact source, output and configuration with the test. The creator’s application JSON, CSV and printable output do not establish formal reference mapping, attachment support or recipient acceptance. Accurate preparation preserves the relationships so an implemented final system can represent and validate them without guessing.

A document-reference test should include one external evidence reference and one preceding-invoice reference with different demonstration values. Confirm that the final provider preserves their relationship types rather than putting both into one general note. Then remove the optional evidence record and inspect whether the remaining relationship is unchanged. This tests the mapping’s boundaries as well as its positive output.

Identify the required reference relationship explicitly.