Human-Readable Preview vs Machine-Readable Invoice Data

A human-readable preview helps someone inspect the invoice visually. Machine-readable invoice data gives values explicit roles in a model software can process. A good preview is valuable, but it is not evidence that every required structured field exists or that the export follows a recognised format.

The format-selection workflow treats presentation and processing as related requirements. The current creator has a live preview and application-owned structured JSON. It does not provide formal standards mapping or validation simply because those two views use the same entered data.

Use the preview for what it shows

Read the seller, customer, supplied scope, dates, amounts and payment text as the recipient will see them. Check long descriptions and contradictory notes. The preview can expose obvious errors that are difficult to notice while editing isolated fields.

A clear layout also helps reviewers connect amounts with the intended lines. Inspect it at a realistic screen width and use browser print preview if printable output is intended. Do not assume a wide editor and a printed page wrap identically.

Keep the review evidence scoped to the visible document. A screenshot can show that a value appeared on screen, but it does not establish its formal structured role or whether another export contains the same information.

Inspect the actual data separately

For application JSON, check the supported fields and their documented meanings. For a formal format produced by another system, inspect the mapped values and required validation report. A familiar label in the preview is not proof of the corresponding target field.

For example, an address may display as one readable block while the destination expects separate components. A reference may appear clearly on the page but belong to the wrong semantic role. Both can look plausible without being suitable for automated processing.

The Commission’s model-and-binding guidance explains why meaning and representation need an implemented relationship. Do not treat any structured-looking serialisation as a verified binding merely because the invoice facts are recognisable to a reader.

Check consistency using one source record

Compare both representations with the accepted business facts rather than checking one against the other alone. If the same wrong buyer identifier appears in the preview and export, the views agree but the invoice is still wrong.

Use the accepted order, approved service record and confirmed party and payment details as appropriate. Preserve the review scope so a later colleague can tell which facts were verified and which remain unresolved.

For a fictional test, give the buyer reference and payment reference distinct values. Check where each appears visually and in data. If a mapper exchanges them, a total comparison will not reveal the mistake. Role-level checking is necessary alongside amount reconciliation.

Recognise hybrid requirements

A hybrid invoice can combine a readable view and structured payload under a particular specification. That creates additional implementation and consistency requirements. It does not mean any printable invoice plus a separate JSON file is a recognised hybrid format.

The related Factur-X explanation covers one such format family. The creator’s browser print output does not embed invoice XML or implement its packaging. Keep current presentation capability separate from educational discussion of future adapters.

If the receiver requires a hybrid, use a suitable exporter and inspect both components. A reader seeing the correct page should not be asked to assume the embedded values are correct without the relevant review and validation.

Review edits and export timing

The preview updates from supported workspace edits, but an already downloaded file does not. After changing a name, quantity or reference, generate a fresh output before comparing the final versions. Otherwise you may be reviewing different states of the invoice.

Free text also needs a separate pass. Numeric totals can recalculate while a sentence in notes retains an old amount. Machine-readable arithmetic does not automatically make every human-readable statement consistent.

Keep the intended final output identifiable. A validation report belongs to the exact file tested, not a later revision sharing the same convenient name. Repeat affected checks after meaningful changes to source values or mapping configuration.

Match the recipient’s actual needs

Some recipients need a readable document, others a particular structured format, and some need both under defined rules. Confirm the requirement rather than deciding from appearance alone. A strong preview cannot substitute for absent data fields or a required delivery integration.

The creator’s supported outputs are printable output, application JSON and line-item CSV. They can help preparation within their scope but do not establish recognised standards conformance, tax correctness or acceptance. Complete any formal mapping, validation and transmission in an implemented workflow.

A useful review record names the source facts, visible version, data version and checks performed. This lets another person distinguish presentation quality, data accuracy and technical validity without treating any one of them as proof of all the others.

For a revision test, change a fictional buyer reference after downloading the first JSON file. Compare the current preview with the old download, then export again. The exercise demonstrates that a live workspace view and an existing file can represent different states even though both are technically readable.