A field check can test whether supported data is present and fits an application’s rules. It cannot establish that the selected tax treatment is appropriate for the transaction. A completed category, rate and reason can still express the wrong conclusion, even when the calculation is internally consistent.
The tax preparation workflow therefore separates determination, entry and validation. The current creator performs application-level field checks. It does not analyse the law, verify party status or certify a formal invoice profile.
Understand the question the software answers
A required-field check asks whether a value exists. A numeric rule can test the supported range or decimal precision. A category rule can require a reason for an exempt or outside-scope line. These are useful checks because they expose incomplete or unsupported inputs.
The question “is this supply correctly treated as exempt?” requires different evidence. It depends on the actual transaction and applicable requirements, not merely the existence of a sentence in the reason field. The creator does not perform that determination.
Do not interpret a green result more broadly than its label. “Field checks passed” describes the application rules tested. It is not a conclusion that the invoice is legally valid, accepted by an authority or suitable for every recipient system.
Consider a complete but incorrect line
A row can contain a recognisable description, positive quantity, supported price and an entered rate that passes all input rules. If the rate belongs to another transaction, the resulting tax is still based on the wrong decision. Arithmetic consistency cannot repair that mismatch.
Similarly, a reason field can contain a full sentence copied from another customer. A presence check sees text; it does not know whether the sentence applies. A plausible legal reference can be more misleading than an empty field if it creates unwarranted confidence.
Use the accepted records and responsible review to establish the treatment. Keep that evidence separate from the validation result so a later reviewer can tell what was determined, what was entered and what the software actually checked.
Distinguish several validation layers
Application checks address the current model. XML schema validation, where implemented by another tool, addresses structural rules for a defined syntax. Business-rule validation can address additional relationships under a specified profile. These layers have different scopes and can reveal different problems.
Even formal automated rules cannot establish every real-world fact. They may check that an identifier or category is represented in an allowed way without proving that it belongs to the transaction. The factual and professional review remains necessary.
The current creator does not generate standards XML or run those formal layers. Its JSON explicitly belongs to the application model. A structured-looking file and a passed form check should not be described as evidence that a recognised invoice standard has been satisfied.
Supply the missing evidence deliberately
Give the responsible reviewer the supply, parties, relevant dates and locations, commercial terms and any necessary identifier evidence. Record unresolved facts rather than guessing values to complete the form. The review should establish the decision before the final data is exported.
Use the accountant review checklist to organise that handoff. The useful output is a record of confirmed treatment, scope, evidence and remaining actions. It is not merely a screenshot of the creator reporting no missing fields.
Where a destination requires codes, breakdowns or other fields the app lacks, identify the final software that will express them. A note explaining the gap does not implement it. Do not present a preparation draft as complete while an essential mapping stage remains unassigned.
Review revisions at the right level
A typing correction can be checked against the existing determination. A change in the supply, customer circumstances or advice may require a new determination. Keep those events distinct instead of calling every revision a data-entry fix.
After an input changes, rerun the supported checks and review the resulting totals. A previous validation result belongs to the earlier state. Likewise, a report from an external validator should be retained with the exact file it tested, rather than assumed to cover later edits.
Before delivery, confirm which review and validation layers the actual workflow requires. The creator can help with local preparation, field completeness and supported arithmetic. Tax determination, formal profile conformance, transmission and recipient acceptance remain distinct tasks that need their own evidence and implemented process.
A practical review check
A useful negative test is a fictional exempt row whose reason contains unrelated delivery text. A presence check may accept the field because it is nonempty. A substantive reviewer should reject the explanation because it does not support the stated treatment. Keep this example separate from production records and describe the test result precisely: the application tested presence, while the reviewer assessed meaning. That distinction demonstrates why improving a required-field rule is helpful but still cannot replace transaction evidence or professional judgement. A software test should be judged against its intended scope, rather than blamed for not answering a question it was never designed to decide.
Record the exact rule tested.