Virtual accounts · collections guide
One account number per customer, and every transfer explains itself
Bank transfers are cheap and familiar, but they arrive with whatever the payer typed in the remarks. A virtual account number fixes that: the number a customer paid into says who they are.
Incoming bank transfers
Illustrative- to PENX 0000 1042₹48,500from Shreeji Traders · NEFTMatched: Shreeji Traders, invoice 7781
- to PENX 0000 1187₹12,340from R. Menon · IMPSMatched: EMI for loan L-2231
- to PENX 0000 1042₹3,10,000from Shreeji Traders · RTGSMatched: same customer, second invoice
- to PENX 0000 9999₹7,000from Unknown sender · NEFTNo such virtual number: to exceptions
Customers, each with their own number
- Shreeji Traders…1042
- R. Menon (loan L-2231)…1187
- Aarav Public School fees…1301
- Exceptions: to investigate1
What arrives with each credit
- Virtual number
- who it's for
- Amount
- what they sent
- Payer
- name and account, where the bank passes them on
- Rail
- NEFT, RTGS, IMPS or UPI
- Bank reference
- the proof for both sides
The problem with “please mention the invoice number”
When customers pay you by bank transfer into one account, your statement fills with credits like “NEFT · SHREEJI TRAD · 48500”. Someone then has to work out which customer that is, which invoice it pays, and what to do with the one that says only “payment”.
Asking payers to quote a reference helps a little. Many forget, some type it wrong, and a few banks cut the remarks short. At a few dozen payments a month it's a chore; at thousands it's a team.
One shared account
NEFT · SHREEJI TRAD · 48500 · “inv”
Who? Which invoice? Someone has to find out.
A virtual account per customer
to PENX 0000 1042 · ₹48,500
Number 1042 belongs to Shreeji Traders. Matched before anyone looks.
Illustrative statement lines.
What a virtual account is, and isn't
A virtual account number is issued by a bank. It looks and behaves like any account number: a payer adds it as a beneficiary with an IFSC and sends money to it. But no money sits in the virtual account itself. Credits are routed into an underlying account held with the issuing bank, and each one is tagged with the virtual number it was sent to.
Which bank issues the numbers, and whose account the money lands in, depends on how your setup is structured, and is agreed during onboarding. That matters for when and how the money reaches you, so ask about it early.
It is
A real account number and IFSC that any bank customer can pay into
It is
A label that tells you which customer or invoice a credit belongs to
It isn't
A separate pot of money with its own balance
It isn't
A way for customers to pay by card, or a checkout
How a transfer reaches you
- Step 1
Share
You give the customer their virtual account number and IFSC, on the invoice or in their account page.
- Step 2
Pay
The customer adds it as a beneficiary and transfers by NEFT, RTGS or IMPS from their own bank.
- Step 3
Credit
The issuing bank receives the transfer and credits the underlying account, recording the virtual number.
- Step 4
Notify
You're told: virtual number, amount, payer's name and account where available, rail and bank reference.
- Step 5
Match
Your rules match the credit to the customer and their open invoices, and mark them paid.
Which payer details are included in a notification varies by bank and rail. How notifications are delivered on Peneu is confirmed during onboarding.
One number per customer, per invoice or per order?
The most important design choice is what a number stands for. It decides how much matching work is left for your team, and how often customers have to add a new beneficiary.
| Assign one per… | Good for | Trade-off |
|---|---|---|
| Customer | Repeat B2B buyers, loan borrowers paying EMIs, parents paying school fees | One payment can cover several invoices, so you still match to invoices by amount or oldest-first |
| Invoice | Large one-off invoices, projects, property milestones | Exact matching, but the customer adds a new beneficiary each time |
| Order or booking | High-value orders paid by bank transfer before dispatch | Many numbers to create and close; unused numbers need expiring |
Most businesses start with one per customer. How many numbers can be issued, and whether they can be closed or expired, is confirmed during onboarding.
Matching rules and the exceptions queue
The virtual number tells you who paid. It doesn't tell you what they meant to pay for. That's what matching rules are for, and the credits they can't place go to an exceptions queue for a person to decide.
A good queue is small and boring. If it isn't, the rules or the way numbers are assigned need changing, not more people.
| Credit | Typical rule | Needs a person? |
|---|---|---|
| Exact amount of one open invoice | Mark that invoice paid | No |
| Covers several open invoices | Settle oldest first, or as the customer's remittance says | Only if it doesn't add up |
| Less than what's due | Part-pay the invoice; the rest stays open | Sometimes: a deduction may need explaining |
| More than what's due | Hold as a credit on the customer, or refund | Yes, to decide which |
| To a number that doesn't exist or was closed | Exception | Yes: identify the payer or return it |
| From an account you don't recognise | Exception, if you only accept registered accounts | Yes |
Checking a credit before it's accepted
Normally a virtual account accepts whatever is sent to it, and you deal with surprises afterwards. Some issuing banks can also check a credit before accepting it and send back anything that fails, for example:
Registered payer only
Accept money only from bank accounts the customer registered with you, useful for loan repayments and regulated collections.
Expected amount only
Accept only the exact amount due, useful for fixed fees or bookings.
Open numbers only
Reject credits to numbers that were closed or have expired.
Whether validation before credit is available depends on the issuing bank and is confirmed during onboarding.
When the money arrives depends on the payer's rail
You don't choose the rail; the payer does, in their own banking app. So the same customer can pay you in seconds one month and in the next NEFT batch the next. What you control is how quickly you react once the credit lands.
Once credited, the money is in the underlying account. When it becomes available to you, if the underlying account isn't your own, follows your settlement terms. See the settlement guide.
| Payer sends by | Credited |
|---|---|
| IMPS | Within seconds, any hour |
| NEFT | In the next half-hourly batch, any day |
| RTGS (₹2 lakh or more) | Within about 30 minutes, any hour |
| UPI, where a UPI ID is linked | Within seconds, any hour |
NEFT and RTGS timings are from RBI's FAQs. IMPS and UPI limits are set by NPCI and the payer's bank.
Money you didn't expect
Once a credit is accepted, it can't be “rejected”. If someone paid the wrong number, paid twice, or paid when nothing was owed, the money is yours to hold until you return it, and you return it with a payout to the account it came from, keeping the original bank reference with the refund.
Record every such return against the original credit, and never send it to a different account because someone asked by email. That's the collections version of the bank-detail fraud described in the vendor payments guide.
What your customer sees, and why it matters
To your customer, a virtual account is a new beneficiary in their banking app. Before sending money to it, a careful customer, and every finance team, will check two things: that the details came from you, and that the beneficiary name their bank shows looks like you.
So put the details where customers already trust you: printed on the invoice, in their logged-in account page, or in the welcome letter for a loan. Never only in an email, which is the channel fraudsters copy. And tell them the beneficiary name to expect, because it may be yours, or it may include the issuing bank's or your provider's name depending on how the account is set up.
Invoice footer
IllustrativePay by bank transfer
- Account number
- PENX 0000 1042
- IFSC
- ABCD0000123
- Beneficiary
- Your business name, as the bank displays it
This number is only for Shreeji Traders. Use it for every payment to us. We never change it by email.
Designing the numbering scheme
The issuing bank sets the length and usually a fixed prefix. What follows is often yours to decide, and a little thought here pays off for years.
Tying the number to a customer code you already use (“PENX 0000 1042” for customer 1042) makes it easy to read on a statement. The trade-off is that neighbouring numbers are guessable. That rarely matters for collections, since money paid to the wrong number still lands with you, but it matters if the number also appears in places where customers could confuse themselves with one another.
Stable
A customer's number never changes, even if their name or plan does.
Never reused
A closed number stays closed, so late payments can still be traced.
Readable
Grouped in fours on invoices so it can be typed without mistakes.
Recorded before shared
The number is in your system against the customer before it's on any invoice.
Closing each day
Collections by virtual account reconcile themselves most of the time, but “most” needs checking. A short daily close keeps the exceptions queue from growing quietly: the total credited to the underlying account should equal what was matched plus what's in exceptions. If it doesn't, a credit arrived without a notification, or a notification arrived without a credit, and both need finding the same day.
Then look at the queue itself. Every item should have an owner and an age. Anything older than a few days is either a payer to contact or a refund to make.
Moving customers onto virtual accounts
Switching existing customers from your one shared account to their own numbers is a small project. Customers who have paid the old account for years will keep doing so unless you make the change easy and give it time.
- Step 1
Decide what a number means
Per customer, per invoice or per order; this decides everything after.
- Step 2
Issue and record
Create the numbers and store each one against the customer in your own system before telling anyone.
- Step 3
Tell customers where they trust you
Invoices and account pages first, with a clear note that the old account is being retired.
- Step 4
Run both for a while
Keep matching payments to the old account by hand until they dwindle, then retire it with notice.
Mistakes that bring the matching work back
Reusing a number. Giving a closed customer's number to a new customer. Old payments and new ones get mixed up; keep numbers retired.
Sharing numbers between group companies. A distributor paying for three outlets through one number leaves you guessing which outlet paid.
Numbers only in email. Customers can't find them later, and fraudsters can imitate the email.
No owner for exceptions. An exceptions queue nobody clears becomes the old manual matching, just slower.
Where virtual accounts fit best
B2B receivables
Distributors and wholesalers collecting from hundreds of trade customers who pay by bank transfer.
Virtual accounts, payment links or QR?
| If your customer… | Use | Why |
|---|---|---|
| Pays by bank transfer, often large amounts | Virtual accounts | Familiar for businesses; no checkout needed; the number identifies them |
| Wants to pay by card or UPI from a message | Payment links | A checkout page with several methods, one link per amount |
| Pays in person or on a phone screen | UPI QR | Scan and pay in seconds |
| Pays through your app or website | Collection API | Checkout built into your own flow |
What your systems need to hold
Virtual accounts only remove manual matching if your own records are built for them. Three things matter: a table that maps each virtual number to a customer, a credit handler that can safely receive the same notification twice, and a matching job whose rules are written down, not buried in code.
| Record | Holds | Why |
|---|---|---|
| Number map | Virtual number, customer, date issued, status (open or closed) | Every credit is matched through it; closed numbers stay for tracing |
| Credit log | Bank reference, virtual number, amount, payer details, rail, time | The bank reference makes a repeated notification harmless |
| Allocation | Which invoices each credit settled, and any remainder | Answers “what did this payment cover?” months later |
| Exceptions | Credits not matched, owner, age, decision | Keeps the manual work visible and shrinking |
Illustrative design. How Peneu delivers credit details is confirmed during onboarding.
Virtual account questions
Do virtual accounts replace my current account?
No. They sit on top of an account that actually holds the money. Virtual numbers identify who paid; the underlying account, and your settlement arrangement, decide where the money is and when you can use it.
Can customers pay a virtual account by cheque or cash?
Virtual accounts are designed for electronic transfers, where the account number travels with the payment. Whether cheques or cash deposits can be credited to a virtual account depends on the issuing bank.
Can one customer have more than one virtual account?
Yes, if it helps you. A distributor with several branches, or a borrower with two loans, can have a number for each, so every payment is attributed to the right branch or loan without anyone reading remarks.
What happens to money sent to a closed virtual account?
It depends on the issuing bank and your setup. It may be rejected back to the payer, or credited and flagged for you to return. Either way, a closed number should never be reissued to someone else.
What is a virtual account number?
A virtual account number is an account number issued by a bank that doesn't hold money on its own. Transfers sent to it are credited to an underlying account, tagged with the virtual number they were sent to. Because each customer or invoice gets its own number, the number tells you who paid.
Is a virtual account a real bank account?
It's a real account number that payers can add as a beneficiary and send money to by NEFT, RTGS or IMPS. But the money lands in an underlying account held with the issuing bank; the virtual number is a routing and identification layer on top of it.
How does my customer pay into a virtual account?
Exactly like paying any bank account: they add the virtual account number and IFSC as a beneficiary in their banking app or net banking, then transfer. Nothing needs to be installed and no card or UPI app is required.
What happens if a customer pays the wrong amount?
The money still arrives and is tagged to that customer's number. Your matching rules decide what happens next: a short payment leaves the invoice partly open, an excess stays as a credit or is refunded. Nothing is lost; it's an exception for your team to resolve.
Can I stop payments from people who aren't my customer?
Some banks can check an incoming credit before accepting it, for example against a list of the customer's registered accounts, and send back anything that doesn't fit. Whether that is available depends on the issuing bank and your setup, and is confirmed during onboarding.
How quickly will I know a payment arrived?
As soon as the underlying account is credited, which depends on the rail the payer used: seconds for IMPS, the next half-hourly batch for NEFT, around 30 minutes for RTGS. How you're notified, and how quickly, is confirmed during onboarding.
Can customers pay a virtual account by UPI?
In some setups a UPI ID is linked to the same virtual account, so customers can pay by UPI as well as bank transfer. Whether that's available on your Peneu setup is confirmed during onboarding.
Virtual accounts or payment links: which should I use?
Use virtual accounts when customers pay by bank transfer, especially larger or recurring B2B amounts. Use payment links or UPI QR when customers pay by card or UPI and you want a checkout experience. Many businesses offer both.
Stop matching bank transfers by hand
Tell us who pays you by bank transfer and how often. We'll walk through numbering, matching and notifications.
Official sources
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.