A buyer reference usually serves the buyer’s internal routing or allocation process, while a purchase order reference identifies the order issued by the buyer. They can both matter on one invoice, and one should not automatically replace the other. Ask the customer which reference it requires and where the final receiving process expects it.
The buyer-information preparation guide treats references as labelled business information, not interchangeable numbers. The current creator has one general buyer/purchase-order reference field. It does not implement every separately typed reference found in a recognised structured invoice profile.
Understand the two purposes
A buyer may assign an internal reference so the invoice reaches the right team, approver or budget owner. A purchase order number identifies a purchasing document. A customer can need both to route the invoice and match the charge with its order, even if both values look like short alphanumeric codes.
OpenPeppol’s published binding distinguishes the buyer-reference and purchase-order-reference meanings. It also documents reference-related rules for that profile. Those documented requirements should be read in their current version and scope, not extended into an assumption that every invoice format or jurisdiction applies an identical rule.
For a fictional customer, department reference “OPS-WEST” could identify the internal routing destination while “PO-574” identifies an order. Combining them as “OPS-WEST PO-574” may be understandable to a person, but does not establish that two required structured fields have been represented correctly.
Preserve the customer’s labels
Read the order and current invoicing instructions. Record the exact label, value, source and intended role for each reference. If the instruction simply says “reference”, ask whether it means the purchase order, internal buyer reference, contract or another code.
Do not decide by appearance. A code beginning with “PO” may be suggestive, but the customer’s actual definition governs its purpose. Leading zeros, punctuation or spaces may be meaningful to the receiving process, so preserve confirmed values unless the instruction specifies another representation.
The multiple-reference preparation workflow is useful when the onboarding pack contains several numbers. Classifying the values before entry prevents a prominent but irrelevant code from being copied into the only available box.
Check what the chosen application can represent
In EInvoiceCreator, the general reference appears in the application model and readable invoice. The field does not provide a complete mapping of buyer reference, order reference, contract reference and project reference into separate standard elements. A populated reference box therefore does not prove that a target profile’s reference requirements are met.
If the recipient needs only one confirmed value for the current preparation output, enter it with a clear understanding of its purpose. If several separate values are required, retain them in the preparation sheet and use supporting software for the appropriate final structure. Do not imply that adding the other values to notes completes a formal mapping.
The field checker also does not verify an order’s existence, available balance or relationship to the buyer. A correctly typed reference can still point to another transaction. Compare the value with the relevant order and customer instruction rather than relying on the absence of a software error.
Keep line-level references distinct
An order may include several lines or deliveries. A document-level purchase order reference can identify the order without identifying each billed line’s relationship to it. If the customer requires order-line references, obtain those facts and check whether the final software supports them.
Do not hide line-specific references in descriptions and assume that an automated matcher will extract them. Readable descriptions remain useful, but structured requirements can be more precise. The current creator has no complete typed order-line-reference model.
For a fictional sale of two equipment types, a single order number may identify the purchase while separate order-line numbers distinguish the items. The preparer should preserve that distinction even when the initial preview shows only the general reference.
Resolve missing or contradictory instructions
If the customer says that no purchase order exists, ask which routing reference or alternative process it expects. Do not invent an order number to satisfy a required field in external software. Follow the actual specification and recipient instructions, using a supported documented representation where applicable.
If the order and email instructions disagree, ask the authorised billing or procurement contact to clarify which value applies. Keep the answer and affected invoice identifiable. A recent informal message should not silently overwrite a confirmed purchasing record without understanding the change.
Reference issues can cause business rejection even when a file is technically valid. A validation report should therefore not be treated as proof that the customer recognises the order or accepts the charge.
Review before export
Read the general reference in the preview and compare it with the source. Check that an old sample or previous-customer reference has not remained in another field such as payment instructions. The invoice number and payment reference serve different jobs from the buyer’s procurement references.
For the final hand-off, identify which references are confirmed and which require separate structured mapping. The current printable output and own-schema JSON are preparation outputs, not verified standard-specific documents. Keeping the reference purposes clear helps the next system route and match information without guessing what a single combined string was intended to mean.