Invoice notes provide supplementary explanation. Structured payment fields identify facts by their defined role, such as payment method, account destination or remittance reference. A sentence can be useful to a reader without giving software the typed information a particular format requires.
The payment-information workflow separates those roles before export. The current creator has its own payment method, details and reference fields plus document notes. It does not formally map all of those values into a recognised e-invoice profile or process payment.
Identify the purpose of each fact
Ask what the information is meant to do. A payment reference helps assign a receipt to an invoice. An account instruction tells the customer where to pay. A note might explain an agreed arrangement. Those purposes should remain understandable even when several values appear in one document.
Do not put essential facts only in a long note if an appropriate supported field exists. A short reference in its own field is easier to compare with the agreement and less likely to be missed among general commentary. It also reduces unnecessary repeated copies.
Conversely, do not place a paragraph of internal explanation into a reference field. That field has a specific application role. The receiving customer should not have to decide which part of a sentence is the value to reproduce in a payment process.
Understand what a typed field supplies
A formal structured model assigns meaning through defined fields and relationships. OpenPeppol’s payment documentation, for example, distinguishes a payment-means code, remittance information and credit-transfer or mandate groups. These roles let software address values without extracting them from prose.
A readable sentence saying “reference DEMO-18” communicates something to a person. It does not by itself establish that DEMO-18 appears in the destination’s required remittance field. The final exporter must implement that mapping and validate the resulting document where required.
The creator’s application fields provide useful organisation within its own model, but that is different from a verified standards adapter. Similar interface wording does not prove equivalent field scope, cardinality, code-list use or conditional relationships in another format.
Avoid notes that imply unsupported behaviour
“Payment received” does not make the creator deduct a prepaid amount. “Collect by direct debit” does not create a mandate or initiate collection. “Pay the converted amount” does not perform exchange-rate conversion. Notes are not calculation or integration instructions.
If those statements belong to the real arrangement, preserve the facts and identify suitable final software. Do not export a document whose text suggests a financial behaviour that its numeric fields do not represent. A plausible final total cannot resolve a missing model.
The current creator supports ordinary positive invoice calculation and its documented line percentage discounts. It does not provide an account ledger, document-level allowances, prepaid reconciliation or payment processing. Keep those limits visible when deciding how to finalise the invoice.
Preserve unsupported structured facts separately
Where the customer requests a typed payee, mandate reference or particular bank component, record the values and roles outside the combined note. Include the target format, profile and version in the handoff. The final mapper should not have to guess whether one string is an account identifier or an invoice reference.
A practical preparation table can contain fact, source, current supported field and required final field. Mark gaps explicitly. This makes a readable note useful as explanation while preventing it from being treated as completion of the absent structured representation.
Use the direct-debit handoff process when mandate information is involved. It explains why a note cannot stand in for authorisation, a typed payment group or an implemented collection service. The same distinction applies to other payment features the current model lacks.
Review copied and revised text
After editing a supported payment field, search notes for the old value. A previous account, reference or due-date statement can survive in prose. The app updates its supported calculation but does not interpret and rewrite every sentence.
Remove redundant repetitions where they add no useful context. If a repetition is necessary, compare it explicitly with the primary supported value. Do not leave the customer to choose between conflicting instructions based on placement or font size.
Inspect the final file as well as the preview when application data will be handed to another process. A visual review does not establish that the intended structured fields exist or that the same information was preserved during transfer.
Before delivery, ask whether the receiver needs a readable explanation or a specific machine-addressable field. Use the supported current fields for their documented roles and a suitable final system for missing requirements. The app’s printable output, JSON and CSV do not certify formal payment mapping, account ownership, settlement or acceptance. A clear distinction between text and structure makes the preparation record easier to review and the final implementation easier to verify.
A practical final check
For a fictional handoff, write the account destination and reference in separate working columns, then inspect the final software’s exported fields. If both values remain only in one note, the typed mapping is still unfinished.