Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
A lending company processes 12,000 EMI collections per month from borrowers using NACH mandates and NEFT payments. Before virtual accounts, the treasury team spent 8 days per month manually matching NEFT credits to borrower accounts — many borrowers paid from different accounts, with narrations like “EMI payment” or their name that did not always match the loan account number.
After deploying virtual accounts — one per borrower — the same 12,000 collections reconcile in under 2 hours: every NEFT credit arrives tagged to the correct borrower, and the LMS is updated automatically via the bank’s webhook.
How Virtual Accounts Work in India
A virtual account number is a unique identifier within a bank’s payment routing system. The bank maintains a mapping table: VAN → physical account + customer identifier. When a payment arrives at the VAN, the bank:
- Receives the NEFT/RTGS credit at the physical account
- Identifies the VAN from the payment reference
- Tags the credit with the customer identifier
- Generates a webhook event with the VAN, UTR, amount, and payer details
- Credits the physical account
The reconciliation system receives the webhook and:
- Looks up the customer assigned to this VAN
- Creates the receipt in the AR/LMS system
- Attempts to match the receipt to an open invoice or EMI instalment
- If matched: closes the record and sends confirmation
- If unmatched: flags for allocation review
Virtual Account Types and Use Cases
| VA type | Issued by | Primary use case | Settlement |
|---|---|---|---|
| Bank CMS VANs | HDFC, ICICI, Yes Bank, Axis | B2B invoice collections | Real-time (T+0) |
| Payment gateway VANs | Razorpay, PayU, Cashfree | SME collections, marketplace payouts | T+1 (batch) |
| NACH collection VANs | Banks / NBFC platforms | Loan EMI, insurance premium | T+1 (post-batch) |
| Escrow VANs | Regulated entities only | Marketplace, RERA | Per RBI escrow guidelines |
Reconciliation Events and Failure Modes
Successful VAN Match
Customer assigned to VAN 40023981XX pays ₹45,000. The webhook fires with VAN 40023981XX, UTR HDFCR2026031512345, amount ₹45,000. The reconciliation system matches to open invoice INV-2026-0234 for ₹45,000. Invoice closed. AR updated. Customer notification sent.
VAN Credit with Amount Mismatch
Same VAN, same customer, pays ₹40,500 (10% TDS deducted on ₹45,000). The webhook fires with ₹40,500 — does not exactly match the invoice of ₹45,000. The reconciliation system applies the TDS detection rule for this customer (Section 194J, 10%) and determines: ₹40,500 = ₹45,000 − 10% TDS. Match: gross invoice ₹45,000 = VAN credit ₹40,500 + TDS receivable ₹4,500. Invoice closed. TDS receivable created.
Webhook Failure
The bank’s webhook system experiences a timeout. The VAN credit appears in the bank statement but no webhook was received. The reconciliation system must have a fallback: periodic polling of the bank statement to identify VAN credits that did not generate a webhook event. Any credit tagged to a VAN that has no corresponding webhook entry is flagged for investigation.
Wrong VAN Used
Customer of Company A pays on the VAN assigned to Company B (wrong digit in the VAN). The credit is routed to Company B’s physical account and tagged to a customer who did not make this payment. Detection: the attributed customer’s account shows no open invoice matching the amount. Resolution: bank’s VAN reversal process — credit is reversed and re-routed to the correct VAN. Timeline: 1–3 business days.
VAN Housekeeping for Clean Reconciliation
Virtual account reconciliation accuracy depends on the quality of the VAN register:
- Unique assignment: Each customer should have exactly one VAN. Shared VANs break the automatic attribution.
- Inactive VAN management: When a customer account is closed, the VAN should be deactivated to prevent misrouted payments.
- New customer onboarding: The VAN must be assigned and communicated to the customer before the first payment is expected. A customer who pays before a VAN is assigned will use the physical account number — and the payment will not be auto-reconciled.
- VAN expiry: Some bank CMS arrangements assign temporary VANs (invoice-specific, 30-day validity). After expiry, payments on the VAN are rejected by the bank — the customer must be notified to use the updated VAN.
Integration Between VA System and ERP
The VAN reconciliation webhook must connect to the ERP or LMS in real time. For companies using SAP, Oracle, or Tally:
- The webhook event must trigger an automatic journal entry in the ERP (Dr. Bank, Cr. AR)
- The ERP receipt must be linked to the specific invoice using the invoice reference from the reconciliation system
- The TDS receivable entry (if TDS was deducted) must be created simultaneously
Without ERP integration, the VAN webhook updates the reconciliation system but the ERP still requires manual data entry — eliminating most of the efficiency gain.
Bank reconciliation software with native VAN webhook support — parsing bank API events from HDFC, ICICI, Yes Bank, and Axis Bank CMS platforms — eliminates the gap between the VAN notification and the reconciliation system update.
Reconciliation software India that handles VAN-level auto-matching, TDS detection on VAN credits, and real-time ERP posting provides the complete auto-reconciliation workflow — reducing NEFT collection reconciliation from days to minutes.
The Reserve Bank of India publishes guidelines on virtual account structures for payment aggregators and banking correspondents, including the regulatory requirements for escrow-linked VANs and the responsibility framework for misrouted VAN payments.