Prepare direct-debit information through an authorised arrangement and software that implements the relevant collection process. An invoice note saying an amount will be collected is not a mandate and does not initiate collection. Keep invoice instructions, authorisation evidence and the actual payment workflow separate.
The payment-information workflow identifies the arrangement before entry. The current creator has no mandate management, direct-debit integration or payment processor. It can display supported text, but it cannot obtain consent, schedule a debit or confirm settlement.
Confirm the arrangement exists
Use the appropriate business and payment-provider process to establish authorisation. Do not assume a previous transfer or the customer’s supply of an account number creates direct-debit permission. The required process depends on the actual scheme and circumstances.
Keep the evidence and its scope in appropriate secure records. The invoice is not a place to collect login credentials, passwords or authentication codes. The creator does not require those secrets to prepare a document.
If authorisation is pending, do not present collection as already scheduled. Record the unresolved action and identify who will complete it through the provider. A confident sentence in notes does not complete an operational step outside the app.
Preserve distinct reference roles
A mandate reference identifies the authorisation arrangement in its relevant workflow. An invoice number identifies a document, and a remittance reference supports payment matching. Do not use one value in all three roles without confirming the actual process.
OpenPeppol’s payment-mandate documentation illustrates separate mandate-reference and payer-account data. These are defined structured roles, not instructions to paste every value into an ordinary invoice note. The creator does not implement that formal group.
Collect the required reference, its source and intended mapping separately for the final provider. An unexplained string cannot tell software whether it is an account identifier, mandate reference or invoice number. Preserve meaning alongside the characters.
Collect only necessary payer information
Follow authorised provider instructions to identify the required payer details. Avoid gathering extra sensitive information because another sample document contains it. Keep invoice-facing facts separate from confidential operational records and access credentials.
Confirm the payer role against the actual arrangement. The buyer, payer and contact person may differ. The creator cannot establish those relationships from names or email addresses, so obtain appropriate confirmation before transferring data into collection software.
Use fictional records to test the technical handoff. Do not expose a customer’s real banking data in a public screenshot or unfamiliar demonstration service. Local invoice processing does not guarantee the privacy of every later file destination.
Coordinate timing and instructions
The invoice due date and planned collection date may need coordinated treatment under the agreement. Confirm that arrangement rather than assuming the creator schedules collection from its due-date control. The app performs no debit action.
Review the text for contradictory directions. An instruction to make a transfer can conflict with a statement that the amount will be collected. Resolve the authorised method before delivery so the customer is not asked to take incompatible actions.
The guide to payment method and terms explains these different roles. A method label does not establish timing conditions, and a date does not create authorisation. Keep the complete arrangement supported by the appropriate external records.
Use implemented collection software
Give the provider the confirmed source facts and target-format requirements. Ask which operations it performs, which rules it validates and what evidence it returns. Do not infer full mandate support from a generic payment dropdown.
Where a structured invoice needs direct-debit fields, inspect the actual output and required validation report. Technical validity remains separate from the real authorisation’s existence and scope. Retain both types of evidence under your business process.
You can prepare supported invoice details locally, but final collection needs a suitable implemented system. Do not label the current application JSON or printable preview as a debit instruction that has been transmitted, accepted or scheduled.
Keep the invoice version, mandate reference and provider evidence connected. The creator does not track receipts, retry failed collections, reconcile payments or prove ownership of an account. Those responsibilities need their own implemented workflow.
For a fictional integration test, use separate demonstration values for invoice number, mandate reference and payer account. Verify that the final software places each in its intended role. Then test a missing required value and inspect the resulting error. This checks the handoff mechanism without implying that demonstration data creates a real mandate. A passing technical test should be reported as that specific test, not as proof that a customer’s collection has been authorised or will succeed.
A final checklist should name the provider responsible for collection, the record establishing authorisation and the evidence expected after submission. If any of those is missing, keep the operational step unresolved. The invoice editor cannot fill that gap by displaying a method label. This makes it possible to distinguish a prepared document from a scheduled collection and a scheduled collection from a confirmed receipt.
Check the delivered values after any revision, because an earlier technical report covers the previous file.