Reconciliation software for India — built for TDS, GST, and enterprise scale
TransactIG is a configurable reconciliation engine built for Indian enterprise finance. It handles bank and ledger reconciliation, TDS and Form 26AS matching, GST input credit reconciliation, platform settlement, and NACH batch aggregation — in a single deployable system with no code changes required.
What is reconciliation software — and why India is different
Reconciliation software is a purpose-built system that compares financial records from two or more sources, applies configurable matching logic, classifies variances by type, and surfaces structured exceptions for review. Inputs are typically bank statements, ERP ledgers, payment gateway settlement files, TDS deduction certificates, and GST portal data. The output is a classified exception queue — not a raw list of unmatched rows.
This guide is most relevant if your organisation processes 10,000 or more transactions per month and is evaluating automated reconciliation for the first time — or replacing a spreadsheet-based process that has stopped scaling.
Why Indian compliance creates complexity that generic tools cannot handle
Generic reconciliation tools — including those embedded in ERP systems — are designed for straightforward bank-to-ledger matching. Indian enterprise finance introduces three additional compliance layers that these tools do not address natively.
First, TDS deduction reconciliation: every professional service invoice where TDS has been deducted by a client requires a corresponding Form 26AS entry on the TRACES portal. The deductor's PAN, the applicable rate, and the timing of TRACES availability create structured mismatches that require systematic classification — not one-off VLOOKUP patches.
Second, GST input credit reconciliation: the credit a business can claim depends on matching GSTR-2B data from the GST portal against the internal purchase register. The portal updates monthly, suppliers file late, and credit reversals create a rolling mismatch problem that carries forward across quarters if not addressed systematically.
Third, platform settlement reconciliation: businesses collecting payments through aggregators — Razorpay, PayU, Cashfree, Paytm for Business — receive settlement files that embed MDR charges, GST on MDR, TCS at 1%, and platform fees as line-item deductions. Each deduction type needs separate classification and matching against the corresponding invoice or ledger entry. This is a structured multi-party settlement problem, not a bank reconciliation problem.
Reconciliation as infrastructure, not a reporting feature
Most ERP vendors treat reconciliation as a report — a comparison view that finance teams export and work through manually. TransactIG treats reconciliation as load-bearing infrastructure: a system with configurable matching rules, structured variance taxonomy, full audit trails, and a documented exception workflow that operates consistently at every month-end cycle — regardless of transaction volume.
The real cost of manual reconciliation in Indian enterprise finance
Finance teams in Indian mid-market enterprises lose 3 to 5 working days per month to reconciliation work that should be automated. This covers bank statement downloads, TRACES portal queries, GST portal exports, VLOOKUP builds, email follow-ups to operations teams for missing reference numbers, and the correction cycles that follow every month-end close.
The staff-time cost is visible on the salary line. The cost of errors is not.
Unrecovered TDS credits — a silent drain on working capital
Businesses that reconcile Form 26AS manually — or quarterly rather than monthly — routinely find mismatches that go unresolved until the ITR filing window. By then, the deductor's correction deadline has often passed. The unrecovered TDS credit loss runs at ₹2 to ₹8 lakh per year for a business invoicing ₹5 crore or more in services subject to TDS deduction. This is a receivable that disappears, not an accounting entry.
Platform settlement disputes — the 60-day resolution failure
Aggregator settlement disputes — where the collected amount, settled amount, and ledger entry do not reconcile — go unresolved beyond 60 days in approximately 12 to 18% of cases for businesses running manual processes. Each unresolved dispute is a receivable that ages out of recovery range. Automated reconciliation identifies these within the settlement cycle, not 45 days later when the aggregator's dispute window has closed.
What enterprise reconciliation software must handle in India
This is the minimum functional checklist for reconciliation software serving Indian enterprise finance. Generic bank reconciliation tools — including ERP-native modules — typically cover only the first item.
Bank and ledger reconciliation
The baseline function: matching bank statement entries against general ledger postings, identifying timing differences, outstanding cheques, bank charges, and interest entries. In India, this includes reconciliation across multiple current accounts, statement formats from HDFC, ICICI, Axis, Kotak, and SBI, and UPI settlement entries that do not carry standard reference identifiers. TransactIG handles all major Indian bank statement formats via SFTP feed or structured CSV upload — without format-specific configuration for each bank.
TDS deduction and Form 26AS matching
Every professional services invoice where TDS has been deducted by the client requires a corresponding Form 26AS entry from the TRACES portal. The reconciliation must work at the PAN level, the quarter level, and the deduction rate level. Common mismatches include: wrong PAN quoted by the deductor, rate mismatch (10% deducted where 2% applies), and the TRACES update lag of 2 to 4 weeks. TransactIG classifies each mismatch into TAX_DEDUCTION, ROUNDING, or UNEXPLAINED — holding each in a structured exception queue with the full evidence trail required for a correction request to the deductor.
GST input credit reconciliation against GSTR-2B
GSTR-2B is the auto-populated monthly statement on the GST portal that defines the maximum input tax credit a registered business can claim. Reconciling the internal purchase register against GSTR-2B requires matching at the GSTIN, invoice number, and amount level — with tolerance for rounding — and identifying blocked credits, missing supplier filings, and credit reversals. This reconciliation must run monthly, not quarterly, to prevent credit from lapsing or carrying into the following financial year without action.
Platform settlement and aggregator reconciliation
Payment aggregator settlement files — from Razorpay, PayU, Cashfree, Paytm for Business, and IATA BSP for travel agencies — arrive with multi-tier deductions embedded: MDR, GST on MDR, TCS at 1% under section 206C(1H), and platform fee. Each deduction must be matched against the original transaction, classified by deduction type, and reconciled against the ledger entry for that settlement cycle. TransactIG's platform settlement reconciliation pattern handles this as a structured variance taxonomy — not a raw exception flag.
NACH batch and direct debit reconciliation
NBFC lenders, subscription businesses, and utility providers collecting via NACH mandates receive daily return files from NPCI. Each NACH return code — R01 through R10 — requires a different handling path: retry, customer contact, mandate status update, or write-off. Reconciling NACH collections against the expected payment schedule, with partial recovery handling and mandate-level tracking, requires a reconciliation pattern that understands mandate structure. This is not a general-purpose bank reconciliation problem and is not addressed by any ERP-native reconciliation module.
How TransactIG's four-pass matching engine works
Most reconciliation tools apply a single matching pass — exact reference match, or the transaction enters an unmatched queue. TransactIG applies four sequential resolution passes, each recovering a different class of match that the previous pass could not resolve.
Exact reference matching
UTR number, cheque number, or payment reference matched exactly between both data sources. Confidence score: 1.00. No tolerance applied. This pass resolves the majority of high-volume, well-structured transactions — approximately 51% of a standard enterprise transaction set.
Fuzzy and partial reference resolution
Partial UTR match, whitespace normalisation, prefix and suffix stripping, and format standardisation. Resolves transactions where the reference has been truncated by the bank's core banking system, entered with a typo at source, or padded with leading zeros in the ERP.
Signal-weighted composite matching
A confidence score is computed from five weighted signals: UTR (0.40), partial reference (0.25), counterparty name (0.15), transaction date proximity (0.10), payment mode (0.05), and amount variance (0.05). Matches above the configured confidence threshold are auto-accepted. Matches below threshold enter the human review queue with the full signal breakdown.
Tolerance-based reconciliation
For items that passed confidence scoring but carry a residual amount difference, tolerance bands are applied: ₹1 for rounding differences, configurable percentage bands for TDS deductions, and fixed-amount tolerance for platform fee deductions. Items within tolerance are classified by variance code and auto-closed. Items outside tolerance enter the exception queue.
Validated result: On a 781-row test pack drawn from real Indian enterprise transaction data, the four-pass engine resolved 51% of transactions in Pass 1, with cumulative automated match rate reaching 88% after all four passes. The remaining 12% entered structured exception queues for human review — not an unclassified unmatched pile.
Which Indian industries use reconciliation software — and why
TransactIG is configured for 24 Indian industry verticals. The primary reconciliation driver differs by sector — but the underlying pattern is consistent: high transaction volume, multiple data sources, and India-specific compliance obligations that generic tools do not address.
| Industry | Primary reconciliation drivers |
|---|---|
| Healthcare & Hospitals | TPA claim reconciliation, pharmacy GST input credit, lab NACH collection matching |
| IT Services & SaaS | TDS on professional fees vs Form 26AS, multi-currency invoice reconciliation, subscription platform settlement |
| Hotels & Hospitality | OTA channel settlement (MakeMyTrip, Booking.com), GST on accommodation tariff, restaurant GST input |
| Logistics & Transport | Freight billing vs purchase order, TDS on contractor payments, fuel GST input credit |
| NBFC & Lending | EMI collection NACH reconciliation, interest income TDS matching, co-lending settlement |
| Retail & E-Commerce | Marketplace settlement (Amazon, Flipkart, Meesho), payment gateway settlement, GST input credit on purchases |
| Staffing & Manpower | Multi-client invoice aggregation, TDS on contract staffing, PF and ESI deduction reconciliation |
| Education | Fee collection NACH mandate returns, GST on non-exempted programmes, scholarship disbursement matching |
Key features to evaluate in Indian reconciliation software
This checklist is designed for finance controllers and IT evaluators conducting a structured assessment. Each question below should be asked of every vendor — including us.
Configurable matching rules — not hardcoded logic
Matching rules should be configurable without code changes or vendor involvement. Your bank's UTR format, your ERP's reference convention, and your payment gateway's settlement structure are specific to your operations. A reconciliation engine that requires a support ticket to change a matching rule is not configurable — it is customised. Ask vendors: how do I change a matching rule myself, and how long does it take?
Structured variance taxonomy — not just exception flagging
An exception flag tells you something did not match. A variance taxonomy tells you why — and what the resolution path is. TransactIG classifies every exception into a defined code: FEE_DEDUCTION, TAX_DEDUCTION, DISCOUNT_APPLIED, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, or UNEXPLAINED. Finance teams review exceptions by type and resolution path — not transaction by transaction.
Full audit trail — not just version history
Statutory audit and internal audit require a complete record of who matched what, when, and on what basis. This means time-stamped logs for every auto-match, every manual override, and every exception reclassification — linked to the specific user and the specific evidence. Version history in a shared spreadsheet does not meet this requirement. Ask vendors: can I export a complete audit log for a specific transaction from the prior financial year?
India-specific integrations — TRACES, GSTN, Indian banks, Indian aggregators
Verify native support for: TRACES exports (TDS reconciliation), GSTR-2B portal data (GST input credit), major Indian bank statement formats (HDFC, ICICI, Axis, Kotak, SBI), and Indian payment aggregators (Razorpay, PayU, Cashfree). Generic ERP reconciliation modules built outside India rarely include these connectors. Confirm whether each integration requires ongoing vendor support or is self-configurable.
Reconciliation software vs spreadsheet-based reconciliation
Spreadsheet reconciliation is not wrong at low volumes. It becomes a liability above 10,000 transactions per month, or when compliance obligations require documented evidence trails that survive an audit query.
| Dimension | Spreadsheet approach | TransactIG |
|---|---|---|
| Setup time | 0 (already in use) | 2–4 weeks, one-time configuration |
| Monthly effort | 3–5 staff days per month | Exception review only — typically under 4 hours |
| TDS / Form 26AS | Manual TRACES download + VLOOKUP | Automated match at PAN + quarter level with variance codes |
| GST / GSTR-2B | Manual portal export + manual comparison | Automated comparison with blocked credit identification |
| Audit trail | Version history only — no per-action log | Every match, override, and exception time-stamped with user identity |
| Scale ceiling | Performance degrades beyond 10,000 rows | Linear scaling — same engine at 10,000 or 10,00,000 rows |
| Exception resolution | Raw unmatched pile — no classification | Structured exception queue by variance type and resolution path |
Security and data residency for Indian enterprise
TransactIG is ISO 27001:2022 certified — the current revision, covering all 93 controls including the 11 new controls for cloud security, data masking, data leakage prevention, and secure coding practices.
All client financial data is processed and stored on AWS Mumbai (ap-south-1). No data leaves Indian data centre boundaries. Infrastructure runs on multi-AZ deployment with no single point of failure and daily encrypted backups with quarterly restoration testing.
Data at rest is encrypted with AES-256 via AWS KMS. All data in transit uses TLS 1.2 or higher. Client environments are isolated at the tenant level — cross-client data access is not architecturally possible.
Deployed in 2 to 4 weeks — no code required
TransactIG deploys through configuration, not customisation. The matching engine, variance taxonomy, and exception workflow are pre-built. What changes per client is configuration: field mappings, matching rule parameters, tolerance bands, and integration connectors.
How reconciliation software works
Reconciliation software replaces the manual cycle of downloading statements, building VLOOKUP formulas, and chasing open items through email threads. The process breaks down into three stages that run sequentially each reconciliation cycle.
Data ingestion from banks, portals, and gateways
The system connects to your data sources — bank statement feeds via SFTP, Form 26AS exports from the TRACES portal, GSTR-2B downloads from the GST portal, settlement files from payment gateways like Razorpay and PayU, and ledger exports from your ERP (Tally, SAP, Oracle NetSuite, Zoho Books). Each source is parsed into a standardised transaction schema. Field mapping is configured once during implementation and handles format variations across banks, gateways, and ERP systems automatically. For organisations with 3 or more data sources, this step alone eliminates 6 to 10 hours per month of manual data preparation.
Automated matching with tolerance bands
The matching engine compares records across data sources using configurable rules — not a single-field VLOOKUP. TransactIG applies a four-pass matching process: exact reference match, fuzzy reference resolution, signal-weighted composite scoring, and tolerance-based reconciliation. Tolerance bands are configured per reconciliation type: rounding differences under ₹1 are auto-closed, TDS rate variances within 0.1% are flagged as ROUNDING, and platform fee deductions within the contracted MDR range are classified as FEE_DEDUCTION. Each match carries a confidence score and a complete audit trail of which pass resolved it and which signals contributed.
Exception classification and resolution
Unmatched items are not dumped into a single unresolved pile. Each exception is classified by variance type — TAX_DEDUCTION, FEE_DEDUCTION, DISCOUNT_APPLIED, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, ROUNDING, or UNEXPLAINED — and routed to the appropriate resolution workflow. Finance teams review exceptions by category and resolution path rather than row by row. A team handling 15,000 monthly transactions typically reviews 1,500 to 1,800 exceptions across all categories, with resolution effort concentrated on UNEXPLAINED items (typically 3 to 5% of total transactions). The remaining exception types follow defined resolution paths that require verification, not investigation.
ROI of reconciliation software
The return on reconciliation software is not a theoretical efficiency gain. It is measurable in four categories, each with a specific financial impact that can be quantified against your current cost base.
Staff time recovered: 3 to 5 days per month
A finance team of 3 to 4 people manually reconciling bank statements, TDS entries, GST data, and platform settlements spends 3 to 5 working days per month on reconciliation activities — data downloads, formula maintenance, exception investigation, and email follow-ups. At an average cost-to-company of ₹8 to ₹12 lakh per annum per analyst, this represents ₹1.2 to ₹2.5 lakh per month in recoverable staff cost. Automated reconciliation reduces this to exception review only — typically under 4 hours per cycle.
TDS credit recovery: 2% of receivables at risk
Unreconciled TDS credits — where the deductor has deducted TDS but the Form 26AS entry is missing, incorrect, or filed under the wrong PAN — represent approximately 2% of total receivables for services businesses. On ₹100 crore annual revenue subject to TDS deduction, this is ₹20 lakh in credits at risk of non-recovery each year. Monthly reconciliation against Form 26AS identifies these within the deductor's correction window, before the ITR filing deadline closes the recovery path.
Penalty and interest avoidance
Late TDS deposit attracts interest at 1.5% per month under Section 201(1A) of the Income Tax Act. GST ITC claimed without GSTR-2B support triggers interest at 18% per annum under Section 50 of the CGST Act. DRC-01C notices for ITC mismatches require a response within 7 days — failure to respond results in liability confirmation. Platform dispute windows are equally time-bound: Amazon SAFE-T claims expire at 90 days, Flipkart disputes at 60 days. Automated reconciliation ensures every compliance window is identified and acted upon within the available response period.
Based on a mid-market services company with ₹50 crore annual revenue, 3 payment gateways, and a 4-person finance team. Actual recoverable amounts vary by transaction volume, supplier mix, and existing reconciliation maturity.
Who needs reconciliation software
Not every business needs dedicated reconciliation software. Below a certain volume and complexity threshold, a well-maintained spreadsheet process is adequate. The inflection point is identifiable — these are the qualification criteria that indicate when manual reconciliation becomes a liability rather than a cost-effective choice.
500+ monthly transactions across 2 or more sources
Below 500 transactions per month from a single source, manual reconciliation using spreadsheets is tractable within a reasonable time window. Above this threshold — particularly when transactions arrive from multiple sources such as bank statements, payment gateways, and marketplace settlements — the combinatorial matching problem exceeds what VLOOKUP-based reconciliation can handle reliably. At 5,000 monthly transactions across 3 sources, manual reconciliation typically consumes 3 to 4 full working days per month.
3 or more data sources requiring reconciliation
Each additional data source introduces a new file format, a new settlement timing cycle, and new deduction types. Businesses reconciling only bank statements against a single ledger can manage with ERP-native tools. Once you add a payment gateway (Razorpay, PayU), a tax portal (TRACES, GSTN), and a marketplace (Amazon, Flipkart), the reconciliation problem becomes a multi-source matching challenge that requires a purpose-built engine — not a collection of separate spreadsheets.
Multiple compliance obligations: TDS + GST + NACH
Each Indian compliance regime — TDS deduction matching against Form 26AS, GST ITC verification against GSTR-2B, NACH mandate return code classification — has its own data source, its own matching logic, and its own exception taxonomy. A business subject to all three is running three parallel reconciliation processes, each with its own deadline, penalty structure, and audit trail requirement. Unifying these under a single reconciliation engine eliminates process duplication and ensures nothing falls through between separate workflows.
Month-end close exceeding 5 working days
If your finance team takes more than 5 working days to close the books each month, reconciliation is likely the bottleneck. The close process depends on all reconciliations being completed, all exceptions being resolved or documented, and all variance explanations being recorded before the trial balance is finalised. Automated reconciliation reduces the reconciliation phase from 3 to 5 days to under 4 hours of exception review, compressing the total close window and giving management earlier visibility into the financial position.
Frequently asked questions about reconciliation software in India
What is reconciliation software?
Reconciliation software is a purpose-built system that automatically compares financial records from two or more sources — such as bank statements, ERP ledgers, payment gateway settlement files, and TDS certificates — and identifies matches, variances, and exceptions. Unlike manual spreadsheet-based reconciliation, purpose-built software applies configurable matching rules, tolerance thresholds, and structured exception taxonomy at scale. The output is a classified exception queue, not a raw dump of unmatched rows.
Why do Indian businesses need specialised reconciliation software?
India's compliance landscape introduces reconciliation requirements that generic tools do not handle. TDS deducted by clients must be matched against Form 26AS entries from the TRACES portal. GST input credit claimed must match GSTR-2B data from the GST portal. Platform settlements from aggregators like Razorpay or PayU embed multi-tier deductions — MDR, GST on MDR, TCS, and platform fees — each requiring separate classification. Generic ERP reconciliation modules built outside India rarely address any of these natively.
How does automated reconciliation handle TDS mismatches?
TransactIG's TDS reconciliation module compares invoiced TDS expectations against Form 26AS entries at the PAN and quarter level. The engine classifies each mismatch into a defined variance code — TAX_DEDUCTION for shortfall, ROUNDING for sub-₹10 differences, UNEXPLAINED for items requiring manual review — and holds each exception in a structured queue with a full evidence trail. Finance teams resolve exceptions by type and resolution path, not row by row.
How long does reconciliation software implementation take?
TransactIG deployments typically complete in 2 to 4 weeks. The first week covers configuration — ERP field mapping, matching rule setup, and tolerance band definition. The second week covers integration testing with live bank feeds, ERP exports, and payment gateway files. The third week runs TransactIG in parallel with the existing process. The fourth week is production cutover. There is no code development in this timeline. All changes to matching rules and configuration are made by the client without vendor involvement.
What ERP and payment gateway integrations does TransactIG support?
TransactIG connects to SAP, Oracle NetSuite, Tally Prime, Zoho Books, Busy Accounting, and Microsoft Dynamics via structured data export. Payment gateways supported include Razorpay, PayU, Cashfree, Paytm for Business, and CCAvenue. Bank integration covers all major Indian banks via SFTP statement feed or CSV upload. Custom integrations can be configured via field mapping templates without code changes.
Is reconciliation software suitable for mid-size Indian businesses?
TransactIG is designed for organisations processing 10,000 or more transactions per month across two or more data sources. Below this volume, structured reconciliation software provides limited additional value over well-maintained spreadsheets. Above this threshold — particularly when TDS, GST, or platform settlements are involved — the cost of manual reconciliation in staff time and unrecovered credits typically exceeds the software cost within the first quarter of deployment.
See reconciliation software configured for your workflow
We map a working demo to your specific reconciliation patterns — TDS, GST, platform settlement, or NACH — before the first call. Most sessions take 45 minutes.