Invoice data entry is the most reliably profitable automation we run at Lacewing Technologies, an AI and software development company in Navi Mumbai. The reason is not that the technology is impressive. It is that the before-state is so obviously wasteful: a person retyping numbers that already exist, in a PDF, in a structured form.
That makes the business case easy. It also makes it easy to oversell, so here is what these projects actually deliver and where they still need a person.
What accuracy should you expect on Indian vendor bills?#
Field-level accuracy above 95% is normal on clean, digitally generated PDF invoices. On a phone photo of a creased bill taken at an angle under a ceiling fan, it drops, sometimes a long way.
Accuracy is a property of your document mix, not of the model. This is why any supplier quoting you a single headline accuracy figure without having seen a sample of your bills is guessing, and why the first thing we ask for is fifty real invoices rather than a specification.
The fields also do not fail evenly:
| Field | Difficulty | Notes |
|---|---|---|
| Invoice number | Low | Usually clean, occasionally confused with a challan number |
| Invoice date | Low | Format ambiguity between DD/MM and MM/DD needs pinning |
| Vendor name and GSTIN | Low | GSTIN has a checksum, so it can be validated outright |
| Line item description | Medium | Wraps across lines, abbreviations vary by vendor |
| Quantity and rate | Medium | Multi-line and multi-page tables are the weak point |
| Tax breakup | Medium | CGST/SGST/IGST split is inferable from place of supply |
| Total | Low | Cross-checks against the sum, which is what makes it useful |
That last row is the one to build on. Because the total can be checked against the sum of line items plus tax, you get a free arithmetic validation on every document. If they do not reconcile, something upstream was misread, and the document goes to a human without anyone needing to notice.
How does writing into Tally actually work?#
Tally runs a small HTTP server that speaks XML, listening on port 9000 by default. You enable it in the advanced configuration, and from then on an external application can post XML requests to it: export requests to read masters, ledgers and vouchers, and import requests to write vouchers in.
No TDL programming is required for this path, which surprises people who have been quoted for custom Tally development. The request and response are both XML with an envelope, a header and a body.
Two practical constraints follow. First, the machine running Tally has to be reachable from wherever your pipeline runs. On a typical local-only accounts machine, that networking question is genuinely the first problem to solve, and often the one that delays a project. Second, Tally has to be open for the gateway to answer, which means the automation runs when someone's machine is on, unless you move Tally to a server.
Why is ledger mapping most of the project?#
Extraction gives you a vendor name and an amount. Tally needs to know which ledger that vendor posts to, which voucher type to use, and how the tax splits across your existing GST ledgers.
None of that is in the invoice. It is in your chart of accounts, and your chart of accounts is idiosyncratic, because every Indian business's is. Vendors are named inconsistently, the same supplier appears three times with different spellings, and someone created a ledger in 2021 that everybody now uses for something it was not intended for.
So the configuration work is:
- Building a vendor-to-ledger table, seeded from your existing data and corrected as it runs
- Deciding voucher types per document category
- Mapping tax ledgers for CGST, SGST, IGST and cess
- Deciding what happens to a vendor nobody has seen before
- Deciding who owns a mismatch when the arithmetic does not reconcile
This is why two clients with identical bill volumes get different quotes. The one with tidy, consistent ledger naming is a cheaper project than the one with 400 near-duplicate vendor ledgers.
What does the pipeline look like end to end?#
Six stages, and it is worth understanding them because the quote you receive should map onto them.
- Intake. Bills arrive by email, WhatsApp, a shared drive, or a person photographing them. Each channel needs its own connector, and this is where scope quietly grows. Pick the one or two channels that carry most of your volume and ignore the rest at first.
- Normalisation. PDFs, images and email attachments become a consistent internal format. Straightening, de-skewing and page splitting happen here. Multi-invoice PDFs get separated.
- Extraction. Fields come out with a confidence score attached to each one, not a single score for the document. Per-field confidence is what makes selective review possible.
- Validation. GSTIN checksum, arithmetic reconciliation of line items against the total, date sanity, duplicate detection against previously posted invoices. Duplicate detection matters more than people expect, because the same bill often arrives twice through two channels.
- Mapping. Vendor to ledger, document to voucher type, tax to the correct GST ledgers.
- Posting. XML import to Tally, with the response checked and the result recorded against the source document so any entry can be traced back to the bill it came from.
That traceability in stage six is worth insisting on. When your accountant queries an entry in month four, being able to open the original bill next to the posted voucher is the difference between a two-minute answer and an afternoon.
Where does a human still belong?#
In a review queue, permanently. Every pipeline we build has a confidence threshold: documents above it post automatically, documents below it wait for a person.
The goal is not zero humans. The goal is turning three hours of typing into ten minutes of checking. A system that posts everything automatically and is wrong 4% of the time creates a reconciliation problem that costs more than the typing did, and it destroys trust in the automation permanently the first time it happens.
Set the threshold conservatively at launch and relax it as you accumulate evidence. Route handwritten amounts, unreconciled totals and unknown vendors to review regardless of confidence.
What should you check before starting?#
Four questions, and one of them may end the project, which is fine.
- Roughly how many bills a month, and in what formats? Under about 100 a month, the payback period stretches out and a tidier manual process may genuinely be the better answer.
- Is your ledger naming consistent? If not, budget for cleaning it, because the automation will inherit the mess.
- Who owns the review queue? An unowned queue silently becomes a backlog, and the backlog becomes the reason the project is judged a failure.
- Do you need it in Tally at all? Sometimes the actual requirement is a clean monthly spreadsheet for a decision, and posting to Tally is a habit rather than a need.
If the answers hold up, this is among the safest automation projects available to an Indian business. If they do not, it is better to find that out in week one.