Invoice number, date, taxable value, and GST amount extraction

Four fields sit at the centre of every GST invoice: the invoice number, the date, the taxable value, and the total GST amount. Get those four right and the rest of the document is detail; get any of them wrong and the purchase register, the ledger, and the returns built from them all inherit the mistake. Each one has its own failure mode, the series prefix in the invoice number, the day-month order in the date, the difference between a taxable value and a total that already includes tax. Dynamite Docs extracts all four as separate, confidence-scored fields and normalizes them for export.

Try this workflow free or view pricing.

Four fields, four ways to slip

Invoice numbers carry series prefixes — INV/24-25/0144, GT-8821, SI-2026-0119 — and the letters and digits blur in OCR. An “INV” read as “IN1” is the same kind of error as a mistyped amount, and just as hard to spot in a list.
Indian layouts print dates as dd/mm/yyyy, so “03/08/2026” is 3 August, not 8 March. The order is unambiguous to a reader and treacherous to a careless extraction, and dates come through zero-padded and otherwise.
Taxable value and total mean different things on different invoices. Some print the value excluding tax and a total including it; others quote an amount that already includes tax and a GST total on top. Mixing the two is the classic books error.
The total GST amount is sometimes printed as a single line and sometimes not printed at all, left to be summed from the CGST, SGST, and IGST split. Either way it has to be captured or computed, and it has to equal the difference between the taxable value and the total.

How the core four get off the page

01 — Drop the batch in

Upload GST invoices, purchase bills, sales invoices, or a folder of scans and photos. Digital PDFs parse deterministically; scans and photos are read by the vision model you choose.

02 — Four core fields inferred

Invoice number, date, taxable value, and total GST come out as their own fields, pulled from wherever the layout puts them, with taxable and inclusive amounts kept separate.

03 — Normalized and reviewed

Dates are converted to ISO (yyyy-mm-dd) so 03/08/2026 becomes 2026-08-03, series prefixes are kept whole, and anything that ties out wrong, value plus tax not equal to total, is flagged.

04 — Export and use

The four fields export to Excel, CSV, or JSON, or as rows in Google Sheets, in the same column order every batch, ready for your register, your ledger, or entry into Tally.

Document types this workflow handles

GST invoices — the four core fields on every one
Purchase bills — vendor layouts and series prefixes
Sales invoices — your own series and totals
Credit / debit notes — the linked invoice’s number and date

What gets extracted from every invoice

The four core fields land in their own columns, normalized and ready to review:

Invoice number — INV/24-25/0144
Invoice date (ISO) — 2026-08-02
Date as printed — 02/08/2026
Taxable value — ₹24,000.00
Total GST amount — ₹4,320.00
Invoice total (incl. tax) — ₹28,320.00
Round-off adjustment — ₹0.00

A realistic example

A batch extracts to rows like these, the date normalized and the four core fields in their own columns:

Invoice #	Date	Taxable value	Total GST	Total (incl. tax)
INV/24-25/0144	2026-08-02	₹24,000	₹4,320	₹28,320
INV/24-25/0145	2026-08-03	₹1,86,000	₹33,480	₹2,19,480
GT-8821	2026-08-05	₹12,000	₹1,440	₹13,440

Why the core four deserve their own pass

The invoice number is the document’s identity, and identities get mangled. Series like INV/24-25/0144 carry letters, digits, and a slash, and every one of them matters when you’re matching a purchase invoice to its entry or chasing a duplicate. Extraction keeps the number whole, prefix and sequence together, rather than guessing at a numeric core and dropping the part that makes the number unique.

Dates look easy and aren’t. On Indian layouts the day comes first, 02/08/2026, and a value that reads as 8 February when it is really 2 August is a mismatch that surfaces at the period-end, not at capture. Normalizing to ISO at extraction, 2026-08-02, means the sort order and the day-month ambiguity both disappear before the row reaches your books.

The taxable value and the total GST amount carry the tax logic of the whole document. Some invoices state the taxable value excluding tax, the GST on top, and a grand total including it; others print an inclusive amount and the GST as a separate line. Extraction keeps taxable and inclusive values in distinct fields and checks that taxable value plus total GST equals the total — the same tie-out you would do by hand, done at capture.

When an invoice doesn’t print a total GST line, the amount is still recoverable from the split, CGST, SGST, and IGST summed into one figure and flagged as computed rather than printed. Confirm the current rules for what you need from your documents with your tax advisor or the GST portal; the extraction’s job is to give you the four fields the way the invoice printed them.

Why bring-your-own-AI matters for the core fields

The four core fields each have a failure mode: the series prefix in the invoice number, the day-month order in the date, the difference between a taxable value and an inclusive total. Normalization, dates to ISO and numbers kept whole, is deterministic work that runs on every invoice regardless of which model read the page.

Clean digital invoices parse deterministically for free, identical results every run. Photographed and handwritten documents are read by the vision model you pick, and the value-plus-tax tie-out runs on the result either way, so a row that will not balance is flagged before export.

The four fields export in the same column order every batch, ready for your register, ledger, or Tally entry. Corrections on a stray prefix or a misread date are remembered per layout, and the rows stay yours.

Questions, answered

Does it keep the full invoice number, prefix and all?

Yes. The number is extracted whole, series prefix and sequence together, so INV/24-25/0144 stays one field rather than a numeric fragment.

How are dates handled on Indian layouts?

Dates are read as printed (dd/mm/yyyy) and normalized to ISO (yyyy-mm-dd) at extraction, so 02/08/2026 becomes 2026-08-02 and day-month ambiguity disappears.

Is taxable value kept separate from the total?

Yes. Taxable value, total GST amount, and invoice total (incl. tax) are separate fields, and the row is checked so taxable plus GST equals the total before export.

What if the invoice doesn’t print a total GST line?

The total GST is computed from the CGST, SGST, and IGST split and flagged as computed rather than printed, so the figure is still available and your review knows how it was derived.