Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
What Bank Reconciliation Is — and What It Is Not
Bank reconciliation is the process of verifying that your internal cash ledger and the bank's record of your account activity are in agreement. Differences exist by design — timing differences, outstanding cheques, deposits in transit — and the reconciliation statement's purpose is to account for those differences and confirm that the underlying records are accurate.
What bank reconciliation is not: it is not a shortcut to verifying revenue completeness, it is not a substitute for accounts receivable matching, and it is not a sufficient control against payment fraud on its own. It is one component of a complete financial close process — necessary but not sufficient by itself.
For Indian enterprises, the bank reconciliation process is more demanding than in most other markets because of the diversity of payment instruments: NEFT, RTGS, IMPS, UPI, NACH, NACH debit mandates, cheque clearing, and payment gateway settlement credits all appear in the same bank statement and require different matching logic. A single bank account at a mid-size Indian enterprise can generate 1,000 to 5,000 line items per month.
Why Enterprise Bank Reconciliation Is More Complex
Multiple bank accounts with different transaction profiles
A typical enterprise operates 3 to 10 current accounts: an operating account for vendor payments, a collections account for customer receipts, a payroll account, an escrow account for RERA or similar obligations, and possibly foreign currency accounts for import or export settlements. Each account has a different transaction profile and requires a different matching configuration. Treating them identically in a single spreadsheet is a common source of reconciliation errors.
Payment gateway credits as batch aggregates
When a payment gateway settles to the bank account, the credit is a single net amount — not 200 individual customer payments. The bank statement shows one entry; the underlying transactions are in the gateway settlement file. Bank reconciliation that stops at matching the bank credit to the gateway settlement total is incomplete — it confirms that money arrived, not that it arrived for the right orders in the right amounts.
NACH and ECS collection batches
For organisations that use NACH (National Automated Clearing House) for recurring collections — EMI collections, subscription billing, insurance premiums — the bank statement shows a NACH credit equal to the net of successful and failed mandates in the batch. Return mandates (failed debits) appear as separate debit entries, sometimes on a different date than the original credit. Matching NACH credits and returns to the underlying mandate-level records requires a separate NACH reconciliation process that sits above the basic bank reconciliation level.
Inter-company transfers and holding account entries
Enterprises with multiple legal entities or branches regularly transfer funds between accounts. These transfers must be mirror-booked in both entities' ledgers on the same date to avoid creating an unexplained difference in each entity's bank reconciliation. When the transfer date in one entity's books differs from the other — even by one day due to a cut-off difference — the difference appears as an unexplained item in both reconciliations until it is identified and corrected.
The Standard Bank Reconciliation Process
Regardless of volume, the bank reconciliation process follows the same logical sequence. The enterprise version differs in the data volume, the diversity of transaction types, and the number of parallel workflows required.
Step 1 — Obtain bank statement in structured format
Download bank statements for the reconciliation period via net banking portal or SFTP feed (most major Indian banks support SFTP-based MT940 or CAMT.053 format for enterprise accounts). The statement should include: date, value date, transaction reference, description, credit/debit indicator, and running balance. The distinction between transaction date and value date is material for NEFT/RTGS entries where the value date may differ by one day.
Step 2 — Extract cash and bank ledger from ERP
Extract the bank account ledger from your ERP for the same period. If the ERP uses a cashbook approach, extract the cashbook entries. Ensure that the ERP export includes the narration or reference field — without this, matching against the bank statement description is impossible. Many ERP implementations have a mismatch between the reference captured at the time of booking and the UTR (Unique Transaction Reference) that appears in the bank statement.
Step 3 — Match using UTR and transaction reference
The primary matching key for NEFT/RTGS/IMPS transactions is the UTR. For UPI, the UPI reference number serves the same function. For cheque payments, the MICR number or cheque number is the matching key. Match each bank statement entry to the corresponding ERP ledger entry. Where an exact match exists on reference and amount, mark as reconciled. Where no match exists, classify as either a timing difference (in bank, not yet in ERP — or vice versa) or a genuine exception requiring investigation.
Step 4 — Document and resolve exceptions
Each exception falls into a category: outstanding payment (ERP entry without corresponding bank credit or debit), outstanding deposit (bank credit without ERP entry), bank charge not booked, or unexplained entry requiring investigation. Resolve each category through the appropriate path — follow-up with bank for unexplained entries, book the unrecorded charges, and flag the outstanding items for aging analysis if they exceed a defined threshold.
What Structured Bank Reconciliation Software Changes
The bank reconciliation process at enterprise scale is not bottlenecked by the matching logic — it is bottlenecked by data preparation, format normalisation, and exception classification. Automated bank reconciliation addresses all three.
Data ingestion: Bank statement feeds (SFTP MT940 or direct upload) and ERP exports are ingested and normalised automatically. No manual reformatting required.
Multi-signal matching: Instead of matching only on UTR (which fails for payment gateway credits, cheques, and inter-company transfers), the engine applies amount + date + partial reference matching. TransactIG's matching engine assigns confidence scores to each potential match — a score ≥0.55 is accepted within tolerance, a score <0.25 requires exact match only, and entries between these thresholds are held for manual review.
Exception queue structure: Exceptions are not presented as a raw unmatched list. They are classified by type (timing difference, bank charge, unexplained debit, gateway reconciliation required) and routed to the appropriate resolution workflow. The output is a structured exception inventory, not a pile of rows.
See the reconciliation software guide for a full comparison between spreadsheet-based and purpose-built bank reconciliation approaches, and how TransactIG handles the combined bank + TDS + GST + platform settlement workflow for 24 industries.
The Institute of Chartered Accountants of India (ICAI) publishes guidance on bank reconciliation as part of its auditing standards, which sets the baseline expectation for what constitutes an adequate reconciliation process for statutory audit purposes.
Common Bank Reconciliation Errors
Bank reconciliation errors fall into distinct categories, each requiring a different detection method and resolution approach. Treating all errors as generic "unmatched entries" delays resolution and obscures the root cause.
- ▸ Transposition errors: Digits reversed during manual data entry — ₹23,450 recorded as ₹23,540. These create small differences that pass cursory review but compound over hundreds of entries. Detection requires amount-proximity matching, not exact matching.
- ▸ Omission errors: Bank charges, NEFT/RTGS fees, and account maintenance charges debited by the bank but not recorded in the company books. For accounts with 500+ monthly transactions, unrecorded bank charges can total ₹15,000-₹50,000 per month.
- ▸ Timing differences: Cheques issued but not yet presented for clearing, NEFT credits initiated but not yet received, or NACH debits processed on the following business day. These are not errors — they are expected differences that must be documented and aged.
- ▸ Duplicate entries: The same payment recorded twice in the ERP due to manual booking of an auto-posted entry, or a bank credit appearing twice due to a system glitch. Duplicate detection requires matching on amount + date + approximate reference.
- ▸ Narration truncation: Bank statement narrations are often truncated at 20-25 characters, while ERP reference fields may store 30-40 characters. A 22-character UTR number may be truncated in the bank statement, making exact string matching fail. HDFC truncates differently from ICICI and SBI, requiring bank-specific parsing rules.
The narration truncation problem is particularly acute in India because UTR numbers (16 or 22 digits depending on the payment channel) are the primary matching key, and different banks format them differently within the narration field. An SAP system that stores a full 22-character UTR will fail to match against an HDFC statement that truncates it to 18 characters in the description field.
Manual vs Automated Bank Reconciliation
| Dimension | Manual (Spreadsheet) | Automated (Structured Software) |
|---|---|---|
| Time per month | 3-7 staff days | 85% faster — exception review only |
| Error rate | 15-25% undetected mismatches | 95%+ match rate with multi-signal logic |
| Audit trail | No structured trail — spreadsheet versions | Full audit trail with match reasoning and user identity |
| Multi-bank handling | Separate template per bank | Unified normalisation layer across banks |
| Exception classification | Raw unmatched list | Structured exception queue by type and priority |
The threshold for transitioning from manual to automated bank reconciliation is typically 500+ monthly transactions or 3+ bank accounts. Below this threshold, a well-structured spreadsheet process is adequate — the time investment in setting up automated reconciliation is not justified by the volume. Above this threshold, the manual process produces errors faster than the team can resolve them, and the cost of undetected mismatches exceeds the cost of the tooling.
For a detailed comparison of reconciliation approaches, see the manual vs automated reconciliation guide.
Bank-Specific Reconciliation in India
Indian banks do not follow a uniform standard for statement narration formats, reference field placement, or MT940 field usage. Reconciliation logic that works for HDFC Bank will not work for ICICI Bank or SBI without bank-specific configuration. This is a structural issue, not a tooling limitation.
HDFC Bank uses a structured narration format for NEFT/RTGS transactions that typically includes the UTR number followed by the remitter name. MT940 statements from HDFC place the transaction reference in Field 61 and additional details in Field 86. However, UPI transactions in HDFC statements use a different narration pattern — the UPI reference number is embedded within a longer narration string that varies by transaction type.
ICICI Bank uses a different narration structure where the UTR number may appear at a different position in the description field, and the bank often appends its own internal reference codes. ICICI's MT940 implementation uses Field 86 sub-fields differently from HDFC, which means that a parser configured for HDFC MT940 will misread ICICI statement data.
SBI (State Bank of India) has the most significant formatting challenges due to the volume of legacy systems involved. SBI narrations for NEFT credits may truncate the UTR number or include additional prefix codes. Statement delivery methods also vary — SBI enterprise accounts may deliver statements via e-mail in PDF format rather than MT940, requiring OCR or manual extraction before reconciliation can begin.
For organisations operating across multiple banks, these format differences mean that a single reconciliation template is insufficient. Each bank requires its own parsing configuration for narration extraction, reference field mapping, and date format handling. TransactIG includes pre-built parsing templates for all major Indian banks. For bank-specific guidance, see our detailed articles on HDFC bank reconciliation, ICICI bank reconciliation, and SBI bank reconciliation.