Bank Statement Parsing for Tally: How We Built Leepik

Bank statement parsing turns a bank statement into structured transactions that accounting software can import. We built Leepik, an in-house product of Rain Infotech, to do this for Indian bank statements. It converts them into Tally-ready XML vouchers for TallyPrime and Tally ERP 9, with each entry matched to the client’s existing Tally ledgers.

Leepik is not client work. Rain Infotech Private Limited built it and owns it, and it is currently pre-launch. This post covers the problem it addresses, why we kept generative AI out of the extraction path, the two engineering problems that took the most work, and the one place where an AI agent does help.

Who Leepik Is For

Leepik is built for Chartered Accountants, CA firms, and their accounting staff in India, starting with Surat and Gujarat. Bank statements are a routine input to the bookkeeping they do for clients, and every client brings a different bank, format, and set of ledgers.

Each transaction on a statement has to become a voucher in Tally, posted to the right ledger. Done by hand, that means reading every line, typing the date, narration, and amount, and choosing a ledger for each entry. Leepik’s job is to produce those vouchers as a file the CA can review and import.

What Makes Indian Bank Statements Hard to Read

There is no single statement format. Each bank lays out its statements differently, and statements reach a CA’s office in several forms:

• digital PDFs downloaded from net banking
• password-protected PDFs
• scanned copies of printed statements
• phone photographs of printed statements
• statements from co-operative banks, whose layouts often differ from those of larger banks

Password-protected files need to be opened before parsing can begin, and photographs bring skew, shadows, and uneven lighting. A parser that works on one bank’s clean PDF can fail on another bank’s layout, or on a photo of the same statement. Reading statements reliably in any layout was the hardest technical problem we worked on.

Why Bank Statement Parsing Stays Deterministic

Large language models can read documents, so an obvious approach is to send each statement to one. We chose not to. Leepik’s extraction runs as server-side Python processing, with no generative AI or LLMs in the extraction path.

Two reasons drove that choice:

• Same input, same output. Processing the same statement twice gives the same result. Accounting records need output that does not change between runs and can be checked against the source.
• Predictable cost. Rule-based server-side processing has a predictable cost per statement. Model calls for every page would make cost depend on document length and model pricing.

Deterministic does not mean error-free. A poor scan can still be misread, and a new layout may need parser changes. That is why Leepik’s output is a file the CA reviews before importing it into Tally, not an automatic posting.

Matching Entries to Each Client’s Ledgers

Extracting transactions is half the job. Each entry also has to post to a ledger that already exists in the client’s Tally company, and clients name their ledgers differently. The ledger one client uses for bank charges may have a different name in the next client’s books.

Leepik’s ledger matching is rule-based and adapts to each client, so entries are matched to that client’s existing ledgers rather than to a fixed list of generic names. The result is written as XML vouchers. Tally documents XML as its format for importing data from third-party applications, and Leepik produces files for both TallyPrime and Tally ERP 9.

Manual Entry vs. Leepik

The table compares the two workflows step by step.

Where an AI Agent Does Help: New Bank Formats

The second challenge was adding support for new bank formats quickly. Every new layout needs its own parsing code, and writing that code by hand for each bank is slow, repetitive work.

This is where we do use AI, outside the product’s extraction path. An internal AI coding agent drafts the parsing code for a new format, and our engineers review and test it before release. AI speeds up how parsers are written. The released parsers are deterministic Python, so the output for a statement never depends on a model at runtime.

That split, AI in the development workflow and deterministic code in production, is a pattern we would recommend to other teams. It is also the question we start from in AI agent development: where does a model add value, and where does it add risk?

Lessons for Teams Building Document Pipelines

• Decide where determinism is required. If the output becomes a financial or legal record, repeatable results matter more than flexible ones.
• Collect real inputs early. Scans, photos, and unusual layouts are where parsers fail, so test on them before launch.
• Keep a human review step. Make the output easy to check against the source, and do not post it automatically.
• Use AI to build the pipeline, not only to run it. A coding agent with engineer review can shorten the work of adding new formats without putting a model in the runtime path.

The same approach applies to invoices, purchase records, and other financial documents, which our finance and invoicing automation services cover.

Current Status

Leepik is pre-launch. The statement parsing engine and ledger matching are built, and a pilot with CA firms in Surat is next.

Conclusion

Leepik shows how we approach bank statement parsing for accounting: deterministic extraction, ledger matching that adapts to each client, a review step for the CA, and AI used where it speeds up engineering without entering the extraction path. If you are planning data pipeline automation for financial documents, Rain Infotech can help you design and build it.