Scan to Tally is a gate, not a stopwatch.

A factory AP desk still lives on paper. A supplier prints an invoice. Someone photocopies it. It arrives as a WhatsApp image, a crooked phone shot, or a 150 dpi scan with a challan stuck in the same PDF. A clerk then types GSTIN, invoice number, date, HSN, amounts into Tally Prime.

That last step is where the books go wrong. A swapped GSTIN digit still looks like a GSTIN. A total that never summed still posts. The CA finds it when GSTR-2B will not match. Scan-to-Tally, as we mean it, is not “OCR into a cell.” It is: read the page, run the same checks a careful clerk would, and only then hand Tally a voucher file.

This is not a Tally plugin. It is not a GST filing product. It does not replace the import ritual Tally already ships. If a page promises “60 seconds, every invoice, always,” treat that as marketing. Paper quality and review decide the clock. We publish straight-through rate on your own paper, not a stopwatch.

The filmstrip: five stations, one authority

The live walkthrough is on /how-it-works and the demo. What follows is the same path in words a CA can audit.

1. Ingest the scan

The hosted product takes scans the way the desk already works: upload in the UI. The design also allows an email inbox and a folder drop so a clerk does not change muscle memory. What matters after ingest is the same. Multi-page PDFs get split. A challan in the same bundle should not become a purchase voucher. Page classing exists for that mix. If a page is not an invoice, it should not export as one.

Photocopies, phone photos, and skewed scans are the job. Clean digital PDFs with an IRN are a different job. If the supplier already generated an e-invoice, looking the IRN up at GSTN is stronger proof than reading pixels. See IRN vs the photocopy pile. Scan-to-Tally is for the pile that still has to be read.

2. Extract GST-critical fields

The reader has to pull seller GSTIN, buyer GSTIN, invoice number, date, line HSN, taxable value, tax, and total. Indian grouping (Rs. 1,00,000/-), day-first dates, and round-off rows are ordinary on this paper. A confidence badge is not a field. If the model is 91% sure of a GSTIN, that is still a guess until Mod-36 says the check character matches.

Extraction quality changes how often you hit review. It must not change the rule for auto-export. That is written into the product: the validator spine is the sole authority on AUTO_EXPORTED. If a change would let an unvalidated invoice out, it is wrong. Full stop.

3. Run the gate

On every invoice that might auto-export, EntryLedger runs:

• Required fields: invoice number, date, taxable value, total, seller and buyer GSTIN, at least one line.
• GSTIN checksum (Mod-36) on seller and buyer. See the GSTIN post.
• HSN format on lines that carry a code (2, 4, 6 or 8 digits). Directory membership is shadow by default. See HSN validation.
• Per-line taxable, rate, tax present. Arithmetic closure within ±₹1. See totals that do not add.
• Tax regime vs place of supply: CGST+SGST vs IGST. See regime check.

Fail any of those and the status is NEEDS_REVIEW with a reason string. Pass all of them and the status is AUTO_EXPORTED. There is no “pretty sure” middle that still writes Tally.

Duplicates are a separate rule: same invoice number and seller GSTIN, when both are present. Empty GSTIN rows are not forced unique. That is not a substitute for the arithmetic gate.

4. Review only the failures

The review screen is for rows the gate blocked. The clerk should see the crop of the field and the reason, not a spreadsheet of naked strings. Confirm or correct. Then the row can export. If your process is “approve everything over 90% confidence,” you do not have a gate. You have a slider.

Time on review is the honest cost of bad paper. A clean PDF with a valid GSTIN and a total that closes should not need a person. A photocopy where the GSTIN is a smudge should. Your console shows straight-through rate on your paper. It is not a lab score on a vendor’s sample PDF.

5. Export, then Tally Import Data

Export is CSV, XLSX, or XML in Tally-import shape, batched by day or vendor. Ledger names have to match what already exists in Tally. “Acme Steels” is not “Acme Steels Pvt Ltd.” That mismatch is the usual import failure, and it is a mapping problem, not a Tally bug. Seed mappings in your workspace. Reuse them.

In Tally Prime, use Gateway of Tally → Import Data. Masters first if the vendor ledger does not exist. Vouchers for the batch. Exact labels and keys change by release. Follow Tally’s import vouchers help, not a remembered hotkey from a blog.

Read the import report. Fix skipped rows. Do not re-import the whole file or you will duplicate what already posted. EntryLedger’s job is to make the file boring. Tally’s job is still Tally.

What this is not

It is not “Tally learns to see.” Tally does not OCR your photocopies because you bought a scanner. A scan-to-Tally product that only dumps columns into Excel and hopes the clerk will check math is a faster way to post a wrong total.

It is not GSTN filing. GSTR-1 / 3B / 2B stay with your CA stack. If that stack is Clear, keep it. The voucher can still feed it after Tally. See Clear vs EntryLedger.

It is not a new chart of accounts. If you want to leave Tally, that is a ledger decision. Read Busy vs Tally vs a gate. Do not migrate books to fix AP typing.

How to score a demo without getting sold a PDF

Bring your worst 20 photocopies, not the supplier’s digital invoice. For each page write down: printed total, extracted total, whether arithmetic closed, whether GSTIN checksum passed, whether a human touched it. Count auto-exports that were actually right. That count is the product.

Ask where the crop lives when GSTIN fails. Ask what happens if lines do not sum. Ask whether a confidence score can still export. If the answer to the last one is yes, you are buying a slider.

Then import one clean batch into a Tally company that is not production. Confirm ledgers, tax, HSN. Only then talk price. Published meter: ₹1.40 a page to 40,000 pages, ₹1.20 after. At 40,000 pages that is ₹56,000. Labour savings are your CTC sheet, not ours.

The screen the clerk actually uses

Most AP desks are a 1366×768 laptop, Tally in one window, WhatsApp or a scan folder in another. A review UI that needs a 4K monitor and a mouse tour is dead on arrival. Keyboard-first: next failure, confirm, skip. Evidence beside the field so the eye does not travel. If the GSTIN failed, the crop of that GSTIN is on The human at that screen works the checker side of maker-checker. the same row. If the total failed, the printed grand total and the summed lines are both visible.

Mixed bundles are ordinary. A lorry receipt, a weighment slip, a duplicate copy, then the tax invoice. Page classing is supposed to keep the non-invoice pages from becoming vouchers. If a challan still exports as a purchase, that is a product bug, not “the clerk should have noticed.” Say so and we fix the split; we do not train you to babysit it.

Batching matters at month end. One CSV per day is easier to import than 400 single-voucher files. One CSV per vendor is easier when you are still mapping ledgers. Pick one rule and keep it. Re-importing yesterday’s file because today’s batch was appended is how duplicates land. The duplicate rule (invoice number + seller GSTIN) is a backstop, not a licence to be sloppy at the import screen.

If your paper is already IRN JSON and Tally is already posting from GSTN, you may not need this path. If the desk still keys photocopies, the path is the product. Try five pages on /demo. If the totals do not close, you will see why.