The total on the invoice does not add up from the line items. Here is what to check.

You receive an invoice. The line items add up to ₹47,280. The tax is ₹8,510.40. The total says ₹55,800. The math does not work. ₹47,280 + ₹8,510.40 = ₹55,790.40, not ₹55,800. The invoice carries a wrong total.

If that invoice reaches Tally, you post ₹55,800. Your books say you owe ₹55,800. Your supplier's books say ₹55,790.40. At filing time, the numbers do not reconcile. Someone spends an hour tracing the ₹9.60 difference. The difference is small. The time to find it is not.

This is the kind of error that does not announce itself. The invoice looks normal. The numbers look reasonable. Nobody checks whether they actually add up. The mismatch sits in the books until reconciliation reveals it, and by then the fix takes hours instead of seconds.

Four reasons the math does not work

Vendor typos happen. Someone calculates the total by hand, or uses a calculator, and presses the wrong button. The result is a total that is close to correct but not exact. On a ₹50,000 invoice, a ₹10 or ₹20 error is easy to miss. But it is there, and it shows up at reconciliation.

Round-off is also common. Some vendors round to the nearest rupee. Some round to 50 paise. The total on the invoice might be ₹55,800 when the exact amount is ₹55,799.40. This is normal and not an error. But the round-off must be within a reasonable tolerance. A ₹50 round-off on a ₹50,000 invoice is suspicious. A ₹0.60 round-off is not.

The missing line happens when a vendor forgets to include a line item in the total. Maybe there is a freight charge that was added to the invoice but not to the total. Maybe there is a discount that was subtracted from the lines but not from the total. The math does not work because a line is missing from the calculation.

The rate confusion happens when the GST rate changes mid-year. A vendor might use 18% on some lines and 12% on others, but the total assumes a single rate. Or the vendor might use the old rate on a new invoice. The tax amounts do not match the rates, and the total does not match the tax.

The three closure checks

EntryLedger runs three arithmetic checks on every invoice:

1. Lines sum to taxable. Add up all line item amounts. They should equal the taxable value. Tolerance: ±₹1. If the lines add up to ₹47,280 but the taxable value says ₹47,300, there is a mismatch. The ₹20 difference might be a missing line or a typo.

2. Taxable times rate equals tax. Multiply taxable value by the GST rate. The result should equal the tax amount. Tolerance: ±₹1. If taxable is ₹47,280 and the rate is 18%, the tax should be ₹8,510.40. If the invoice says ₹8,520, there is a mismatch. The ₹9.60 difference might be a rate confusion or a typo.

3. Taxes sum to total. CGST + SGST (or IGST) should equal the total tax. Total tax plus taxable should equal the invoice total. Tolerance: ±₹1. If taxable is ₹47,280 and tax is ₹8,510.40, the total should be ₹55,790.40. If the invoice says ₹55,800, there is a mismatch. The ₹9.60 difference is the error.

If any check fails, the invoice goes to review. The scan is there. The reason is there. A person confirms or corrects it in seconds. The wrong number never gets a chance to sit in your books for three months and surface during reconciliation.

Why ±₹1 and not ₹0

Vendors round. Some round to the nearest rupee. Some round to 50 paise. A ₹0.60 round-off is normal and does not indicate an error. EntryLedger allows ±₹1 to account for this. Anything larger flags the invoice for review.

The tolerance is configurable. If your vendors do not round (everything is exact to the paise), you can set the tolerance to ₹0. If your vendors round aggressively (to the nearest 10 rupees), you can increase the tolerance. The default of ±₹1 works for most Indian manufacturing invoices.

The tolerance is the line you draw. ₹0.60 of printed round-off is ordinary. ₹50 wants a look. EntryLedger’s default is ±₹1 because that is what the validator uses. Do not treat a blog example as a CBIC rule.

What this looks like in practice

An invoice comes in as a photocopy. The line items are extracted. The taxable value is calculated. The tax is calculated. The total is calculated. Then EntryLedger compares the calculated total against the printed total. If they differ by more than ₹1, the invoice goes to review.

The scan is there. The reason is there. The person reviewing can see the line items, the calculated total, and the printed total side by side. They can see exactly where the error is. They fix it in seconds. The wrong total never reaches Tally.

This is the difference between arithmetic closure and a format check. A format check asks: does this look like an invoice? Arithmetic closure asks: do the numbers add up? One is a filter. The other is a proof. The proof catches errors that the filter misses.

Indian amounts make this easier to get wrong

You will see Rs. 1,00,000/- and 1,23,456.78 on the same desk. Lakh grouping is not US grouping. If your parser strips all commas, you turn 1,00,000 into 100000 (fine) or you turn a European-style 123,09 into 12309 (not fine). EntryLedger’s amount parser has to accept both styles. If you build this yourself, test lakh grouping or you will invent mismatches that were never on the paper.

Round-off lines are another trap. Some vendors print a “round off” row of ₹0.37 so the total is a round rupee. That row is not a product. It still has to sit in the arithmetic. If you drop it, the total fails. If you treat it as taxable at the line GST rate, the tax fails. The closure check should allow a small round-off bucket, not pretend every paise is a line of steel.

CGST + SGST must equal the intra-state tax. People fat-finger one of the two. The grand total can still look right if they padded the other. Check both legs, not only the sum. IGST invoices should not also carry CGST. That is regime plus arithmetic. Fail closed.

When the printed total is wrong on the paper itself, the gate should not “fix” it into Tally. That is the vendor’s document. Review, call, credit note. Auto-exporting a corrected total you invented is how you create a second set of books. Block. Show the scan. Let a human decide whether to post the printed number or wait.

If you are still keying by hand, add one habit: after you type the total, add the lines with a calculator. Ten seconds. Catches the ₹9.60. If that sounds tedious at volume, that tedium is the product. Software should do the add. A person should only see the ones that fail.