Record bank-transfer instructions from an authorised source and keep the account destination, currency and payment reference clear. Review the exact values before sharing the invoice. Entering bank details into a document does not verify ownership, confirm that the account accepts the payment or initiate a transfer.
The payment-information workflow treats those as separate responsibilities. The current creator provides payment text fields and a preview. It has no banking connection, payment processor or verified mapping of every account component into a formal structured format.
Collect the intended destination
Use the confirmed account holder’s instructions for the agreed payment method. Identify the account name and relevant identifiers, together with any required institution information. Do not construct missing values from a logo, a bank name or an old invoice whose instructions may have changed.
Confirm that the instructions belong to the intended payee. If a party other than the seller is to receive payment, preserve the authorised arrangement and identify the final representation required. The current app has no dedicated structured payee-party workflow.
Keep the source and confirmation process with your business records. The invoice should show the necessary customer-facing details, while internal evidence of authorisation can remain separate. A professional layout is not evidence that the account instruction is genuine.
Preserve account identifier roles
An account identifier and an institution identifier serve different purposes. Collect the values the payment method actually requires and keep their labels. Do not substitute a BIC for an account number or assume a domestic account identifier is an IBAN.
The comparison of IBAN and BIC information explains those roles. Exact characters matter, so avoid typing from memory or changing formatting without checking the source. A visually familiar string can still contain a transposed character.
The creator does not perform account-checksum, banking-directory or ownership verification. A field accepting text proves only that the application can preserve it. Use the appropriate external confirmation process for the banking facts.
Enter readable instructions without hiding facts
Use the supported payment method for a concise description of how payment is expected. Put necessary destination instructions in payment details and the reconciliation value in the payment-reference field. Keep the amount and currency consistent with the agreed invoice.
Avoid embedding the only payment reference inside a long paragraph. The customer should be able to identify the value to reproduce without interpreting internal commentary. Likewise, avoid repeating account identifiers across several notes unless there is a clear reason.
Do not include bank login credentials, passwords, authentication codes or full card data. These are not needed to prepare bank-transfer instructions and should not circulate with an invoice. The current app requires no such credentials.
Check currency and special requirements
Confirm that the instructions are appropriate for the agreed invoice currency and payment route. A business may have several accounts or currency-specific instructions. The creator cannot determine which account should receive the payment or convert invoice amounts.
If an international transfer requires additional bank instructions, obtain them from the authorised source. Do not infer correspondent details or charges from a previous customer’s transaction. Keep the actual agreement and payment-provider requirements visible.
Where the recipient needs typed structured fields, preserve the underlying components separately. OpenPeppol’s credit-transfer group illustrates distinct account identification, name and institution roles. A readable text block containing those facts is not automatically that mapped structure.
Review changes through a trusted process
Unexpected replacement instructions deserve independent confirmation using an established contact route. Do not rely only on the new message’s phone number or apparent branding. The creator cannot authenticate the sender or determine whether a request to change bank details is authorised.
Once confirmed, update every relevant occurrence in the draft. A previous account can remain in notes even after payment details are replaced. Search the preview and intended exported file for the old value where practical, then create a fresh final version.
Do not send conflicting alternatives without explanation. Two account blocks can leave the customer unsure which one is current. Resolve the intended destination before treating the invoice as a clear payment request.
Finally, compare the preview with the confirmed source character by character for critical identifiers. Retain the approved instruction and final invoice version under your normal business process. The current printable output and application JSON support preparation; line-item CSV is not a complete payment instruction document. None of them verifies account ownership, processes payment or establishes a formal standards mapping or recipient acceptance.
A practical preparation example
A useful fictional review case starts with one confirmed destination and a draft containing the previous instruction in notes. Update the supported payment details, then deliberately search for the old account string. The remaining occurrence demonstrates why a field-level edit is not a complete document review. Remove or correct the stale text before considering the instruction consistent.
For a real invoice, retain the source confirmation separately and compare the final output against it. Record any unresolved mismatch as an action, rather than approving the payment section because the amount and due date happen to be correct.