Skip to content

Document AI

Parsing Indian invoices: GSTIN, HSN and the formats that break extraction

Extraction tools trained on US and European paperwork miss the fields that matter here. What is different, and what to validate.

6 min readByteWeave Studio

Most off-the-shelf document extraction is tuned on invoices from the US and Europe. Point it at Indian paperwork and it will find the total and the date and then quietly ignore about a third of what the finance team needs, because those fields do not exist in the layouts it learned from.

None of this is difficult once you know what you are looking at. It is just that nobody writes it down, so every team discovers it in the same order.

The fields that have no Western equivalent

A GST invoice carries a supplier GSTIN and usually a buyer GSTIN: fifteen characters, where the first two are the state code, the next ten are the PAN, and the last is a check digit. Line items carry an HSN or SAC code classifying the goods or service. Tax is split into CGST and SGST for a sale within a state, or a single IGST for a sale across states, and which one appears tells you something about the transaction that the addresses may not.

A pipeline that treats tax as one number loses that. Worse, it will sometimes sum CGST and SGST into a single figure and reconcile correctly by accident, which hides the error until someone files a return against it.

Validation you get for free

Several of these fields are self-checking, which is unusual and worth exploiting. GSTIN has a defined structure and a checksum, so a misread character is detectable without any reference data. The embedded PAN can be cross-checked against a PAN field elsewhere on the document. State code should agree with the address.

This turns OCR ambiguity into a solved problem for the highest-value fields. The classic confusions — 0 against O, 5 against S, 1 against I — are exactly what a checksum catches. Run the validator, and where it fails, try the alternate reading rather than sending the field to a human.

Layout habits that trip up region detection

Indian invoices frequently carry a rubber stamp and a signature over the lower third of the page, often across the totals block. Many include an "Amount in words" line, which is a useful independent check on the numeric total and is routinely ignored. Multi-page invoices repeat the header on each page, so a naive parser can create duplicate documents from one invoice.

Bilingual layouts appear in several states, with Devanagari or a regional script alongside English. An OCR configuration restricted to Latin characters will not fail loudly on these; it will return partial text with no indication that anything was dropped.

What to build first

Start with the checksum validators, before any model work. They cost an afternoon and they immediately lift accuracy on the fields with the most downstream consequence. Then add the arithmetic checks: line items summing to taxable value, tax computed at the stated rate, and the total matching the amount in words.

Only once those are in place is it worth tuning extraction. Most of what looks like a model problem on Indian invoices turns out to be a missing validation rule, and rules are cheaper to write, easier to explain to a client, and do not need retraining when a vendor changes template.

  • Document AI
  • GST
  • India
  • OCR
  • Validation

More reading

Have a problem
worth solving?

Tell us what you're building. We'll help you figure out what's possible — and say so if we're not the right people for it.

Start a conversationSee the work