How to Organise Invoice Lines with Different Tax Rates

Organise lines with different confirmed tax treatments by recording each line’s category, rate and supporting basis before grouping amounts for review. Do not average rates or infer a treatment from a subtotal. The preparation record should show which supplies belong together and why.

The tax-information workflow separates this organisation from arithmetic. The creator allows manually selected tax information per line, but it does not decide the treatment or construct a formally validated category breakdown for a recognised standard.

Identify the treatment of each supply

Start with the accepted commercial scope and the responsible tax determination. Similar descriptions do not prove identical treatment, and different product names do not automatically require different categories. Record the confirmed basis instead of grouping by visual similarity alone.

Use a working sheet with one entry per billed supply. Include a recognisable description, source reference, net amount, category, rate and relevant reason. This is a review aid, not a substitute for the invoice or the underlying determination.

Mark unresolved rows clearly. A blank decision should not be hidden inside a group labelled “other” merely to finish the sheet. Resolve it with the appropriate reviewer before final export, especially if the line’s treatment affects the required document structure.

Separate commercial grouping from tax grouping

Commercial invoice lines describe the supplies and charging bases. A tax review group collects amounts that share the relevant confirmed treatment. These are related but different views of the same transaction. Several commercial rows may contribute to one tax group.

For a fictional example, two separately described maintenance services might share one determined category and rate, while an unrelated supply has another. Keep the commercial rows distinct if they need independent quantities or prices, then record their tax relationship in the review sheet.

Do not combine rows solely to make the tax groups shorter. Different quantities, units or discount scopes may need separate calculation bases. Similarly, do not split a fixed package into arbitrary values without a justified allocation supported by the agreement and applicable requirements.

Preserve category distinctions at equal rates

Two lines producing zero tax do not necessarily belong to the same treatment group. Zero-rated, exempt and outside-scope meanings remain distinct. Preserve the confirmed category and reason rather than grouping all zero results under one unexplained label.

OpenPeppol’s published tax-category structure shows category, percentage and reason as distinct data roles. A final mapping may need the correct relationships at the breakdown level. The current creator’s line controls do not implement that complete profile structure.

If a reason applies to only some lines, retain that scope. Copying it into every zero-tax row can create an inaccurate statement. A shared arithmetic result is not enough evidence that one explanation covers the entire invoice.

Review adjustments within the groups

Record whether unit prices already include a reduction and which supplies receive a separate discount. The creator supports percentage line discounts, which change the net base used by its current tax calculation. Keep the review sheet aligned with the final supported net amounts.

Document-level allowances, charges or allocations need their own appropriate model. The app does not distribute a global reduction across different tax groups. Do not assign an entire allowance to whichever row makes the final total easiest to reconcile.

The related guide to preparing discount evidence for tax review focuses on what the reviewer needs to know about those adjustments. Use it before asking a final mapper to infer the discount scope from one document total.

Check the handoff to formal software

Give the final software provider the confirmed groups, affected lines, reasons and any required identifiers. Identify the target format and profile. A generic request to “group VAT correctly” leaves too much meaning to be guessed from descriptions.

Review the actual structured output and required validation report in that system. A correct visible tax total does not establish that all category groups are present or that their reasons and rates are mapped correctly. The creator’s application JSON does not promise that formal representation.

If the final system uses a different calculation or rounding policy, compare intermediate values separately from category grouping. A cent difference does not justify moving a line into a different treatment. Keep the tax decision and arithmetic investigation distinct.

Retain the reviewed grouping record with the final invoice version. It should let another person trace every line into its intended tax treatment without reconstructing an internal discussion. The current app supports preparation and field checks; tax determination, formal grouping validation and acceptance remain responsibilities of the appropriate final workflow.

A practical review check

For a long invoice, a two-pass grouping review is useful. First trace every commercial line into one confirmed review group and mark it as included. Then work backwards from every group to its contributing lines. The reverse pass exposes orphan totals and stale group entries that a forward-only check may miss after a row has been removed. Keep the working references separate from any formal line identifiers the final format requires.

Record the reviewed draft identifier so the grouping can be repeated against the same line set.