Application JSON vs a Recognised E-Invoice Format

Application JSON stores invoice data according to the application’s own schema. A recognised e-invoice format has its own defined meanings, structures and rules. A JSON export can be useful structured data without being a verified implementation of the format a customer requires.

The format-selection workflow checks this distinction before export. The current creator uses invoice-workspace/1 for supported application data and explicitly records that standards validation has not been performed. It does not export EN 16931, XRechnung, Factur-X or Peppol documents.

Understand what the JSON preserves

The creator’s JSON can preserve supported invoice fields for review and continued editing. Its own import process accepts the documented application structure, filters recognised fields and recalculates supported totals rather than trusting supplied amounts.

That makes the file useful within the application’s workflow. It does not mean every field needed by another format exists, or that another accounting system can interpret the values without an adapter. A structured object can still contain an ambiguous reference or lack a required typed identifier.

Keep editable draft data distinct from a validated final export. The app permits an incomplete draft download for later work, while supported final exports require its field checks. Neither status establishes formal standards conformance; they describe different stages within the application.

Recognise schema ownership

A schema explains the expected organisation and meaning of data within a particular model. A receiving system needs to know which schema it is reading. The generic extension json does not identify a universally accepted invoice contract.

For example, a field named reference could mean a buyer reference, purchase-order number or remittance reference in different systems. Copying the string without its intended role can produce a technically readable but semantically wrong transfer.

Likewise, the creator’s multiline address is not automatically equivalent to a target’s separate street, city, postal zone and country-code fields. Preserve source components when a final mapping needs them rather than assuming another system can extract them reliably.

Identify missing destination facts

Confirm the recipient’s required format, profile and version. Compare those requirements with the current application model. Typed endpoints, exemption codes, line periods, price-base quantities or other fields may need collecting outside the editor.

A converter cannot recover facts that were never supplied. Do not invent an identifier or reason merely because a target field is mandatory. Record the gap, obtain the confirmed value and use a mapper that knows the intended destination role.

The current product’s country selection is context metadata, not a country-compliance adapter. Its JSON remains the same kind of application output regardless of the selected country. A German buyer does not turn the file into an XRechnung.

Treat conversion as implementation

A real adapter needs field definitions, transformations, code-list handling and supported calculation behaviour. It must account for values the source cannot represent and validate the resulting target document where required. Renaming keys to XML-looking names is not enough.

Use the conversion review checklist before relying on a transfer tool. Establish whether it preserves the intended meanings and reports unsupported data rather than silently dropping it. Compare the actual result with the confirmed source record.

If the target needs a financial model beyond this app, such as document allowances or prepaid reconciliation, a simple field copy is insufficient. Use final software that implements the required model instead of hiding adjustments in notes or changing commercial prices.

Test a representative transfer

Use fictional data containing the kinds of references, quantities, categories and payment instructions your real workflow needs. Include at least one supported boundary case and one known unsupported requirement. Check whether the adapter reports the gap clearly.

For a fictional address example, preserve a street, city and postal code in the preparation record, then compare their mapped target fields with the source. A correct-looking combined address on screen does not prove those components landed in the right locations.

For a reference example, give buyer routing and payment matching distinct demonstration values. If both appear in one target field, the transfer has lost meaning even if every character survived. This kind of test checks roles rather than only whether a file can be opened.

Keep privacy and final validation explicit

The creator prepares and exports supported data locally, but a JSON file can contain customer, address and payment information. Protect downloaded files and do not upload real data to an unfamiliar converter merely to see whether it works.

After mapping, inspect the exact target document and required validation report. Keep its format, version, configuration and file identity together. A report about the source JSON or an earlier target version does not establish the final file’s status.

Application JSON is a useful preparation and editing format within its scope. It is not a formal invoice standard simply because machines can read it. Choose an implemented destination format when required, and keep mapping, validation, delivery and recipient acceptance as separate steps with their own evidence.

Before a handoff, label the file as application-owned invoice data and include its schema identifier. That small instruction helps prevent a recipient from assuming it is an already validated standard invoice.