How to Prepare Payment Details and Notes for an E-Invoice

Prepare payment information so the recipient can understand how, when and against which invoice to pay. Keep the method, due date, reference and account instructions distinct. Review any supplementary notes for contradictions and unnecessary sensitive information before sharing the document.

You can prepare those supported details locally in the creator. It provides editable payment text and a live document preview, not payment processing, account verification or receipt tracking. It does not create bank mandates, initiate transfers or determine that the named account belongs to the seller.

Begin with the agreed payment arrangement

Use the accepted commercial terms to identify the intended method and timing. Do not infer the arrangement from a previous invoice or a bank account that happens to be available. A new customer agreement may use a different currency, reference or settlement schedule.

Record which party is expected to pay and who should receive the payment. In a simple sale, the seller is the payee, but some arrangements involve another authorised party. That distinction needs a clear, supported explanation and may require typed fields beyond the current model.

If the arrangement is not settled, mark the draft unresolved. A professional-looking payment section can conceal missing agreement just as easily as an empty field. Confirm the facts before asking the customer to act on the instructions.

Separate method from terms

The method describes how payment is expected, such as a bank transfer. The terms describe the agreed timing or conditions. A reference helps connect the receipt to the invoice. These facts support different tasks and should not be merged into one unexplained sentence.

The guide to payment method and terms explains the distinction. The current creator uses its own application payment fields. It does not convert a text method into a verified formal payment-means code or implement every structured payment group a destination may require.

Keep the due date consistent with any written terms. The app checks supported date rules, but it does not interpret every phrase in notes or calculate contractual conditions from prose. A sentence saying “pay within thirty days” can conflict with the selected date unless you review both.

Choose a usable payment reference

Use a reference the seller can recognise during reconciliation and that the customer can reproduce reliably. The invoice number may serve that purpose when appropriate, but the agreed process could require another value. Confirm any recipient constraints rather than assuming every banking field accepts the same characters or length.

Use the payment-reference workflow to decide what belongs in the supported field. Keep it distinct from the buyer’s purchase-order number unless the agreed process deliberately uses that value. Different identifiers can share a document without serving the same role.

If the reference appears again in payment text, compare both versions. A copied note may retain the previous invoice’s reference after the main field is updated. The creator does not automatically rewrite every repeated identifier in free text.

Collect bank instructions from a trusted source

Use the account holder’s authorised instructions and verify unexpected changes through an established contact process. Do not rely only on the fact that a message uses a familiar logo or arrives in an existing conversation. The invoice editor cannot determine whether an instruction was authorised.

Collect only the details needed for the intended method and currency. Where an IBAN, BIC or domestic account identifier is required, preserve its exact role and value. Do not invent a code from a bank name or substitute one identifier for another because they both look technical.

Review the supported payment text in the preview for transcription errors. The current application does not verify account ownership, check banking directories or confirm that the account can receive the chosen currency. Those checks remain part of the appropriate external process.

Recognise structured payment requirements

A formal invoice profile can represent payment method, remittance reference and credit-transfer account information in separate elements. OpenPeppol’s payment documentation illustrates these roles. A readable block containing similar words is not automatically that structured representation.

If the recipient requires typed account details, a payee party, direct-debit information or another profile-specific structure, preserve the source facts separately for final software. The current creator has no dedicated mandate-management or verified bank-field mapping workflow.

The guide to notes and structured payment fields helps identify where a text explanation reaches its limit. Do not treat a note as implementation of an absent field, calculation or integration. A matching screen label does not establish formal support.

Keep sensitive information out of notes

An invoice may circulate among purchasing staff, finance teams and advisers. Include customer-facing payment instructions that are necessary, but keep passwords, access codes, full card details and private internal commentary out of the document. The creator does not need banking credentials to prepare an invoice.

Use fictional data when demonstrating the payment section or testing an export. Avoid real account details in screenshots intended for public sharing. Local processing limits application transmission, but downloaded files and screenshots still need appropriate handling.

Optional browser draft storage is explicit and is not an encrypted account vault. Protect the device and downloaded files using your normal business process. A draft remaining on a shared browser can expose payment and customer information even when the app sends no invoice-data requests.

Review special arrangements before export

A payee different from the seller needs its own confirmed role. Foreign-currency payment may need instructions different from a domestic transfer. Direct debit requires an authorised external collection arrangement, not merely a sentence saying the amount will be collected.

Partial-payment schedules and prior receipts also need care. The current app does not implement an instalment ledger or deduct prepaid amounts from its total. Do not alter the commercial price to make the preview show an account balance the model cannot reconcile.

Where the agreement exceeds the available fields or financial model, finalise in suitable software. Keep the unsupported requirement visible in the handoff rather than asking the customer to infer an important payment condition from a vague note.

Complete the final instruction check

Read the document as the person making payment. Can they identify the invoice, amount, currency, date, authorised destination and required reference without resolving contradictory statements? Compare the details with the accepted terms and confirmed account instructions, not just with the previous draft.

Use the final payment checklist to record unresolved actions and the reviewed version. After any correction, create a fresh export. Earlier downloaded files do not update when the workspace changes, so keep the intended final version clear.

The creator’s printable output, application JSON and line-item CSV support preparation only within their documented scope. They do not process payment, confirm receipt, verify account ownership or guarantee recipient acceptance. Complete any required formal mapping and delivery through the appropriate implemented workflow, and retain the final instructions with the business evidence supporting them.

A practical preparation example

Consider a fictional supplier preparing a second invoice for an existing customer. The new agreement uses the same method but a different due date and payment reference. The account instruction remains unchanged. A useful review changes the date and reference, checks any repeated wording and confirms that the authorised destination is still applicable. It does not replace the account merely because the document is new or assume the old written terms still apply.

A small preparation sheet can separate agreed facts, entered values and review evidence. For example, it can show who confirmed the method, which record establishes the due date and where the account instruction was authorised. This makes unresolved questions visible before final export and avoids using a familiar-looking preview as the only evidence that the payment section is accurate.