The round-off row on an invoice is not a line of goods.

The invoice prints ₹2,80,000 for steel, 18% tax, ₹50,400. The total should be ₹3,30,400. But the vendor rounds the total to ₹3,30,400. The round-off row shows 0.00. No problem. Now the vendor rounds to ₹3,30,400.40 and prints a round-off row of ₹0.40. The total is a round rupee. The arithmetic still works. But OCR picks up the round-off row as a product line. The model writes 18% tax on it. Now you have ₹0.40 of goods and ₹0.07 of tax on something that is not a product. The total closes. The books are wrong.

This is the kind of error that does not announce itself. The invoice looks normal. The numbers look reasonable. Nobody checks whether 0.40 of steel is a line item or a rounding convenience. The mismatch sits in the books until reconciliation reveals it, and by then the fix takes hours instead of seconds.

The three ways this goes wrong

1. Drop the round-off row. Total is 3,30,400.40. Sum of lines is 3,30,400.00. Gap of 0.40. Closure fails. Invoice goes to review. The clerk does not know why. Fix: include round-off in the sum.

2. GST the round-off as a product. 0.40 of TMT bar at 18% gives 0.07 tax. Books now have a phantom line. At filing, the rate on the code does not match the rate on the tax. Your CA asks: where is this 0.40 of steel? There is no steel. It is a rounding convenience.

3. Round-off is too large. Vendor prints round-off of ₹50 on a ₹2,80,000 invoice. That is not rounding. That is a missing line or a wrong total. The tolerance catches it. ₹0.40 passes. ₹50 does not. The default of plus/minus 1 rupee draws that line. Your CA may set it differently. The validator does not invent a rule.

What the validator does

arithmetic.py checks three things: lines sum to taxable, taxable times rate equals tax, taxes plus taxable equals total. The tolerance is plus/minus 1 rupee. If the round-off row is in the sum and the total matches, the check passes. If the round-off row is missing and the gap is 0.40, the check fails. That is the correct failure: the printed total does not match the sum.

The round-off row is not a product. It is not a service. It is not a tax line. It is a bookkeeping convenience. Do not GST it. Do not drop it. Include it in the sum so the total closes. The CA will sort the ITC treatment.

Mixed rates

Some invoices have 18% on steel and 12% on packing. The vendor rounds the total to a round rupee. The round-off row may be 0.60 because the packing at 12% produced a paise fraction. Do not assume the round-off is 18%. The vendor decided the rounding. We include it in the sum. We do not recompute it.

What we check: taxable times rate equals tax on each line. If the vendor printed 12% on packing and the tax is 12% of the packing taxable value, the line closes. If the vendor printed 18% on packing and the tax is 12%, the line fails. We do not fix the rate. We flag the mismatch.

What the clerk should do

If the round-off row is present and the total matches, review sees the row. Confirm it is not a product. If it is round-off, leave it. If it is freight mislabelled as round-off, fix the description. If the total does not match, the invoice has a wrong total. Link totals.

If the vendor does not print a round-off row but the total is a round rupee and the sum is off by 0.37, that is still a closure failure. The vendor rounded in their head. We do not know that. We see a gap. The invoice goes to review. The clerk types 0.37 as round-off. The total closes. The books are clean.