How to Check the Tax Breakdown Against Individual Lines

Check a tax breakdown by tracing every group to the invoice lines that contribute to it. Confirm the category, rate, net base and relevant explanation, not only the summed tax amount. A correct-looking total can hide a line assigned to the wrong treatment or a missing reason.

The tax-information workflow separates this data review from determining tax treatment. The current creator calculates and sums rounded line contributions, but it does not generate a formally validated category breakdown for a recognised e-invoicing profile.

Build the line-to-group relationship

Use the final line list, including the supported discounts, rather than an earlier quotation total. For each row, record its confirmed treatment and the net amount entering the review. Identify unresolved classifications before trying to make the group totals balance.

Give each source row a recognisable description or working reference. A spreadsheet row position alone can become ambiguous after insertion or deletion. Keep enough context that another reviewer can trace the group back to the actual supply without guessing.

Do not group all lines merely because they show the same numerical tax result. Zero-rated, exempt and outside-scope meanings can differ. Preserve the category and its basis even where all corresponding tax amounts are zero.

Inspect group membership before addition

Compare the supplies within each group. Ask whether they share the confirmed category and relevant rate, and whether an explanation covers the entire group. A reason approved for one service should not automatically extend to every line with a similar description.

For a fictional review, imagine two separately described services assigned to one confirmed category and a third assigned elsewhere. Verify the third remains separate even if its amount happens to equal one of the others. Monetary equality does not establish shared treatment.

OpenPeppol’s published tax-category structure illustrates the separate roles of category, percentage and reason. Its grouping requirements belong to that specific profile and version. The current application’s related controls do not prove that the formal breakdown has been implemented.

Check the bases after adjustments

Use the line net values after supported discounts when comparing the current creator’s tax calculation. If the review sheet uses undiscounted amounts, the tax bases can differ before rounding is considered. Confirm the adjustment scope against the accepted agreement.

Document-level allowances or charges may require additional relationships beyond the app’s line percentage model. Do not assume the line sum alone accounts for an adjustment the creator does not implement. Keep unsupported financial requirements explicit for the final system.

If a total differs, isolate the stage. First compare group membership, then net bases, then rates and rounded tax. Changing all four at once makes the cause difficult to identify and can introduce a new error while repairing the original mismatch.

Review explanations and identifiers

Check whether each group needs reason text, a code or another field under the intended profile. The creator has supported reason text for relevant line categories but no verified exemption-code mapping. Preserve any additional requirements separately.

Confirm that the seller and buyer identifiers have not been confused with the category data. They describe parties, not the reason a particular supply has a treatment. A complete party record does not make every breakdown group valid automatically.

Use the reason-code and text comparison when a receiver asks for a coded explanation. Record the applicable list and meaning instead of placing an unexplained value in a text box and treating it as formal support.

Compare the final software output

In the standards-capable system used for delivery, inspect the actual breakdown groups and their mapped fields. Check that every intended line contributes once, every required explanation appears in the correct role and no group was added from a stale draft.

Run the validation appropriate to the format, profile and version. A schema result can address structural rules without proving the semantic grouping or the underlying tax determination. Keep the validation scope visible rather than reporting every successful check as complete compliance.

Where two systems use different rounding policies, retain that as a separate arithmetic issue. Do not change category membership to eliminate a cent difference. The treatment should remain anchored to its determination, while calculation differences need their own justified resolution.

Finally, retain the reviewed line-to-group record with the exact exported version. The current creator’s JSON, CSV and printable output support preparation but do not establish formal tax-breakdown conformance or recipient acceptance. Resolve unsupported grouping, mapping and submission requirements in an implemented final workflow before delivery.

A practical review check

A fictional group review might show lines A and C contributing net amounts of 40.00 and 60.00, while line B belongs to another treatment. The first group’s base is 100.00, but its evidence must still identify both A and C. If C is removed in a later draft, the group record must change too. Keeping the source references lets a reviewer distinguish a stale 100.00 subtotal from a newly justified allocation, instead of accepting the familiar figure because it appeared in the earlier review.