Exemption text explains a treatment in words. An exemption code identifies a reason using a defined list within a particular structured workflow. A sentence and a code can relate to the same determination, but they are not interchangeable fields. Confirm which representation the final destination requires.
The tax preparation workflow preserves that requirement before export. The current creator supports a text reason for relevant line categories. It does not supply an exemption-code list, map a typed code into a standards format or validate that a code applies to the transaction.
Establish what the recipient means by code
Ask for the actual format, profile and field requirement. “Use an exemption code” is incomplete if it does not identify the list or intended context. A software package’s internal shorthand may differ from a published code required in the transmitted document.
Record the list name, expected value and meaning supplied by the responsible source. Keep a reference to the relevant current documentation. Do not choose an identifier by searching for a phrase that merely sounds similar to your business situation.
A code can be syntactically acceptable and still represent the wrong basis. List membership is a technical check, while applicability depends on the confirmed transaction. Preserve both pieces of evidence instead of treating one as proof of the other.
Keep the explanation independently understandable
Reason text should express the confirmed basis accurately and concisely. A reader may need to understand the treatment without consulting a code list. Avoid copying long internal advice or confidential correspondence into the customer-facing field.
If the final workflow requires both code and text, check that they agree. A correct code beside a stale explanation creates a contradiction. Conversely, a good explanation does not repair a code that identifies another reason.
OpenPeppol’s published tax-category structure illustrates separate exemption-code and exemption-text elements. That example shows why preserving the roles matters. It does not imply that every profile has identical requirements or that the current creator produces those elements.
Avoid code-shaped text workarounds
Typing a recognised code into the creator’s reason text box stores text in its application model. It does not create a formally typed reason-code field. The export remains the application’s own JSON or line-item CSV, and the printable preview remains a readable document.
Do not add an XML-looking tag around a code in the description. That does not change the data model or create a valid standards document. The current app escapes preview text rather than executing it as markup, which is appropriate for safe display but unrelated to formal mapping.
Likewise, putting the list name and code in one sentence can help a working record but does not establish the structural location a receiver expects. Preserve required mapping facts separately for software that implements the destination format.
Build a small mapping record
For each confirmed reason, record the affected supply, determined treatment, approved text, code if required and source of the mapping. Include the target profile and version. This makes the handoff reviewable without asking the final software provider to infer meaning from an unexplained string.
If the same reason covers several lines, retain the scope explicitly. Do not assume that one code applies globally because the document tax total is zero. Different supplies or circumstances may need separate determinations or a different category-level representation.
Use the reason-preparation review to check the underlying wording and evidence. The mapping record should preserve a reviewed decision, not create a new tax conclusion merely because a destination code list offers a convenient option.
Test the final representation
In the standards-capable final system, inspect the actual exported code and text fields. Confirm the list requirement and run the validation appropriate to the intended version and profile. A successful schema check alone may not test the semantic applicability of the reason.
Use fictional data when testing the integration itself. Create cases with required text missing, an unsupported code and mismatched text/code meanings, then verify what the implemented validator actually reports. Do not send real customer files to an unknown online validator to discover whether a code works.
Keep the resulting report with the exact tested version. A later edit can change the reason or category and invalidate the earlier review. A report about a previous file is not evidence that the current export still contains the same values.
The creator can help prepare and review supported text locally, but it cannot certify the coded mapping, legal treatment or recipient acceptance. Complete those requirements through the appropriate reviewer and implemented final workflow. Clear separation between words, codes and validation prevents an informative explanation from being mistaken for formal standards support.
A practical review check
A simple test record can hold a fictional code value and its separate readable explanation, clearly marked as demonstration data rather than a real exemption. Pass it through the proposed final exporter and inspect whether both values appear in their intended roles. This checks the mapping mechanism without asserting that the fictional reason applies to a customer transaction.