Why invoices are hard to read reliably
Indian GST invoices come in thousands of layouts: different suppliers, languages, scanned copies, phone photos, multi-page tables and handwritten stamps. Transport documents such as lorry receipts (bilties) are even less standardised. Modern layout-aware models handle much of this, but they still misread characters, merge table rows or skip a field now and then.
For accounting, an occasional error is not acceptable. A wrong digit in a GSTIN or a shifted line item ends up in your books. The fix is not only a better model. It is a layer of checks that can show an extraction is consistent before it is used.
Layer 1: check identifiers and formats
Start with the fields that have a strict structure.
- GSTIN: 15 characters. The first two digits are the state code, the next ten are the PAN, then an entity number, the letter Z and a final check character. A single misread character usually breaks the check character, so it is easy to catch.
- PAN: five letters, four digits, then one letter.
- Dates: parse to a real date and check that it falls in a plausible financial year (April to March).
- Invoice numbers: check length and character rules per supplier where you know them.
Layer 2: check the tax logic
GST has rules that an extraction can be checked against.
- Place of supply decides the tax split. For a supply within one state, tax is split into CGST and SGST. For a supply between states, it is IGST. The state codes in the GSTINs help confirm which one applies.
- Tax amount should equal the taxable value multiplied by the rate, within a small rounding tolerance.
- CGST and SGST amounts on a line should be equal.
- The rate on a line should be a valid rate for that kind of item.
Layer 3: reconcile the totals
- Quantity times rate, minus discount, should match each line amount.
- Line amounts should add up to the taxable value.
- Tax on the lines should add up to the tax totals.
- Taxable value plus taxes, plus or minus round-off, should equal the grand total.
When every check passes, the invoice is internally consistent. That is much stronger evidence than a model's confidence score.
Route by validation, not by confidence alone
Use three outcomes for every document:
- All checks pass: post automatically and generate the voucher XML that Tally imports.
- A check fails: send it to a review queue with the failing field highlighted.
- The document is unreadable: reject it and ask for a better copy.
Where we use this
This is the approach behind our GST document AI work: fine-tuned extraction, a deterministic validation layer, and Tally Prime XML export, delivered as containers you own.