Choose a payment reference that your business can use to connect a receipt to the intended invoice. Confirm that the customer can reproduce it in the relevant payment process. Keep it consistent wherever it appears, and avoid adding unrelated instructions inside the reference itself.
The payment-information workflow separates this reconciliation value from method, terms and account destination. The current creator provides a payment-reference field, but it does not connect to a bank feed or verify that a customer used the reference when paying.
Decide what the reference should identify
An invoice number can be a useful reference where it fits the agreed process. Another established value may be appropriate if the customer or payment workflow requires it. Use the actual reconciliation arrangement rather than a random label invented during final editing.
Keep the value specific enough to distinguish invoices from the same customer. A reference containing only the customer’s name may not identify which of several open documents is being settled. The creator does not maintain an invoice ledger to resolve that ambiguity later.
Avoid including unnecessary personal information in the reference. It may appear in payment records and be handled by people beyond the original purchasing contact. Use a business identifier suited to the task rather than private notes or confidential project commentary.
Distinguish buyer and seller reference roles
A buyer reference may support internal routing, while a purchase-order number identifies a procurement record. A payment reference helps the seller assign an incoming receipt. They can be related, but they are not automatically interchangeable.
If a customer asks you to use its order number as the payment reference, confirm the process and preserve that instruction. Do not assume the existence of an order number means it belongs in every reference field. A receiver may need both values in different roles.
OpenPeppol’s payment documentation illustrates a separate remittance-information role. This is a defined structured meaning, not evidence that the current creator maps every application reference into that profile. The final format may need separate fields beyond the current model.
Check practical payment constraints
Ask whether the payment channel or customer process restricts characters or length. Preserve the agreed usable value rather than a decorative phrase that may be truncated or altered. Do not assume every bank interface accepts identical punctuation and spacing.
If a required reference must be entered exactly, make that clear in the instructions without adding text to the value itself. Keep the payment reference concise and use surrounding payment details for necessary explanation.
For a fictional preparation example, an invoice identifier of DEMO-204 could be used consistently as the reference if that is the agreed process. This does not establish uniqueness across your business. The creator does not check invoice numbering against previous documents or bank records.
Keep repeated values synchronised
Compare the reference field with payment details, notes and any cover message prepared elsewhere. A copied draft can retain the previous invoice’s value in free text even after the main field is updated. The numeric and textual preview cannot infer which occurrence is authoritative.
Avoid repeating the reference unnecessarily. Each repetition creates another place to update. Where the supported payment field displays it clearly, additional prose may be redundant unless the customer needs a specific instruction.
After a document revision, decide whether the agreed reference remains appropriate. Do not change it casually if the customer has already used or recorded it. Keep the relationship between versions and payment records clear under your business process.
Review account details separately
A clear reference does not verify the account destination or authorise a change in bank instructions. Review those facts through the appropriate trusted process. Do not treat matching reference text as proof that a payment request is genuine.
The guide to reviewing bank details before sharing explains that separate check. Keep account verification, reference selection and invoice calculation as distinct tasks so success in one does not create false confidence about the others.
The current creator neither sends a transfer nor checks account ownership. It also cannot confirm that the receiving payment system preserves the reference exactly. Those operational details need an implemented banking or accounting workflow outside the invoice preparation tool.
Before export, read the reference in the preview and compare it with the accepted instruction. You can revise the payment section locally and create a fresh printable or application-data output. Earlier downloads retain old text, so make the intended final version clear.
Keep the reference decision with the invoice records where appropriate. If a formal standards format is required, review its mapped remittance field in the final system. The current application JSON and line-item CSV do not establish that mapping or provide receipt reconciliation, settlement tracking or recipient acceptance.
A practical preparation example
For a repeated-customer test, prepare two fictional invoices with different identifiers and inspect both payment references. Each should point to the intended document under the agreed process. Then revise one draft and check that the other’s reference has not been copied into its notes. This tests the practical reconciliation distinction without using a real customer’s banking information.