Give your accountant or responsible tax reviewer a clear record of the transaction, proposed treatment and unresolved questions. Include the supporting evidence and explain what the current creator can and cannot represent. A screenshot of a balanced total is not enough to review the underlying tax decision.
Use this checklist at the end of the tax-information preparation workflow. The aim is a documented decision and a concrete finalisation plan. The creator performs supported calculations and field checks locally; it does not provide tax advice or certify the resulting invoice.
Describe the transaction being reviewed
Identify the seller, buyer, goods or services and the relevant dates and locations. Provide the accepted agreement, order or approved delivery record. Do not reduce the brief to a product name and a desired tax rate, since important circumstances may be missing.
Explain whether the draft covers a complete supply, recurring period, partial delivery or another agreed stage. Keep that description consistent with the invoice lines. A broad project narrative may not identify the scope of the particular charge being reviewed.
List any changes from the previous transaction or draft. A different customer entity, revised scope or new commercial arrangement may mean earlier advice should not be carried forward automatically. Mark assumptions as assumptions rather than presenting them as confirmed facts.
Confirm the parties and identifiers
Provide seller and buyer names, addresses and relevant identifiers with their roles and sources. Keep tax numbers distinct from company registrations, purchase-order numbers and electronic delivery identifiers. Resolve obvious record conflicts before asking the reviewer to approve the final data.
Include any relevant official verification evidence with its date and scope. The creator does not perform registry or ownership checks. A previous invoice or customer email is not the same evidence as a current official query result.
If a required identifier is missing, state the issue directly and ask what is needed for this transaction. Do not invent a value or copy the other party’s identifier into the gap merely to make the preparation record appear complete.
Review each treatment and explanation
For each distinct supply, record the proposed or confirmed category and rate, and identify who established it. Ask the reviewer to confirm the scope of the conclusion. Different rows producing zero tax may still represent different treatments.
Where a reason is needed, provide the proposed customer-facing wording and its source. Ask whether the final workflow also requires a code, specific reference or additional field. The current text reason is not a verified formal exemption-code mapping.
Use the capability-gap checklist to make unsupported scenarios visible. Reverse charge, formal category breakdowns and other requirements should not be disguised as ordinary zero-rate entries simply because the preview’s arithmetic looks similar.
Explain discounts and other adjustments
Supply the accepted basis for discounts, allowances, charges and prior payments. Distinguish an already reduced price from a separate concession, a percentage from a fixed amount and a line adjustment from a document-wide one.
The current app supports percentage discounts per line only. It does not implement document-level allowance allocation, withholding, prepaid reconciliation or credit notes. If the transaction needs those features, identify the final system that will represent them accurately.
Keep the source terms available so the reviewer can see which amounts and supplies are affected. Do not ask them to infer the adjustment scope from a final balance that has already been manipulated through unrelated fields.
Check the required delivery model
State what the recipient actually requests: readable output, a particular structured format, a named profile or a submission route. Include the version and technical instructions where supplied. Preparation, formal mapping, validation and delivery are separate stages.
The creator exports its own JSON, line-item CSV and printable output. It does not create recognised standards XML or submit through Peppol or government systems. A country choice or a format name in notes does not add those capabilities.
If another provider will finalise the invoice, give them the confirmed treatment record and unsupported-field list. Identify who reviews the mapped output and retains the formal validation report. Do not leave the final stage as an unassigned expectation.
Record decisions and next actions
After review, distinguish confirmed facts, corrected entries and open questions. Keep the conclusion’s scope and any required follow-up. A useful review record should let someone explain why the final values were chosen without reconstructing a conversation.
You can revise the supported invoice fields once those decisions are available, then validate and export a fresh version. Recheck written notes for old figures and keep earlier downloads distinguishable from the intended final file.
Retain the decision record, source evidence and exact final output under your business process. A reviewed preparation draft is useful, but it is not automatically a formally valid standards document or evidence of recipient acceptance. Complete the identified mapping, validation and delivery requirements in the appropriate implemented workflow before treating the invoice as finished.
A practical review check
Ask the reviewer to distinguish approval of the tax determination from approval of the final file. Those may occur at different stages and require different evidence.