A tax scenario exceeds the current creator when it requires a treatment, calculation or structured field the app does not implement. Recognise that gap before export rather than forcing the transaction into a superficially similar category. A matching visible total does not make an unsupported model accurate.

The tax-information workflow uses the creator for supported preparation and field checks. It does not turn its country context, reason text or application JSON into a verified country profile, formal tax validator or submission integration.

Check whether the treatment is represented

The current line choices are standard, zero, exempt and outside scope in the application’s own model. Standard uses a manually entered supported rate, while the other choices calculate zero. Exempt and outside-scope require a reason for field checks.

A treatment needing its own semantic category and formal relationships cannot be assumed to fit one of those choices. Reverse charge is one example of a dedicated workflow the creator does not implement. An ordinary zero result does not express the entire requirement.

Do not select whichever category gets past validation fastest. Record the confirmed treatment and what is missing. The responsible reviewer and final software provider should be able to see that the limitation concerns representation, not simply an unfinished text field.

Check financial adjustments

The creator supports percentage discounts per line, rounded within its stated sequence. It does not provide fixed-amount discount fields, document-level allowances or charges, withholding or prepaid reconciliation. Transactions needing those features require an appropriate financial model.

A note does not change totals. A negative row is outside the ordinary positive-invoice model, and reducing a unit price to simulate a payment changes the commercial statement. Avoid workarounds that hide an adjustment inside an unrelated field.

For a fictional example, a contract might contain a fixed concession and a prior payment. Those are different facts with different roles. Entering a percentage until the preview shows the expected balance would not preserve either fact reliably.

Check precision and currency requirements

Supported quantities have up to four decimal places, prices up to two and percentages up to two. A required value beyond those limits cannot be preserved by writing additional digits in the description. The calculation uses the numeric field’s supported value.

The current currencies use the app’s two-decimal money model. There is no exchange-rate conversion or separate tax accounting currency. Changing a currency label does not convert amounts or satisfy a second-currency tax requirement.

If an alternative unit basis is proposed, verify that it preserves the commercial meaning and required precision. Do not alter supplied quantities solely to compensate for an unsupported rate. A numerically matching amount can still describe the wrong transaction.

Check structured tax data

A destination may require exemption codes, tax-category breakdowns or other typed relationships beyond the current line controls. Preserve those requirements separately. A string containing several labelled facts does not create the corresponding formal fields.

The related guide to reason text and codes explains one specific gap. OpenPeppol’s category documentation illustrates defined fields, but the creator does not implement that profile simply by using related words in the interface.

If formal validation is required, identify the exact format, profile, version and validator configuration. The app’s required-field checks are not XML schema or semantic business-rule validation. A passed local check cannot prove conformity to a model that has not been mapped.

Plan a complete handoff

Keep the supported source facts and unsupported requirements in one reviewable working record. State which values are confirmed, which questions remain and which final system will implement the missing capability. Assign responsibility rather than leaving an unexplained note for the next person.

You can use the creator’s application JSON as preparation data within its documented model, but it is not a ready-made standards adapter. A receiving process needs explicit mapping and recalculation checks. Unknown fields added by another system are not automatically supported on import.

Use fictional records for testing a proposed integration. Verify positive and negative cases, inspect the actual exported fields and retain the validation evidence. Do not mistake a demonstration file passing one technical check for a complete production tax workflow.

Before delivery, review the final software’s capabilities against the identified gaps. The current printable output, JSON and CSV remain useful preparation outputs, but they do not provide tax determination, formal standards conformance, authority acceptance or transmission. A clear decision to use an appropriate final tool is more accurate than exporting a document that only appears complete because unsupported facts were hidden in notes.

A practical review check

Create a capability table with columns for requirement, supported field or adapter, missing behaviour and final owner. For example, a separate tax accounting currency would have no current field or calculation adapter and should name the final system responsible. This record is more actionable than a general note saying the invoice needs extra checking. It also gives future product development a concrete gap to implement and verify without changing current capability claims prematurely.

Give each gap an explicit completion check.