Reconciliation Software Implementation: What to Expect in 30-60-90 Days

howToSteps:

• name: “Scope Use Cases and Data Sources” text: “In days 1–10, document every reconciliation stream in scope — bank accounts by institution, TDS streams by section, GSTR-2B, payment gateways, NACH mandates. Identify each source system and confirm the file format and delivery mechanism for bank statements, ERP exports, TRACES challan files, and GSTN JSON downloads.”
• name: “Run Sample Data Quality Review” text: “In days 11–20, load three months of historical data and identify narration inconsistencies, missing UTRs, duplicate entries, and format anomalies. Map HDFC/ICICI/SBI bank statement format variations and document normalisation rules needed for each. Begin counterparty master data cleanup for PAN and GSTIN fields.”
• name: “Configure Matching Rules and Tolerances” text: “In days 21–30, finalise the matching rule configuration document covering the signal hierarchy per stream (UTR as strongest, followed by partial reference, counterparty, date), tolerance thresholds for TDS netting and MDR deductions, and variance codes (FEE_DEDUCTION, TAX_DEDUCTION, ROUNDING, PARTIAL_PAYMENT). Get the document approved before configuration begins.”
• name: “Run First Parallel Month and Train Team” text: “In days 31–60, configure the matching engine against sample data and begin the parallel run alongside the existing manual process. Configure the exception review workflow and complete team training on the dashboard and override procedures — typically two to three sessions — so the team can process the exception queue without vendor support.”
• name: “Validate Second Parallel Month” text: “In days 61–80, run the engine against a second complete monthly dataset with any configuration adjustments from month one applied. Compare match rates across both months and confirm they meet the contractual target of 70–85% on each configured stream.”
• name: “Sign Off Match Rate and Go Live” text: “In days 81–90, execute the formal match rate sign-off document confirming match rates by stream and exception volumes. Retire the manual process for all signed-off streams. The first automated month-end close using the platform is the operational go-live milestone.”

Reconciliation software implementation India follows a more predictable pattern than most enterprise software projects because a configuration-based platform does not require custom code development. The implementation is discovery, configuration, and testing — not build, test, and deploy. This article is for Finance Heads and IT Heads who are managing or about to manage an implementation project and need a clear 30-60-90 day framework, milestone structure, and sign-off criteria. By the end, you will know what each phase requires from the finance team, what the most common delay causes are, and what India-specific data quality issues to anticipate.

What a Configuration-Based Implementation Involves

The distinction between configuration and custom development matters more in reconciliation software than in most enterprise applications. A configuration-based reconciliation software India deployment adjusts matching rules, signal priorities, tolerance thresholds, and workflow routing within the platform’s existing architecture. No code is written for the client. The implementation team’s job is to understand the client’s transaction types and translate them into the platform’s configuration options.

This is why the 2–4 week timeline is achievable for a single-stream deployment. There is no development sprint, no code review, and no release cycle. Configuration changes can be applied and tested within hours. When a matching rule needs to be adjusted because a new counterparty uses a non-standard UTR format, the change is a configuration update, not a development ticket.

For Finance Heads evaluating whether a 30-60-90 day timeline is realistic, the critical question is not “how fast does the vendor work?” — it is “how clean is our source data, and how many streams are we configuring?” Both factors are under the finance team’s control.

Why Implementation Projects Slip

The ERP Export Format Problem

A common cause of delayed reconciliation software implementations is discovering mid-project that the ERP export format requires custom transformation — configuration-based platforms that ingest standard formats (MT940, CSV, XLSX) avoid this. When ERP exports arrive in proprietary formats, or when the ERP configuration has been customised to produce non-standard field layouts, the implementation team must build a transformation step before the matching engine can run.

This problem is avoidable with a thorough data source inventory in the first two weeks. If the ERP export format is confirmed as standard-compatible before configuration begins, the implementation timeline holds.

Data Quality Issues in Indian Bank Statement Formats

Indian bank statement formats introduce narration inconsistencies that are not present in international bank feeds. HDFC Bank MT940 exports use narration structures that differ across account types and product lines. ICICI Bank statement CSV exports have changed narration delimiters across different export versions. SBI MT940 files use narration truncation rules that cut off the UTR reference at 35 characters, which means the full UTR is only recoverable from the structured field, not the free-text narration.

These are known issues, but they require configuration rules that are specific to each bank and account type. An implementation that does not inventory all bank accounts and test their statement formats in the first 30 days will discover these issues during the parallel run — which is the worst time to address them, because it delays the sign-off cycle.

Incomplete Counterparty Master Data

TDS and GSTR-2B matching requires PAN and GSTIN data for counterparties. Enterprises with incomplete or inconsistent counterparty master data in their ERP will find that reconciliation match rates on these streams are lower during the parallel run than the engine is capable of achieving. Counterparty master data cleanup is a finance team task, not a vendor task, and it needs to begin in days 1–30 to be complete by the time the parallel run starts.

The 30-60-90 Day Implementation Framework

Days 1–30: Discovery and Data Mapping

The first thirty days are the most important phase of the implementation. The output of this phase is a complete picture of the client’s reconciliation scope: which transaction streams are in scope, what the source data looks like, what the matching rules should be, and where the data quality problems are.

Use case scoping is the first activity. The implementation team documents every reconciliation stream in scope: bank accounts by institution, TDS streams by section, GSTR-2B against the purchase register, payment gateway by processor, NACH by mandate pool. Each stream has a separate configuration within the engine, and the scope needs to be agreed before configuration begins.

Data source inventory follows. Every source system is identified — ERP for the book entries, each bank for statements, GST portal for GSTR-2B, payment processors for settlement reports, and TDS challan files from the TRACES portal. The format, frequency, and delivery mechanism of each source file is documented.

Sample data quality review is the critical activity. Three months of historical data is loaded, and the implementation team identifies narration inconsistencies, missing UTRs, duplicate entries, and format anomalies. For HDFC/ICICI/SBI formats specifically, narration normalisation rules are documented at this stage.

Matching rule configuration for primary transaction types begins once data quality is understood. The configuration covers the signal hierarchy applicable to each stream (UTR as the strongest signal, followed by partial payment reference, counterparty name, and date), the tolerance thresholds for fee and tax deductions, and the variance codes (FEE_DEDUCTION, TAX_DEDUCTION, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, UNEXPLAINED) applicable to each exception type.

Sign-off criteria for days 1–30: Source data inventory complete, sample data quality report reviewed and accepted, matching rule configuration document approved, counterparty master data cleanup task assigned with owner and deadline.

Days 31–60: Configuration and Parallel Run

The middle thirty days move from design to operation. The matching engine runs against live data for the first time, alongside the existing manual process.

Matching engine configuration is finalised and tested against the sample data. The multi-pass pipeline — exact match, composite-signal, tolerance matching, and many-to-many aggregation — is configured for each in-scope stream. Match rates on the historical sample data are reviewed against the contracted target of 70–85%.

Exception review workflow is configured. The workflow covers how unmatched transactions are routed to the relevant finance team member, what information is displayed in the exception queue, and how manual overrides are recorded and attributed.

Team training on the dashboard and override procedures happens during this phase. The finance team members who will operate the platform daily need to be able to process the exception queue independently before the parallel run sign-off. This typically takes 2–3 sessions of 1–2 hours each.

Parallel run operation begins as soon as the engine is configured. Both the reconciliation engine and the existing manual process run simultaneously for the same transaction data. Discrepancies between the two outputs are reviewed to identify configuration gaps.

Sign-off criteria for days 31–60: Parallel run match rates meet the contractual target on at least one complete monthly dataset, exception workflow is operating with zero vendor assistance required, team training complete.

Days 61–90: Parallel Run Validation, Go-Live, and Retirement

The final thirty days validate the parallel run across a second complete monthly cycle and execute go-live.

Parallel run validation runs the engine against the second month of live data. This month typically produces higher match rates than the first, as any configuration adjustments identified during the first parallel run month are applied.

Match rate sign-off formalises the contractual match rate target against the validated output. The sign-off document confirms the match rate on each configured stream, the exception volume, and the average time to process the exception queue.

Go-live retires the existing manual process for the signed-off streams. The engine becomes the system of record for reconciliation output. The first fully automated month-end close using the platform is the operational milestone.

Sign-off criteria for days 61–90: Two complete monthly parallel runs completed, match rate targets confirmed, exception workflow stable, team able to operate independently, formal go-live sign-off executed.

Implementation Milestone Tracker

The India-Specific Data Quality Issues to Anticipate

HDFC Bank MT940 narration inconsistencies: HDFC MT940 exports use different narration structures for RTGS, NEFT, IMPS, and UPI transactions within the same statement. The UTR field appears in the structured data block for RTGS and NEFT, but is embedded in the free-text narration for some UPI transactions. Configuration rules must handle both cases to avoid UTR mismatches.

ICICI Bank CSV format variations: ICICI Bank’s online banking portal has exported statements in at least three different CSV column layouts across major format revisions. An enterprise that has been downloading statements for several years may have files in multiple formats. The implementation data quality review must identify which format versions are present across the historical data set.

SBI MT940 narration truncation: SBI MT940 files truncate the narration field at 35 characters in the free-text field. For RTGS transactions where the full UTR is 22 characters and the beneficiary name follows, the narration is often sufficient. For transactions where additional reference information follows the UTR, the narration is cut. The UTR must be extracted from the structured field (field tag :86:) rather than the free-text narration, which requires a specific configuration rule.

GST portal export formatting differences: GSTR-2B JSON exports and Excel exports have different field structures across GST portal version updates. The JSON format is the more reliable option for machine processing, but some enterprises work with the Excel export by default. The implementation should standardise on JSON format from day one.

TDS challan CSV format variations: TDS challan files downloaded from TRACES use a CSV format that has changed with TRACES platform updates. Column ordering and date format have varied across versions. The data quality review should include a version check on challan files in the historical data.

What the Configuration Model Changes for Indian Enterprises

The configuration-only model means that every India-specific format change — a new bank statement layout, a TRACES CSV format update, a GSTR-2B JSON schema change — is handled by a configuration update rather than a development cycle. This matters more for Indian enterprises than for international ones because the frequency of statutory format changes in India is high.

TDS reconciliation software that operates on a configuration model can incorporate a new TDS deduction section or a revised Form 26AS format within the same 2–4 week window that the initial deployment uses — because the work is the same type of work. This means the total cost of ownership over a 3-year horizon includes format maintenance that would otherwise be a recurring development expense.

The 24+ industry presets available on the platform encode the most common Indian reconciliation patterns — bank, TDS, GSTR-2B, NACH, payment gateway, intercompany — without requiring custom configuration from scratch for each. For most mid-size Indian enterprises, the preset closest to their transaction profile is the starting point, and the discovery conversation identifies the customisations required on top of it.