How Payment Information Fits into the Semantic Model

Map payment information by the purpose each value serves: method, destination, timing or reconciliation. A paragraph of readable instructions can contain several facts without giving each the typed role a formal invoice model requires. Preserve the components before selecting target fields.

The mapping preparation workflow starts from confirmed instructions. The current creator supports its own payment method, details, reference and notes, but it does not implement a verified formal payment group, banking validation or settlement integration.

Establish the payment arrangement

Use the accepted terms and authorised account instruction. Confirm who pays, who receives payment and how the process works. The seller, payee, buyer and contact person can be related without being identical roles.

Do not infer a direct-debit arrangement from a bank account number or a phrase copied into notes. Authorisation and collection require the appropriate external process. The mapper should preserve confirmed facts rather than invent the operational arrangement.

Keep the source and scope of each instruction. A familiar destination from a prior invoice may not apply to a different currency or authorised payee. Resolve those questions before technical conversion.

Separate method from terms

The method concerns how payment is expected. Terms concern timing or conditions. A method code in a formal profile is not the same thing as readable text saying bank transfer, and a due-date field cannot express every conditional schedule.

OpenPeppol’s payment documentation illustrates separate roles for method, remittance information, transfer account and mandate data. Use it as a profile-specific example, not a declaration that the current app formally generates those groups.

Record the target code list and confirmed mapping where required. Do not guess a method code from a sample or assume any numeric value is permitted. A code’s existence also does not prove it describes the actual agreement.

Preserve destination components

Keep the account identifier, account name and institution information separately in preparation records where the target requires them. A combined payment paragraph may be clear to a person but ambiguous for a parser.

Do not treat an institution identifier as an account identifier or a remittance reference as either of them. Preserve exact values and significant characters. A typed field needs both the right content and the right role.

The creator does not check account ownership, directory status or currency capability. A formal mapping can also be technically correct while naming an unauthorised destination. Banking confirmation and source review need their own evidence.

Keep references distinct

A payment reference supports receipt matching; a buyer reference may support internal routing; an order reference identifies procurement. Similar-looking strings do not make these meanings interchangeable. Collect each under the agreed process.

Use the reference mapping guide to identify document and process roles. The current app’s limited reference model is a gap to record when a target needs additional typed references, not a reason to duplicate one string into every field.

Check repeated values after edits. A supported reference field can be corrected while notes retain the old value. The final representation should not contain contradictory instructions simply because the structured mapper ignores prose.

Identify additional payment roles

A payee different from the seller or a mandate arrangement may require separate target structures. Preserve the authorised role and source components. Do not overwrite seller identity or hide a mandate identifier inside an unrelated note.

Partial-payment schedules, prior receipts and balances can also require a financial model beyond the current creator. A payment is not a discount. A note stating that a deposit was received does not make the numeric total deduct it.

Use appropriate final software where those features are required. An adapter that merely copies supported source fields cannot complete a missing settlement model without additional confirmed data and implemented calculations.

Test the mapping safely

Use fictional values that clearly distinguish method, account, buyer reference and payment reference. Trace each into the actual target output. A test with the same string everywhere can hide a role reversal.

Add a known unsupported mandate or payee requirement and verify that the workflow reports the gap clearly. Do not accept an output that silently drops the requirement while claiming a complete formal invoice.

Inspect any required validation report and preserve the exact file and configuration. Technical success does not establish account authorisation, payment initiation or receipt. Those belong to separate implemented processes.

A useful payment mapping record identifies each fact, source, target role, code transformation and remaining external responsibility. The creator can help prepare supported information locally, but its current JSON, CSV and printable output do not establish EN 16931 payment mapping, legal validity or successful settlement. Complete the required formal implementation and delivery before making those claims.

For a practical test, put the fictional payment reference and buyer reference into different source fields and give them visibly different prefixes. Confirm the actual target roles after export. A successful total comparison cannot detect their exchange, while a role-level review can identify the error without needing real account information or a live payment service.