/tally-import · Agent on Laabha

The AI Accountant.

One job: take a bank statement and post the right vouchers into your TallyPrime. 15 banks. PDF, Excel, scanned image, password-protected — all in. Idempotent push. Full audit trail in every voucher narration.

Bank statement in. Posted vouchers out.

Six stages. Each one shows its work.

The AI Accountant doesn't just call an LLM and pray. It runs six deterministic stages, each one auditable.

1. Bank detection. Reads the first two pages, matches against the 15-bank registry by keyword. ~95% accuracy. If unknown, falls through to a generic parser.
2. Parsing. Tier 1: bank-specific parser using pdfplumber (digital PDFs). Tier 2: generic parser. Tier 3: Gemini Vision OCR (scanned). The parser that succeeds is recorded.
3. Ledger fetch. Pulls your active ledger list from TallyPrime via the bridge. Used to validate mappings + suggest matches when narrations are ambiguous.
4. Mapping. Four layers, in order: your narration rules → your historical mappings → UPI-under-₹1000 heuristic (configurable per company type) → Claude AI batch mapping. Each transaction tagged with the source layer that mapped it.
5. XML generation. Builds the Tally XML envelope. Validates against known Tally crash patterns before sending.
6. Push (idempotent). Posts to your Tally bridge. Each voucher carries an idempotency key in its narration. If you retry, duplicates are skipped, not re-pushed.

If any stage fails, you see exactly which one and why. No mystery.

Two-call contract: preview first, push when you say so.

15 Indian banks. Auto-detected.

No dropdown to remember. Drop the file, the bank gets detected. If you have a bank we don't support, we usually add it in 3–5 days — bank parsers are pluggable.

Excel from Razorpay, Cashfree, and similar payment-aggregator exports also works through the generic Excel parser.

Need a bank we don't list? Email rajkumar.nr@gmail.com — most additions ship within a week.

Your rules win. Always.

The biggest mistake we see in "AI accounting" tools is that the AI overrides everything. Laabha runs the AI last, not first.

1. Layer 1 — Narration rules. If you have a rule that says "narrations containing 'AMAZON' map to 'Sundry Creditors - Amazon Sellers'," that rule fires first. AI doesn't even see those rows.
2. Layer 2 — Historical patterns. For transactions Layer 1 didn't catch, we check your previous mappings for the same client. If "PRIME ENERGY DRINKS PVT LTD" mapped to "Sales - Beverages" 47 times in your last 6 months, we don't ask the AI.
3. Layer 3 — UPI heuristic (configurable). For UPI transactions under ₹1,000, you can choose to auto-map to "Drawings" (default ON for trading firms, OFF for service firms). Per-company setting.
4. Layer 4 — AI batch mapping. Whatever's left goes to Claude Sonnet in batches, with the client's chart of accounts as context. Each AI mapping comes back with a confidence score and a reason.

If a transaction can't be confidently mapped by any layer, it lands in "Suspense." You see a Suspense flag on every such row. Nothing silently lands in the wrong place.

Every voucher carries its own audit ID.

When the AI Accountant pushes a voucher into Tally, it embeds a short audit ID in the narration field — e.g. |AID:a3f9b21c. That ID points to an audit row in our database recording:

1. Which transaction this voucher came from (date, amount, original narration)
2. Which layer mapped it (narration rule / historical / UPI heuristic / AI)
3. If AI mapped it: the confidence score and the model's reasoning
4. Who reviewed it (if anyone edited the mapping before push)
5. When it was pushed

So when a partner reviews the books in March and asks "why is this ₹47,000 in 'Office Maintenance' — that doesn't look right" — your senior pulls up the AID, sees the AI mapped it with 62% confidence three months ago, no one reviewed, and now you know exactly how the error happened. That's the difference between "AI for accounting" and "AI you can actually audit."

Priced like a utility, not a SaaS.

Talk pricing →