Prepare invoice tax information by separating the treatment decision from the values needed to express it. Confirm the transaction facts and applicable treatment first, then record the category, rate, identifiers and any required explanation. An invoice creator can calculate from those inputs without being able to determine whether the inputs describe the correct tax treatment.
The current tool lets you prepare an invoice locally, enter manual line tax information and review calculated amounts. It does not apply a country’s tax rules, verify registrations, implement reverse-charge mapping or formally validate an e-invoicing standard. Use the following workflow to organise confirmed information and identify what needs a qualified review or another system.
Build a transaction record before choosing a rate
Start with who supplied what, who received it and the agreed commercial scope. Retain the relevant dates, locations and supporting records. These facts may affect the eventual tax determination, but the creator does not analyse them or infer a category from a description.
Avoid copying the treatment from a previous invoice just because the customer name is familiar. The supply, customer status or applicable circumstances may differ. Likewise, a rate shown in fictional demo data is an arithmetic example, not an official recommendation for your business.
Record unresolved questions explicitly. If you do not know whether the customer identifier is relevant or which explanation is needed, ask the person responsible for the tax determination. An incomplete preparation record is easier to correct than a confident invoice whose tax basis was assumed without evidence.
Separate category, rate and reason
A category describes the treatment being represented, while a rate supplies a percentage where applicable. A reason explains the basis when required. These values have different roles. A zero percentage alone does not tell a reader or a receiving system why no tax has been added.
The guide to tax categories and rates explains this distinction. In the current creator, standard is a manually supplied rate; zero, exempt and outside-scope categories calculate zero tax. Exempt and outside-scope lines require a reason to pass the app’s field rules. Those rules do not establish the correct legal treatment.
Formal profiles may require specific codes and relationships between category, rate and explanation. OpenPeppol’s published tax-category structure illustrates separate category, rate, reason-code and reason-text roles. The creator does not implement that full mapping merely because its interface has related labels.
Preserve the evidence behind an explanation
When a reason is needed, retain the actual determination and its source. Do not invent statutory wording from memory or copy an explanation from an unrelated sample. A short phrase can look convincing while referring to a different transaction or a different basis for not charging tax.
Use the exemption-reason review process to connect the wording with the confirmed facts. If a required structured format expects a code as well as or instead of text, record that requirement separately. The current text field does not validate a formal exemption code list.
Keep advice and confidential correspondence outside the customer-facing description unless it is appropriate to disclose them. Your working record may need a fuller explanation than the invoice itself. Preserve the connection without copying internal discussion or personal information into a document that may circulate through several departments.
Check the parties’ identifier roles
Collect the seller’s and buyer’s tax identifiers separately, with their confirmed roles and source. Do not use an organisation’s registration number as a tax identifier simply because it appears on a business record. Similarly, one party’s identifier cannot substitute for the other’s.
Where a registry check is relevant, use the appropriate official process and retain the result with its date and scope. A successful lookup does not establish every fact about a business or decide the transaction’s treatment. The current creator neither performs that lookup nor verifies that an entered identifier belongs to the named party.
Review the names and addresses alongside identifiers to catch obvious record conflicts. Resolve differences with the relevant party or adviser rather than silently choosing whichever version is shortest. The app can preserve entered strings, but it cannot determine which business record is authoritative.
Organise the lines for the determined treatments
Keep separately determined treatments distinguishable in the line structure. One current row has one category and rate. A description stating that part of a combined amount is exempt does not make the calculation divide that row into several tax bases.
Use the tax-rate organisation workflow to group the preparation record for review. The financial allocation must reflect the actual agreement and relevant requirements. Do not invent proportions or average rates merely to simplify the preview.
Discounts also need a clear basis. Record what was reduced, the adjustment level and whether the source price already includes the reduction. The current calculation supports percentage discounts per line. Document-level allowances, fixed adjustments and other financial structures may require a more capable final invoicing system.
Review the tax breakdown as structured information
A review should show which net amounts belong to each determined treatment and how the corresponding tax was calculated. The creator sums its rounded line contributions, which is useful for checking current application arithmetic. That does not establish a formal profile’s complete tax-breakdown representation.
Compare the line-level evidence with the preview and any later mapped output. A missing category, reason or identifier can be hidden by a correct-looking total. Conversely, a cent difference can originate in rounding policy rather than a different tax decision. Keep those questions separate during investigation.
If the destination needs tax accounting currency, specific exemption codes, reverse-charge fields or another unsupported structure, mark the requirement before export. A note naming the requirement does not implement it. Use verified software to complete the mapping and the validation required by the destination.
Correct data-entry errors without changing the decision
After a treatment has been confirmed, inspect the entered percentage carefully. A missing decimal point can turn 7.50 into 75.00, while a copied row may keep a previous service’s rate. Review every edited line, then recalculate the document and check any stale figures in notes.
A correction to a mistyped value should be traceable to the original determination. If the underlying treatment itself has changed, obtain and retain the revised basis instead of calling it a simple typing correction. Post-issue corrections may also require a separate process beyond editing a local draft.
Run the creator’s field validation before a supported final export. It checks current application rules, not tax law, formal standards or recipient acceptance. Its printable document, application JSON and line-item CSV remain those output types regardless of the country context or wording entered in a reason field.
Finish with an accountable handoff
Before final delivery, use the accountant review checklist to identify confirmed facts, unresolved questions and unsupported requirements. Assign who will resolve each remaining item and which system will produce any required formal document. Retain the reviewed version rather than relying on an earlier draft.
The practical result is a tax-data record whose values and limits are understandable. It should let the responsible reviewer trace each decision, and let the final software express the required fields without guessing. The creator can support preparation and arithmetic, while determination, formal mapping and submission remain distinct responsibilities.
A practical review check
A compact review packet can contain four sections: transaction evidence, party records, line-treatment decisions and final-format requirements. Put the exact draft version at the top and assign a person to each open action. This organisation lets the accountant review the determination while the software provider reviews representation, without either mistaking a complete-looking preview for evidence that the other’s work has already happened.