Blog/GST & ITC
Default, not law

A 0.60 round-off is ordinary. A 50 round-off is suspicious. The line is 1 rupee.

Plus/minus 1 rupee is the validator default. Paisa round-off is normal. Anything larger flags the invoice. Your CA may set a different tolerance. The validator does not invent a CBIC rule.

The invoice prints ₹2,80,000 for steel, 18% tax, ₹50,400. The total should be ₹3,30,400. 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.

See round-off for the product handling. This page is the tolerance: plus/minus 1 rupee. Why not zero? Why not 5? Why not 50?

Plus/minus 1 is the default

Vendors round. Paisa round-off is normal. Plus/minus 1 lets good invoices pass review. Anything larger flags the invoice. Your CA may set a different tolerance. The validator uses plus/minus 1. Not a CBIC rule.

Tolerance draws the lineproduct default
0.60

Passes

Normal round-off

1.00

Line

Default threshold

50.00

Flags

Not round-off

Why not plus/minus 0

If the tolerance is zero, every paisa mismatch flags the invoice. Vendors round to the nearest rupee, or to 50 paise. A 0.60 mismatch on a ₹2,80,000 invoice is normal rounding. Plus/minus 0 would flag it. The clerk would review it. The clerk would confirm it. The time spent reviewing good invoices is the cost of zero tolerance.

Plus/minus 1 lets paisa round-off pass. It flags anything larger: ₹5, ₹50, ₹500. Those are suspicious. They are not rounding. They are missing lines, wrong totals, or typos. The tolerance draws the line.

Why not plus/minus 50

A ₹50 mismatch on a ₹2,80,000 invoice is 0.018%. That sounds small. But ₹50 is not rounding. It is a missing line or a wrong total. Plus/minus 50 would let real errors through. The clerk would not see them. The CA would find them at filing. The tolerance is the gate. It should catch errors, not round-offs.

The default of plus/minus 1 draws the line between "vendor rounded" and "something is wrong." Your CA may set it differently. The validator does not invent a rule. It uses plus/minus 1 as the default.

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.

Sources
  • EntryLedger
    validators/arithmetic.py

    plus/minus 1 rupee default. Configurable. Not a CBIC rule.

  • EntryLedger
    Round-off post

    How round-off rows are handled. Product default, not law.

Frequently asked questions
Legal tolerance?+

No. Product default. Configurable. CBIC circulars for rounding rules.

Why not zero?+

Paisa round-off floods review with good invoices.

Configurable?+

Yes. Your CA may set a different tolerance.

Plus/minus 1 is the default

0.60 round-off passes. 50 does not. The line is 1 rupee.