A value can look plausible and still fail a code-list rule because it is absent from the required list, belongs to another scheme or is not permitted in that field. A value can also belong to the list while describing the wrong fact. Check both technical membership and semantic applicability.
The mapping preparation workflow records the target list and meaning before transformation. The current creator uses application choices and free-text fields; it does not formally validate every unit, tax, payment or identifier scheme required by a recognised profile.
Identify the field’s list
Read the actual target documentation and profile version. A field may use a subset of a broader list rather than every possible value. Do not choose a code solely because a general search shows it exists somewhere.
OpenPeppol’s billing documentation identifies several lists for different roles, including units, payment methods and identifier schemes. These lists are not interchangeable. A numeric code valid for one field does not become meaningful in another because both accept text.
Record the source and version used by the mapper. Avoid a working sheet labelled current codes without an identifiable release or retrieval context. Later changes need a reproducible basis for comparison.
Separate source labels from codes
A readable label such as hour is not automatically the target’s coded unit. The mapper needs a confirmed relationship between source meaning and destination value. Do not derive codes by taking initials or copying an unrelated sample.
Keep original labels in the preparation record so mapping decisions can be reviewed. A source term such as unit can mean an individual item, package or business-specific measure. Clarify that meaning before standardising it.
The same applies to tax reasons and payment methods. Text can help people understand a decision without implementing a typed code. The current creator’s text fields do not become formal coded fields merely because code-like strings are entered.
Preserve schemes and roles
An identifier value may need a scheme that explains how it should be interpreted. Preserve both where required. An unexplained string can be mistaken for a tax number, endpoint or internal account code during transfer.
Do not infer ownership or legal applicability from the scheme or shape alone. A technically permitted identifier can still belong to the wrong party. Registry or banking checks, where relevant, have their own scope and are not supplied by this creator.
Use the party-role mapping review to keep values attached to the correct seller, buyer or other role. A valid code does not repair a semantically reversed party group.
Apply the profile’s restrictions
A broader syntax can allow values that a particular profile excludes. The final implementation needs the applicable restrictions, not only a generic schema. Confirm whether the required rules test membership, conditional combinations or another relationship.
Do not change a transaction classification just to select a permitted code. Resolve the correct representation from confirmed facts and the target requirements. If the target cannot express the intended case through the proposed adapter, report the unsupported case clearly.
Keep human-readable descriptions consistent with codes. A correct code next to stale text can create contradictory representations. Review both when a mapping or source decision changes.
Build a meaningful test set
Use fictional cases with one permitted value, one value outside the required list and one valid value from the wrong role. Check what the final implementation and validator report for each. This distinguishes list membership from field assignment.
Add a case with a source label that has no confirmed mapping. The mapper should request resolution or report the gap, not silently choose the nearest-looking code. A convenient default can conceal uncertainty.
Keep the expected result, actual target and configuration with the test. A file parsing successfully is not evidence that code-list or semantic rules were checked. Report the observed validation scope accurately.
Review updates and final output
When a list or profile changes, identify which mappings and tests are affected. Do not assume every existing value is removed or every new one is accepted by the recipient. Confirm the actual production requirement and implementation.
Inspect the final exported codes and schemes after source edits. An earlier report does not update itself when a value changes. Retain the exact file version with the appropriate rule-set evidence.
The current JSON, CSV and printable output can preserve supported application data but do not establish formal code-list validation or recognised format conformance. A reliable final workflow needs confirmed meanings, correct list membership, accurate field roles and implemented checks, rather than confidence based on a value looking technical.
A small code-test register can record source label, confirmed meaning, target list, selected value and evidence. Give an unresolved label an explicit pending status. Do not approve it because the adapter produced a default. The register should make a reviewer ask whether the mapping was confirmed, not merely whether a string appeared in the file. Keep the list version with the test so later updates can be checked against the same original assumption.
Record the confirmed mapping source.