From scanned bundle to Tally-ready batch

How it works

Four stages. Scans come in how they always did. Entries leave how Tally wants them. The typing just goes away.

Send the scansupload, email, folderRead and extractvision model + OCRProve the math4 gates, in writingExport to Tallyday or vendor batches

Four steps, no new habits

You keep working as before. Scans in, entries out. Less typing.

Send the scans

Drop PDFs, JPGs, PNGs. One file or a hundred. Photocopies, crooked phone shots, three-page bundles. We split every PDF page by page at 300dpi.

bulk uploadmulti-page300dpi rasterize

Read and extract

A model reads each page. OCR runs next to it as a check. Seller GSTIN, buyer GSTIN, invoice number, IRN, HSN lines, taxable value, taxes, total.

GSTINsIRNHSN linesIndian amounts, DD/MM/YYYY

Prove the math

Here's the gate. GSTIN checksum. HSN check. Do the lines add up. Do the taxes add up. Does the place of supply match the tax paid. Pass and it goes to Tally. Fail and a person sees why.

checksumarithmetic closureregime check

Export to Tally

Tally-import files, batched by day or by vendor. Every field in every entry carries its evidence: the scan crop it came from, the validator results, and who confirmed what, if anyone did.

Tally-import formatday / vendor batchesaudit trail

What happens at each stage

Each stage has a contract: what comes in, what goes out, and what gets logged.

Send the scans

Everything arrives as images of paper; the pipeline treats each page as a first-class document.

In

  • PDFs, JPGs and PNGs from the uploader
  • Multi-page bundles and mixed batches
  • Photocopies with skew, grain and uneven lighting

Out

  • Pages rasterized at 300dpi, ordered per bundle
  • Duplicates flagged by content hash
  • Every source file logged against its invoice

Read and extract

A vision model reads each page; OCR text runs alongside as a cross-check, and output is parsed defensively into a canonical invoice contract.

In

  • Page images plus the OCR text layer as verification context
  • Vendor layout variations, no per-vendor templates
  • Indian amounts (1,00,000.00) and DD/MM/YYYY dates normalized

Out

  • Draft fields: seller and buyer GSTINs, invoice no., date, IRN
  • HSN-coded line items with quantities and rates
  • Low-confidence fields flagged, never guessed

Prove the math

The gate. Four validators decide whether an entry is allowed to exist at all.

In

  • GSTIN mod-36 checksum on both seller and buyer
  • HSN codes checked for format and directory membership
  • Arithmetic closure from line items to grand total
  • Regime consistency: place of supply vs CGST/SGST vs IGST

Out

  • Verdict per invoice: AUTO-EXPORT or NEEDS_REVIEW
  • Machine-readable reasons, e.g. line[2] tax off, checksum digit
  • Every validator result logged to the invoice

Export to Tally

Only validated entries leave. Your import routine does not change.

In

  • Validated entries only; failures never reach this stage
  • Vendor and ledger mappings confirmed once in your workspace

Out

  • Tally-import format files, batched by day or by vendor
  • Per-invoice evidence pack: scan crop, validator results, confirmations
  • Exports land in the same rhythm your Tally imports run
When a gate failsThe invoice never exports. It waits in a review queue with the scan and the reason, and your operator fixes it in about 10-20 seconds.See the validation gate