Where to Put a Customer’s Remittance Instructions

Read a customer’s remittance instruction as a set of distinct requirements before deciding where to put it. It may concern the reference used with payment, a notification sent after payment or an internal matching process. These are different actions, and a note on the invoice does not perform all of them.

The payment preparation workflow keeps method, reference, destination and supplementary explanation separate. The current creator can preserve supported text, but it does not send remittance messages, connect to a bank feed or reconcile receipts.

Clarify what the customer means

Ask for the actual operational instruction when the wording is ambiguous. “Use our remittance details” could refer to a reference, an email destination or a document the customer generates. Do not infer one role merely because another invoice used similar language.

Keep the instruction with its source and date. A purchasing contact may relay a finance-team requirement, while an old order attachment may contain superseded details. Resolve contradictions with the responsible contact rather than combining incompatible instructions into one note.

Confirm which party is expected to act. A buyer’s process for notifying the seller after payment differs from the seller’s responsibility to place a reference on the invoice. The creator cannot decide or execute those external responsibilities.

Separate payment reference from notification

A payment reference connects the incoming amount with the invoice under the agreed reconciliation process. It belongs in the supported reference field when appropriate. A request to email remittance advice is a separate action outside that field.

Do not paste an email address into the payment-reference box merely because the instruction mentions remittance. Likewise, a purchase-order number should not replace a seller payment reference without confirming the agreed process. Several identifiers can be valid while serving different roles.

OpenPeppol’s remittance-information field illustrates a defined reference role in a structured payment group. The creator does not implement that complete mapping or an email-notification integration. A correctly placed application string is still only supported application data.

Place customer-facing explanation carefully

Use a concise payment detail or note where the recipient needs readable context. Keep the exact reference in its supported field and explain any necessary action separately. Avoid repeating lengthy internal instructions that the customer already controls and that add no invoice value.

A fictional instruction might say the customer will send a payment advice identifying DEMO-204 after settlement. The invoice can preserve the relevant agreed reference, but the creator cannot generate that future advice or confirm that it was sent.

If the instruction requires an attachment, portal entry or another document after payment, assign that task in the business workflow. Writing “send advice” in notes does not create an automated notification or verify its completion.

Confirm destination and privacy

Check any notification address or portal instruction through the appropriate trusted process. Do not assume a new address is authorised because it appears in a payment-related message. The creator cannot authenticate the instruction or verify mailbox ownership.

Keep unnecessary banking and personal information out of notification text. Include only what the agreed process needs. An invoice and its supporting files can circulate beyond the initial contact, so internal discussions and credentials should remain outside customer-facing notes.

The guide to sensitive information in notes provides a content review. Apply that review to copied remittance instructions as well as text you wrote yourself, since pasted email chains may contain private signatures or unrelated history.

Identify missing structured requirements

If the customer requires typed references or payment data in a formal format, record the exact format, profile and field roles. Do not assume a note containing the values satisfies the requirement. The final exporter needs to place them in the correct structure.

Preserve the confirmed source values separately for that mapping. A long combined string can make it unclear which part is the reference, contact address or explanation. A small preparation table is more useful than asking the receiving software to parse prose.

Use an implemented final system for requirements beyond the creator’s model. Its current outputs are printable output, application JSON and line-item CSV. They do not provide formal remittance mapping, bank integration or settlement-message automation.

Review the final instructions together

Compare the reference, account destination, due date and explanatory text for consistency. Remove stale instructions copied from an earlier customer or invoice. After revisions, export a fresh version and distinguish it from previous downloads.

Keep a task record for any notification or post-payment step that remains outside the document. Identify who performs it and what evidence confirms completion. That prevents an instruction printed on the invoice from being mistaken for an action already performed.

A clear remittance preparation record tells the parties which value to use and which external tasks remain. It does not imply that the creator tracks payment, verifies banking facts or guarantees acceptance of the customer’s internal process.

A practical final check

Keep an action list beside the draft showing the responsible party, required notification and evidence of completion. That list belongs to the operational workflow and should not be confused with a payment action already performed by the editor.