HSN/SAC code extraction from invoices

Every line on a GST invoice carries a classification. Goods get an HSN code, services get a SAC code, and that code decides how the line’s tax is treated, so a wrong or missing code makes the whole line read wrong, in the invoice, in your purchase register, and in everything built from it later. HSN codes run four, six, or eight digits, SAC codes six, and on a multi-line invoice there is a code per line, each one needing to be matched to its description, quantity, and value. Dynamite Docs reads the classification off every line and hands it back as clean, confidence-scored rows: code, line, description, and amount together.

Try this workflow free or view pricing.

The classification is where line-level errors hide

Every line carries a code that decides its tax treatment, so the invoice’s correctness starts with the HSN or SAC. A mistyped or missing code takes the whole line’s tax with it.
Multi-line invoices carry one code per line, and each code has to be captured, matched to its own description and quantity, and kept in the right order. Single-line invoices shrink the risk to one cell, but the cell is rarely where a column reader looks.
Layouts don’t make it easy. Some print the code inside the description cell, jammed in as HSN:4820 or “4820” next to the item name, so a straight column read misses it entirely.
Codes also disagree with their own invoices. The printed code says one thing and the description another, and someone has to notice the mismatch and decide which is right before the line reaches the books.

How the codes get off the page

01 — Drop the batch in

Upload goods invoices, service invoices, multi-line purchase bills, or a folder of scanned bills. Digital PDFs parse deterministically from their text layer; scans and photos are read by the vision model you choose.

02 — Codes matched line by line

HSN and SAC codes are read per line and kept with their description, quantity, rate, and taxable value. No template library to build for every billing software, and no manual mapping of code positions.

03 — Review by confidence

Low-confidence codes surface first. Code-vs-description mismatches are flagged for a human decision, and every correction becomes a pattern the next batch from the same vendor reuses.

04 — Export and check

Codes come out as their own column in Excel, CSV, or JSON, or as rows in Google Sheets, ready for your purchase register, for entry into Tally, or for reconciliation against the returns your CA prepares.

Document types this workflow handles

Goods invoices — one HSN code per line, 4/6/8-digit
Service invoices — six-digit SAC codes per line
Multi-line purchase bills — a classification for every line
Credit / debit notes — corrections to code and tax

What gets extracted per line

The classification fields land per line, each confidence-scored and matched to the item it belongs to:

HSN code (goods) — 4820
HSN code (6-digit) — 482020
SAC code (service) — 9965
Code type — goods / service
Item description — A4 copier paper (80 GSM)
Quantity & unit — 40 reams
Taxable value (per line) — ₹24,000.00
Matched line — Line 1 of 3

A realistic example

A multi-line invoice extracts to rows like these, with the classification and its line kept together:

Line	Item	HSN/SAC	Qty	Rate	Taxable value
1	A4 copier paper (80 GSM)	4820	40 reams	9%	₹24,000
2	Rotary hammer	8467	6	18%	₹1,86,000
3	Freight (GTA)	9965	1	5%	₹12,000

The small print of classification extraction

The digits mean something. A four-digit HSN groups a class of goods, and the six- and eight-digit codes narrow it down; SAC codes are six digits and work the same way for services. You don’t need to know the taxonomy to use it — the invoice prints the code, and Dynamite Docs reads what’s printed. What matters is that the code you capture matches the code the vendor printed, digit for digit, because that is the value that gets compared and reconciled. Anything the model infers rather than sees clearly is marked low-confidence for your review.

The layouts are the real enemy. A code can sit in its own column, share the cell with a description, appear once in a line-item table header, or be printed only on the summary. The same vendor can change layout between financial years, and two vendors with the same billing software can print differently. Per-layout inference handles that: the code is found where the layout puts it, not where a template expects it.

Code-vs-description mismatches are worth a deliberate pass. When the printed code and the item name disagree, the invoice is telling you something has gone wrong before it reaches your books. Dynamite Docs flags the pair for a human call, and the decision, once made, is remembered for the next time the same pattern appears.

Tax rates and classifications change, and invoices and the returns built from them must match what applies on the date of supply. Keep codes accurate at capture, and confirm current classification and rates with your tax advisor or the GST portal, as the rules stand for your period.

Why bring-your-own-AI matters for classification

Line-item classification on scanned invoices is vision work, and the model that does it should be your choice: bring your own key from Gemini, Mistral, OpenAI, Anthropic, Groq, Cloudflare, OpenRouter, or a local Ollama, and pay your provider’s rate with zero markup. On Pro and Ultra, that processing is unlimited.

Clean digital invoices, including most billing-software and Tally exports, parse deterministically for free, identical results every run. Scans and photos are read by the vision model you pick, so quality and per-page cost are yours on exactly the documents where classification is genuinely hard.

The code-versus-description decision, the judgment call when the printed code and the item name disagree, is a human one, and once made it is remembered for the next batch from the same vendor. The codes export as their own columns, and the classified rows stay yours.

Questions, answered

Does it extract a different HSN or SAC code for every line?

Yes. Codes are read per line and kept with their description, quantity, rate, and taxable value, so a multi-line invoice comes out as multiple classified rows rather than one line of totals.

What if the code is printed inside the description cell?

Per-layout inference finds the code wherever the layout puts it, including codes jammed into the same cell as an item description, and returns it as its own field.

Does it verify the code against the item description?

It flags pairs where the printed code and the description disagree so a human decides which is right. The decision is remembered and reused on later batches from the same vendor.

Can the codes be exported on their own?

Yes. HSN/SAC, code type, and the matched line export as their own columns in Excel, CSV, or JSON, or as rows in Google Sheets.