How to Evaluate Reconciliation Software: A 10-Point Framework for Indian CFOs

When an Indian CFO or IT Head evaluates reconciliation software, most vendor scorecards offer the same categories: integration support, user interface, customer references, and security. These criteria are necessary but insufficient for Indian enterprises. Three structural requirements — statutory compliance handling for TDS and GST, support for Indian payment rails including NACH and UPI, and config-only deployment versus custom development — determine whether a platform actually works for India, or whether the finance team will spend the first six months building the India-specific logic themselves.

This framework gives you ten evaluation criteria in priority order. Criteria 1 through 3 are binary filters: a platform that fails any of them is not fit for purpose in India, regardless of other features. Criteria 4 through 10 are differentiators that separate commodity tools from purpose-built infrastructure. At the end of each criterion is the question you should ask in the demo.

What Reconciliation Software Does in an Indian Enterprise Context

Reconciliation software is the matching layer that sits between your transaction data sources and your ERP general ledger. It ingests bank statements, payment gateway settlement files, TDS certificates, GSTR-2B data, and NACH batch returns, then matches each line item against what the ERP recorded and classifies the gaps.

The operative word is “matches.” An ERP records what should have happened according to a voucher or journal entry. Bank statements and external data sources record what did happen. The reconciliation software’s job is to find the differences, explain them, and route the unexplained ones to the right human for resolution.

For Indian enterprises, this job is structurally more complex than equivalent processes in most other markets. The number of parallel compliance frameworks that generate reconcilable data is higher: TDS deducted at source must match Form 26AS downloaded from TRACES; ITC claimed must match GSTR-2B auto-populated from the GST portal; NACH batch debits must match NPCI return files; payment gateway credits must match settlement files that include TCS under GST Section 52. Each requires different ingestion parsers, different matching rules, and different exception taxonomy.

A platform that handles bank-versus-ledger reconciliation well but cannot ingest GSTN JSON or NPCI XML is a partial solution — it solves the easy part of the problem while leaving the high-compliance parts to manual processes.

Why India Requires a Different Evaluation Framework

The standard SaaS evaluation process is built around a generic feature checklist. Does it integrate with our ERP? Does it have role-based access? Can it generate audit-ready reports? These questions matter everywhere. They do not distinguish between a platform built for the Indian compliance stack and one built for US or European accounting requirements.

Three structural differences make India-specific evaluation criteria non-optional:

The statutory compliance layer is thicker. TDS deduction chains — where a vendor deducts TDS at source, the deductee must trace it to TRACES, and both must reconcile against Form 26AS and Form 16A each quarter — have no direct equivalent in most Western markets. GSTR-2B matching, where ITC claimed in GSTR-3B must reconcile against the auto-populated reconciliation statement from the GST portal, is India-specific. Finance teams using large ERP reconciliation modules report that India-specific exception types like TDS net-of-gross still require manual adjustment outside the system, because the standard ERP logic was not written for this deduction structure.

The payment infrastructure is different. Indian payments travel through NEFT, RTGS, IMPS, UPI, NACH, and bank-specific channels, each generating different transaction identifiers and narration formats. The UTR (Unique Transaction Reference) attached to RTGS and NEFT transfers is the most reliable matching signal available. A reconciliation engine that does not assign high weight to UTR will produce lower match rates than one that treats it as the primary signal.

Deployment expectations are different. Indian finance teams have been operating with ERP exports and manual spreadsheets, not sophisticated middleware. The deployment model needs to be configuration-based — not a development engagement — to allow a 2-to-4-week go-live rather than a 3-to-6-month implementation project.

The 10-Point Evaluation Framework

Criterion 1: India Tax Stack Coverage

This is the first filter. Verify that the platform natively handles:

• TDS matching against Form 26AS and Form 16A — specifically TDS net-of-gross (where bank credit arrives net of TDS, but the invoice and ERP entry are gross)
• Section-level TDS classification — 194C for contractor payments, 194J for professional services, 194H for commission, 194I for rent, 194Q for purchases above threshold, and Section 195 for non-resident payments
• GSTR-2B matching — ingesting GSTN JSON format, matching against the purchase register, classifying ITC mismatches by variance type
• NACH compliance — NPCI return codes, presentation date matching, mandate batch disaggregation

The demo question: Ask the vendor to show you TDS net-of-gross matching on a sample dataset where bank credits are net of TDS. If they cannot demonstrate this in the demo, it means their platform handles it manually or not at all.

Criterion 2: Matching Engine Architecture

The matching engine is the core product. Superficial evaluation — “does it do automated matching?” — is not sufficient. You need to understand the architecture:

A well-designed matching engine for Indian enterprise data runs multiple passes in sequence. The first pass handles exact matches — items where every key field (UTR, amount, date) aligns precisely. Items confirmed in pass one exit the queue. The second pass applies signal-weighted matching — assigning confidence scores to partial matches using UTR (highest weight), payment reference, counterparty name, date, payment mode, and amount. The third pass applies tolerance matching — allowing configured variance bands for rounding differences, MDR deductions, or TDS netting. The fourth pass handles aggregation — splitting one-to-many credits or aggregating many-to-one payments.

Signal weights matter because not all identifiers are equally reliable. A system that treats UTR and amount as equal signals will produce lower match rates than one that weights UTR at 0.40 and amount at 0.05, reflecting the fact that UTR is a deterministic bank-assigned identifier while amount alone is not. On a 781-row test dataset across mixed data sources, this four-pass architecture with calibrated signal weights improved match rates from 51% on single-field matching to 88% on multi-signal matching.

The demo question: Ask the vendor what signal weights their engine applies and in what order. If they cannot articulate this, their engine is likely applying a simpler algorithm that will produce lower match rates on your more complex transaction types.

Criterion 3: ERP Integration Depth

Integration requirements vary by organisation size and ERP landscape:

• SAP (common in large enterprises): SAP RFC or API-based connector, pulling from FI/CO tables; BAPI integration for writing cleared entries back
• Oracle ERP Cloud / Oracle Financials: REST API integration; AP and AR module connectivity
• Tally (common in mid-market): File-based export from Tally Prime, narration field mapping
• Busy (common in trading and distribution): CSV export, custom field mapping for GST and TDS modules

CAs working with Tally-based clients flag that multi-entity reconciliation requires manual export workflows in most point solutions — each entity’s Tally instance must be exported separately and merged manually before matching begins. A platform that handles multi-entity ingestion from a single connector configuration eliminates this manual step.

The demo question: Ask the vendor to show integration with your specific ERP version, not a generic demo ERP. Request a live data pull or show the field mapping for your ERP’s GL export format.

Criterion 4: Deployment Model

Config-only versus custom development is one of the highest-leverage criteria in the entire evaluation. The distinction:

Config-only deployment means the platform ships with pre-built connectors, matching logic frameworks, and industry presets. Implementation consists of configuring parameters: which ERP fields map to which matching identifiers, what tolerance bands apply to which transaction types, which variance codes map to which exception categories. No code is written. A finance operations manager or a vendor implementation consultant can complete it. Typical timeline: 2 to 4 weeks.

Custom development deployment means the vendor builds matching logic, connectors, or exception workflows specific to your organisation. This is often described as “configuration” by the vendor but involves actual development work — custom scripts, bespoke ETL jobs, or modified product code. Typical timeline: 3 to 6 months. The ongoing risk: when regulatory rules change (new GST notifications, revised TDS thresholds, new NACH return codes), you depend on the vendor to release an update rather than reconfiguring a parameter.

For most Indian enterprises, 24 or more industry presets covering verticals from NBFC to healthcare to real estate to e-commerce eliminate the need for custom development. The preset encodes the vertical-specific matching logic — split-matching for TPA settlements in healthcare, mandate disaggregation for NACH in NBFCs, buyer TDS under Section 194IA for real estate — as configurable parameters.

The demo question: Ask the vendor to show you their onboarding scope of work document. If it includes a “development” or “customisation” line item, you are looking at a custom-development engagement.

Criterion 5: Audit Trail and Override Logging

Reconciliation software must produce a defensible audit trail because the outputs feed into regulatory filings (TDS returns, GST returns, income tax returns) and statutory audits. The audit trail must record:

• Every matching decision: which rule matched item A to item B, what confidence score was assigned, which pass confirmed the match
• Every manual override: which user overrode an automatic match or unmatch decision, at what timestamp, with what justification
• Every exception resolution: which user cleared an exception, what action was taken (approved as variance, escalated, referred for correction return)

The audit trail must be immutable — it should not be editable by any user, including administrators. ICAI audit standards require that financial controls are documented and evidenced; an override log that an administrator can delete does not satisfy this requirement.

The demo question: Ask to see an actual audit trail export from a live client account. Look for: timestamp granularity (second-level, not day-level), user attribution on every action, and immutability confirmation.

Criterion 6: Exception Workflow

An exception queue that lists unmatched items is not the same as an exception workflow. The difference is resolution path versus discovery. A workflow:

• Classifies each exception by variance code — FEE_DEDUCTION for MDR deductions on gateway credits, TAX_DEDUCTION for TDS netting, ROUNDING for sub-rupee differences, PARTIAL_PAYMENT for instalments, PENALTY_OR_INTEREST for late payment charges, UNEXPLAINED for items requiring manual investigation
• Routes each code to the right reviewer — rounding exceptions to bulk approval, TDS mismatches to the tax team, unexplained items to the accounts manager
• Tracks resolution SLA — how many days each exception has been open, which are approaching deadline
• Records the resolution action — not just “resolved” but “approved as MDR variance” or “referred for correction return”

The demo question: Ask the vendor to show a live exception queue from a client, then ask: “How does a ROUNDING exception get resolved differently from a PARTIAL_PAYMENT exception?” If the workflow treats all exceptions the same, the classification step adds no operational value.

Criterion 7: Security Certifications and Data Residency

Financial data residency is not a preference for Indian enterprises — it is a compliance requirement for many. The relevant framework:

ISO 27001:2022 is the baseline information security certification. Verify the certificate scope covers the reconciliation platform specifically — not just the parent company’s corporate IT environment.

AWS Mumbai (ap-south-1) data residency satisfies RBI guidelines on storage of payment transaction data within India. For payment aggregators and payment system operators, RBI’s 2018 circular on data localisation mandates that all payment data be stored in India. Verify that data at rest and data in transit do not traverse non-India regions during processing.

DPDP Act 2023: The Digital Personal Data Protection Act imposes obligations on entities processing personal data. Financial transaction data containing PAN numbers, Aadhaar references, or bank account details falls within scope. Verify the vendor’s data processing agreement includes DPDP compliance clauses.

The demo question: Request the vendor’s ISO 27001:2022 certificate, their AWS region configuration documentation, and their DPDP compliance posture document. A credible vendor produces all three without delay.

Criterion 8: Variance Explanation Codes

The difference between a platform that flags exceptions and one that explains them is the variance code system. A flag says “these two items did not match.” A variance code says “these two items did not match because TDS was deducted at source and the bank credit arrived net” — and that explanation determines the resolution path.

Standard variance codes for Indian enterprise reconciliation:

• FEE_DEDUCTION — platform or bank fee deducted before credit
• TAX_DEDUCTION — TDS or TCS deducted before credit
• ROUNDING — sub-rupee difference due to rounding methodology
• PARTIAL_PAYMENT — instalment or partial settlement
• PENALTY_OR_INTEREST — late payment charge applied
• UNEXPLAINED — no variance pattern matched; requires manual investigation

The operational impact: a queue of 200 flagged exceptions requires a finance team member to investigate each one from scratch. A queue of 200 coded exceptions lets the team bulk-approve 150 ROUNDING items, route 30 TAX_DEDUCTION items to the TDS team, and focus human effort on the 20 UNEXPLAINED items that actually require investigation.

The demo question: Ask the vendor to show what happens when a TDS net-of-gross exception is generated. Does it classify as TAX_DEDUCTION automatically, or does it land in a generic “unmatched” bucket?

Criterion 9: Industry Preset Depth

A generic reconciliation tool applies the same matching logic to every transaction type. An industry-preset platform ships with vertical-specific configurations that reflect the structural characteristics of each sector’s reconciliation challenge.

Evaluate preset depth by asking: does the preset encode the matching logic, or does it just change the label? Substantive presets for Indian sectors include:

• NBFC: NACH batch disaggregation to individual loan accounts, DPD counter update logic, bounce code classification
• Healthcare: TPA settlement split-matching (one credit covers many patient claims), Ayushman Bharat claim reconciliation, doctor payout matching
• Real estate: Buyer TDS under Section 194IA matched to property consideration and Form 26QB, RERA milestone payment matching
• E-commerce: Marketplace settlement reconciliation (Razorpay, PayU, Cashfree) with TCS under Section 52, MDR and reversal handling
• IT services: Section 194J TDS receivable matching against Form 26AS, multi-currency invoice matching for export invoices

Organisations on generic accounting platforms find that GSTR-2B matching requires a separate manual step when the platform has no GST-specific ingestion preset — the GSTN JSON download cannot be mapped to a generic “CSV” ingestion field without manual transformation.

The demo question: Ask to see the preset for your industry loaded in a demo environment. Verify that the matching rules loaded reflect your transaction type — not a generic rule set relabelled with your industry name.

Criterion 10: Vendor Discovery Process

The final criterion is about the vendor’s sales process, because it predicts how well the platform will be configured for your use case.

A vendor who books a demo and then presents a generic product tour has not scoped your reconciliation requirements. A vendor who asks — before or during the first call — what transaction types you process, which ERPs and banks you connect to, what your current match rate is, and what your quarterly TDS and GST exception volumes look like is a vendor who will configure the engine to your actual data, not a generic dataset.

The distinction matters at go-live. A platform configured by someone who understood your NACH batch structure, your TDS section mix, and your payment gateway settlement format will achieve the contracted match rate target within the first month of operation. A platform handed over after a generic demo tour will require extensive post-go-live tuning — consuming your finance team’s time during the period when they should be seeing benefit.

TransactIG’s sales process moves through three stages: Demo, Discovery, and Configure. The Discovery meeting is where your transaction types, data sources, and exception patterns are mapped before any configuration begins. A vendor who asks about your transaction types before quoting is better positioned to configure correctly than one who demos a generic product and scopes your use case only after contract signature.

The demo question: Before the demo, ask the vendor what information they need about your organisation to run the demo on representative data. If they can demo without knowing anything about your transaction types, you are watching a canned product tour — not an evaluation.

Comparison: Spreadsheet or Generic Tool vs Purpose-Built India-Specific Platform

How the Matching Engine Works

The matching engine is the technical core of reconciliation software, and understanding its architecture is the clearest predictor of match rate performance on your data.

A four-pass pipeline processes each reconciliation run in sequence. In the first pass, the engine attempts exact matches across all key fields simultaneously: UTR, payment reference, counterparty name, amount, and date. Items that match exactly on all signals exit the queue confirmed and do not proceed to further passes. Exact matching handles the straightforward volume — typically 40 to 55% of total transactions in a clean dataset.

The second pass applies signal-weighted matching to items that did not exit in pass one. Each available signal is assigned a weight reflecting its reliability as a matching identifier:

Items that score above a configured confidence threshold are matched with high confidence and exit the queue. Items that fall below threshold proceed to pass three.

The third pass applies tolerance matching — allowing a configured variance band for specific exception types. For TDS net-of-gross scenarios, a 5% tolerance on high-confidence UTR matches allows the engine to match a ₹97,000 bank credit to a ₹1,00,000 invoice where TDS was deducted at 3%. Without tolerance matching, this is an unresolved exception; with it, it matches as TAX_DEDUCTION with the variance amount captured for audit.

The fourth pass handles aggregation — where one bank credit corresponds to multiple invoice items, or where multiple small payments aggregate to one invoice value. This pass is critical for NACH batch processing (where one credit represents hundreds of mandate collections) and for marketplace settlement reconciliation (where one gateway credit nets out many transactions).

On a 781-row test dataset across mixed data sources — bank statements, ERP exports, and gateway settlement files — this four-pass architecture improved match rates from 51% on single-field matching to 88%. The remaining 12% feeds an exception queue classified by variance code.

Industry Coverage

Reconciliation requirements differ substantially by sector. The following table shows the primary matching problems each sector faces and whether a preset encodes the relevant logic:

Evaluation Guide for Shortlisting

For organisations shortlisting two to three vendors, the following sequence reduces evaluation time and surfaces differences quickly:

Step 1 — Tax stack proof of concept first. Before evaluating anything else, ask each vendor to ingest a sample of your GSTR-2B JSON and your Form 26AS PDF and show you the exception output. Vendors without native parsers for these formats will reveal the gap immediately.

Step 2 — Run your own data, not their demo data. Provide a month of actual bank statements and ERP GL exports. Any vendor with a credible matching engine will willingly run your data and show you the match rate and exception breakdown. A vendor who insists on demo data only is not confident their engine performs on real-world Indian data.

Step 3 — Request a tolerance band walkthrough. Ask the vendor to show you how they would configure tolerance bands for your transaction types — specifically for TDS netting, MDR deductions, and rounding. The answer reveals whether configuration is done by their finance team (correct) or their engineering team (warning sign).

Step 4 — Verify the audit trail format. Request a sample audit trail export and test it against your auditor’s requirements. ISO 27001:2022-certified platforms produce structured, timestamped, user-attributed logs that an auditor can read without interpretation.

Step 5 — Ask the contract match rate question. Credible vendors offer a contractual match rate commitment — typically 70 to 85% on a defined dataset. Ask what the contract terms are if the match rate falls below the committed threshold. Vendors who cannot commit to a match rate in contract are not confident in their engine’s performance on India-specific data.

Security and Deployment

Indian enterprises face a straightforward security question when evaluating cloud-hosted reconciliation software: does the vendor’s infrastructure satisfy both the baseline security standard and the data residency requirement?

ISO 27001:2022 is the current version of the international information security management standard. The 2022 revision introduced specific controls for cloud services and data protection that are directly relevant to SaaS-delivered reconciliation platforms. Verify that the certification scope statement covers the reconciliation platform and the AWS infrastructure used to deliver it — not just the vendor’s corporate IT environment.

AWS Mumbai (ap-south-1) data residency places all data at rest and in transit within India. For most Indian enterprises, this satisfies both RBI guidelines on payment data localisation and reasonable data governance requirements under the DPDP Act 2023. Regulated entities — banks, insurance companies, stock brokers — should verify with their respective regulators whether additional controls are required beyond AWS Mumbai residency.

On deployment timeline: a platform with 24+ industry presets and config-only architecture deploys in 2 to 4 weeks. The deployment consists of four sequential stages: connector configuration and data source mapping (Week 1), matching rule and tolerance band configuration (Week 2), parallel run validation against the existing manual process (Week 3), and production cutover with sign-off (Week 4). No custom code is involved. If the vendor’s deployment plan includes a “development” or “integration build” phase, you are looking at a longer engagement.

A private cloud deployment option (dedicated VPC within AWS Mumbai) is appropriate for regulated entities that require logical isolation from multi-tenant infrastructure without the operational overhead of on-premise hosting. This satisfies data residency requirements while retaining the vendor’s update and maintenance responsibilities.

For organisations ready to map their specific reconciliation requirements against these criteria, the starting point is a discovery conversation — not a generic demo. Reconciliation software India covers the full platform capabilities. For the TDS-specific evaluation, TDS reconciliation software addresses the section-level matching requirements and the Form 26AS ingestion architecture in detail.

The Institute of Chartered Accountants of India publishes audit and internal control standards that define what a defensible reconciliation process must produce — including evidence requirements for exception resolution and override justification that directly inform what the audit trail and workflow criteria should cover.

The 3 Questions Most Evaluations Miss

Standard software evaluation processes — whether run internally or through a procurement RFP — apply criteria developed for generic enterprise software. Three questions are routinely absent from shortlists but material for Indian enterprises:

Question 1: “Does the platform handle TDS net-of-gross matching without manual intervention?”

This question is India-specific and has no equivalent in Western reconciliation evaluation. TDS net-of-gross describes the scenario where a vendor or customer deducts TDS from the gross invoice value and remits only the net amount to the bank. The ERP records the gross invoice; the bank statement shows the net credit. Without a matching engine designed for this scenario, the variance is flagged as an unexplained exception — requiring manual intervention for every TDS-deducted transaction. Finance teams using large ERP reconciliation modules report that India-specific exception types like TDS net-of-gross still require manual adjustment outside the system, because the base product was designed for markets where TDS deduction at source is not standard practice. Verify that this specific scenario is handled automatically before shortlisting.

Question 2: “What happens to your match rate when regulatory rules change — new GST notification, revised TDS threshold, new NACH return code?”

This question surfaces the config-only versus custom-development distinction. A config-only platform updates a rule parameter when regulations change. A custom-development platform requires a development engagement, a release cycle, and possibly a contract amendment. Given that Indian tax regulations change annually — Union Budget introduces TDS threshold revisions, GST council notifications change rate applicability, NPCI updates NACH return codes — the ability to absorb regulatory change through configuration rather than development is a material operational requirement, not a nice-to-have.

Question 3: “Will you scope my use case before configuring the platform?”

This question reveals whether the vendor’s process is built for accurate configuration or for fast contract closure. A vendor who cannot answer specific questions about your NACH mandate structure, your TDS section mix, or your ERP GL export format before configuring the engine will produce a misconfigured deployment that underperforms the contracted match rate. The scoping conversation — where your transaction types, data sources, exception patterns, and volume are mapped to the platform’s configuration options — is the step that determines whether you achieve 70% or 88% match rate in month one.