Account Reconciliation Software vs Custom Automation: An Honest Comparison
Packaged account reconciliation software wins on standard bank matching. It stalls when settlement lines name terminals and the ledger names branches.

Account reconciliation software is the right buy for most Indian businesses. If the job is matching a bank statement to your books across one or a few entities, the reconciliation built into TallyPrime or Zoho Books, or a close platform like BlackLine, does it for less than anything we would build. A custom engine earns its cost in one situation: when the identifiers on the two sides of the match do not line up.
We build reconciliation automation for a living, so read this knowing our bias. It is also why we are specific about where software wins. Our reference build reconciles card and UPI settlements for a jewellery retailer with roughly fifty shops and two acquiring banks, and most of what follows is what that build taught us about where packaged tools stop.
What does account reconciliation software actually do?
It imports the external record (a bank statement, a card settlement file, a vendor statement), compares each line against your ledger on date, amount and reference, and flags what disagrees. Two categories sell under the same name, and they solve different problems.
- Accounting-suite reconciliation lives inside the ledger you already run. TallyPrime sorts imported statement lines into an Exact Match section and a Potential Matches section, the second judged on instrument date, amount and party, according to TallyHelp's auto reconciliation guide. Zoho Books suggests the best possible matches for each uncategorised bank line, and lets you match one line to several transactions once their amounts add up to the bank amount (Zoho Books help on matching transactions).
- Close-management platforms such as BlackLine, FloQast, Trintech and Numeric sit above the ERP. Their job is balance-sheet account certification: every account reconciled, reviewed and signed off before month-end close, with task lists and audit evidence attached. The first page of Google for this keyword is almost entirely these vendors and their own best-of lists.
Neither category was designed around the file an Indian card acquirer sends a retailer every morning. That gap is what this comparison is about.
When is off-the-shelf reconciliation software the right choice?
Buy software when a bank line and a ledger line can be matched on amount and date without anyone needing to know anything else. That describes most businesses, and for them a custom engine is money spent rebuilding a feature they already own.
- You run one company, or a handful, each with its own books.
- Each bank credit corresponds to one invoice, or to a few that sum exactly to it.
- Your statements arrive in a format your accounting suite already imports.
- The monthly exceptions list is short enough for one person to clear in an afternoon.
- The pain is discipline (reconciliation keeps slipping to month-end) rather than impossibility.
If that is you, switch on the reconciliation feature in the ledger you already pay for, write the matching rules, and put a weekly reconciliation on someone's calendar. When a prospect describes this shape on a call, that is the answer we give, because the honest fix is a setting, not a build.
Where does packaged software break for Indian multi-branch retailers?
It breaks at settlement reconciliation, where the bank credit is not the amount the shop took and the settlement file does not name the shop. UPI alone handled 24.51 billion transactions in August 2026, per NPCI data reported by Business Standard, and every card or UPI rupee a retailer collects comes back as a netted, batched acquirer credit.
When a customer pays by card, the shop does not receive that amount. The acquiring bank deducts its merchant discount rate (MDR), deducts GST on that fee, batches the remainder with other transactions, and credits it later, often combined with other days. Three separate problems then hit a rules-based matcher.
The identity problem: terminals are not branches
A settlement line names a payment terminal. The ledger names a branch, and in a multi-entity group, a separate company. Nothing in either file connects the two. Tally's party matching and Zoho's filters cannot bridge that, because the link lives in nobody's system. We had to build a terminal-to-shop-to-ledger crosswalk and resolve every terminal before a single deterministic match was possible. A crosswalk that resolves 90% of terminals is not automation. It is a new manual task with extra steps.
The arithmetic problem: net never equals gross
Zoho Books will match one bank line to several transactions once their amounts equal the bank amount. A settlement credit never equals the sales it covers, because MDR and GST have already come out of it. The match has to run on the net figure and then split the fee and the tax into their own journal lines, which is posting logic, not matching logic.
The format problem: every acquirer writes its own file
Two acquirers means two settlement layouts and two naming conventions for the same terminal. In our build, one acquirer also reported transfers to head office in a way none of the sample files had shown. A packaged tool expects a bank statement, and an acquirer settlement report is a different document.
Scale compounds all three. The client's ledger spans 52 Odoo company records, so "reconcile the bank account" really means "decide which of 52 books each credit belongs to", and no packaged reconciliation screen asks that question. If your morning looks like this, it is the exact problem our finance and reconciliation automation service is built around: we read the acquirer and bank files you already receive and stage journals in the ledger you already use.
How do the three options compare, side by side?
On standard bank matching they are close. They separate on identity, fee splits and entity routing, which is exactly where multi-branch retail lives.
- Matching basis: suites match on date, amount and party. Close platforms add configurable rules on top of ERP data. A custom engine matches on whatever key your data actually shares, including a terminal crosswalk.
- Multi-entity: suites reconcile one company's books at a time. Close platforms certify per entity. A custom engine routes each credit to the entity it belongs to.
- Acquirer settlement files: suites import bank statements. Close platforms need an integration project. A custom engine ships one parser per acquirer over shared matching logic, so a third acquirer is a parser, not a rebuild.
- MDR and GST split: manual in the suites. For a close platform, ask the vendor to demo it on your own settlement file. In a custom engine it is part of the posting step.
- Time to live: a suite, the day you switch the feature on. A close platform, a vendor implementation project. A custom engine, roughly 5 to 8 weeks for a single entity (2 to 3 weeks mapping, 3 to 5 building and running in parallel with the manual process), longer for multi-entity groups.
- Who maintains it: the vendor, for the first two. You, or whoever built it, for a custom engine.
What does a custom reconciliation engine cost you that software does not?
Ownership. A software vendor absorbs format changes, bank additions and bugs across thousands of customers. A custom engine absorbs them for exactly one. Price the upkeep before you price the build.
- Tests. Ours re-runs 122 automated tests against 9,462 shop, date and rail batches every cycle, because a silent mismatch in a ledger is worse than a loud failure.
- Historical archaeology. We audited roughly 27,000 historical journal entries to recover the client's existing posting conventions before writing a single rule. Packaged software asks you to adopt its conventions instead, which is cheaper and sometimes the right trade.
- First-run corrections. The first live posting in July 2026 corrected assumptions about date conventions and head-office transfers that no sample file had shown.
- Parser upkeep. When an acquirer changes its file layout, someone has to update a parser that week.
What it buys back is concrete: 2,400 to 3,000 hand-keyed journal entries a month that nobody types any more, and a morning that opens as a review queue (green rows to confirm, red rows to investigate) instead of a reconciliation exercise. The deciding number is how many lines your current tool cannot match, not your turnover.
How do you decide between software and a custom build?
Reconcile one real day by hand before you buy or commission anything. It costs one person one day and settles the question with your own data instead of a vendor's demo data.
- Take one day's bank statement, every settlement file that fed it, and the point-of-sale export for the same day.
- Match what you can on amount and date alone. That share is what any account reconciliation software will do for you.
- For every line left over, write down what you needed to know to match it: a terminal-to-branch lookup, a fee deduction, a head-office sweep.
- If that list is short and irregular, buy software and clear the exceptions by hand.
- If the same missing key appears on line after line, you have found your crosswalk, and that is the case for a custom engine.
Whichever way it lands, check one thing before signing: can the tool write to your ledger, and does it keep the edit log India's audit trail rule requires? The ICAI implementation guide on audit trail reporting is what your auditor will read it against. Our longer piece on finance automation that posts only after a human approves explains why write access is the design decision to get right first.
Can custom automation sit on top of the software you already have?
Yes, and it usually should. The engine in our reference build does not replace the client's accounting software or point-of-sale system. It reads the files the acquirers and bank already produce, does the matching packaged tools cannot, and stages journals in the existing ledger for a person to approve.
That split keeps each tool on the work it is good at. Plain bank reconciliation can stay in the ledger's own feature while the custom layer handles only the settlement rails. Nothing posts without a human approving it, and zero journals have gone through unreviewed. CA Anirudh Varma, from the client's internal audit team, described it as "a practical system with the right level of human control" in the reconciliation case study.
Frequently asked questions
Is there free account reconciliation software?
The reconciliation built into TallyPrime and Zoho Books comes with the licence you already pay for, so it costs nothing extra. Below that, Excel is the zero-cost option. Standalone free tools exist, but moving your books to save a subscription rarely beats switching on the feature you already own.
How do you do reconciliation in Excel?
Put the bank statement and the ledger extract on two sheets, build a match key (date plus amount, or a reference number), and use XLOOKUP or COUNTIFS to flag lines that appear on one side only. It holds up until one bank credit covers many sales, which is exactly what card and UPI settlements do.
What should we ask a reconciliation software vendor in a demo?
Bring your own files, not theirs. Ask them to import one real acquirer settlement report, match it to the bank credit it produced, split MDR and GST into separate lines, and post to the right entity. Then ask to see the edit log for that posting. A demo run on sample data only proves the demo works.
Can we start with software and move to a custom engine later?
Yes, and it is a sensible order. A few months on packaged software shows exactly which lines it cannot match, and that list is the specification a custom build needs. Keep the exception reports; they become the first input to the mapping phase.
Which accounting systems can a custom engine post into?
We have built production reconciliation into Odoo across 52 company records. The same approach connects to Tally or Zoho Books wherever there is an API or a structured import, so the ledger stays where it is and nobody migrates.
If you are not sure which side of the line you are on, bring one day of settlement and bank files to a 30-minute call with our team. We will run the one-day test with you and tell you whether you need a software setting or a build.

Founder and Director at Neogen Media. Writing field notes on AI automation, growth systems, and the integrated playbook we ship for Indian SMBs. Based in Kochi.
Follow on LinkedIn