UPI Narrations Explained: Turning VPAs into Party Names for Ledger Scrutiny (2026)
Half of a modern bank statement is UPI rows, and the counterparty is hiding in the VPA. How to read UPI handles, tell people from merchants, use the RRN, and build a party ledger from UPI-heavy statements.
Open any current-year bank statement of a trading client or a professional, and UPI rows dominate it. Payments that would once have been five cheques and two NEFTs are now forty UPI transactions, each with its own narration, its own truncated name and its own UPI handle.
For ledger scrutiny this is both a problem and a gift. A problem, because the volume of small rows buries the statement's shape. A gift, because UPI narrations carry something older channels never did: the VPA, a stable identifier for the counterparty that survives every spelling variation of their name. This guide is about reading UPI rows properly and using them to build a party ledger that actually holds up.
What a UPI Narration Contains
However a bank formats it (hyphens at HDFC, slashes at ICICI, transfer strings at SBI, covered in detail in our narration formats guide), a UPI narration carries the same underlying fields:
- The counterparty name, as registered on their UPI app, often truncated.
- The counterparty VPA (virtual payment address), like rajesh.k@okaxis.
- The RRN, a 12-digit retrieval reference number unique to the transaction.
- A free-text remark typed by the payer, which can be anything from "invoice 42" to a single dot.
Pro tip
When the name field and the VPA disagree, trust the VPA. The name is whatever string the payer's app happened to hold; the VPA is the address the money actually went to.
Reading a VPA
A VPA has two parts: a local part chosen by the user, and a handle after the @ that identifies the UPI app or bank that issued it.
The handles you will see constantly:
| Handle | Issued by |
|---|---|
| @okaxis, @okhdfcbank, @okicici, @oksbi | Google Pay (via partner banks) |
| @ybl, @ibl, @axl | PhonePe (via partner banks) |
| @paytm, @ptyes, @ptaxis | Paytm |
| @apl, @yapl | Amazon Pay |
| @upi | BHIM |
| Bank-specific handles like @hdfcbank, @icici | The bank's own UPI app |
The local part is where the information lives. rajesh.k, rajeshkumar9876 and rk.traders are all plausibly the same person or firm, and the handle tells you which app they pay from. One person commonly holds two or three VPAs (a Google Pay one and a PhonePe one), so even VPAs need merging, but they merge far more reliably than truncated names do.
People vs Merchants: The Distinction That Changes the Head
UPI traffic splits into person-to-person and person-to-merchant, and the accounting treatment usually differs: a payment to an individual might be a loan, a salary, a personal expense or a supplier payment, while a merchant payment is almost always an expense or purchase.
The narration gives you signals:
Merchant VPAs look constructed. Handles containing paytmqr, razorpay-style gateway strings, or local parts like storename.pos are terminal or gateway VPAs, not personal ones.
Merchant names are business names. SHREE BALAJI TRADERS is a merchant; RAJESH KUMAR might be anyone.
Frequency and amounts tell on them. Dozens of small round-amount credits from many different VPAs usually mean the client is the merchant, collecting via a QR code. That pattern matters for revenue completeness: those credits are takings, not gifts.
Worth knowing
A single person paying the client repeatedly through a gateway VPA can masquerade as "merchant traffic". When one counterparty explains a large slice of credits, look through the VPA to who is behind it before classifying.
The RRN: The Cross-Reference You Are Not Using
Every UPI transaction carries a 12-digit RRN, and both sides' banks record the same RRN. That makes it the cleanest cross-reference in Indian banking:
- Matching both sides. When you hold statements of related entities (the client and their proprietor account, or two group firms), matching RRNs proves which rows are the same transaction seen from both ends. That is round-tripping detection with receipts.
- Chasing a disputed row. Given an RRN, the bank can locate the transaction precisely. Working papers that quote RRNs get faster answers than ones that quote dates and amounts.
- De-duplicating messy exports. Statements exported twice or stitched from overlapping date ranges contain duplicate rows; identical RRNs identify them with certainty.
From UPI Rows to a Party Ledger
The workflow that turns a UPI-heavy statement into a scrutiny-ready ledger:
- Extract name, VPA and RRN from each UPI narration (per your bank's format).
- Group by VPA first, not by name. The VPA survives truncation and spelling drift.
- Merge VPAs that belong to the same party, using the name field and repeated remarks as evidence.
- Split the result into people and merchants using the signals above.
- Roll up per party: transaction count, total paid, total received, net position.
- Send everything unattributable to an explicit Suspense bucket, visible and countable.
What UPI Patterns Reveal in Scrutiny
Once the party ledger exists, UPI-specific patterns become visible that a chronological statement hides completely:
The out-and-back. Money going to an individual's VPA and returning weeks later is a loan in both directions, whether or not the books say so. Grouped by party, the pattern is one line.
The salary that is not on the payroll. The same VPA receiving a similar amount every month is a recurring obligation. If it is not in the salary register, it is worth a question.
The round-amount habit. Genuine commercial payments have odd amounts (invoice values, split bills). A party receiving only clean round figures, repeatedly, reads differently.
Concentration. When three VPAs account for most of the outflow, that is either a normal supplier structure or the first thread to pull. Either way you want to see it before the client explains it. This is the core argument of our party ledger guide: the shape is where the findings are.
Automating the Whole Chain
Everything above is mechanical: parse, anchor on VPA, merge, classify, roll up. Which means it automates well, and doing it by hand across two thousand UPI rows is exactly the kind of evening this tooling exists to remove.
Greenote Lite runs this chain on any Excel or CSV statement from the major Indian banks: it parses each bank's UPI narration format, merges parties using VPA anchors, separates what it can attribute from what it cannot, and returns a workbook whose first sheet is the party ledger. The first statement is free, and the uploaded file is processed and deleted, never stored.
Conclusion
UPI changed what a bank statement is: more rows, smaller amounts, and a counterparty identifier hiding in every narration. Read the VPA instead of the name, group by it, separate people from merchants, and quote RRNs in your working papers. The statements are not going back to five cheques a month; the scrutiny workflow has to meet them where they are.
Frequently asked questions
What is a VPA in a bank statement?
A VPA (virtual payment address) is the UPI identifier money was sent to or received from, like rajesh.k@okaxis. The part before the @ is chosen by the user; the handle after it identifies the UPI app or issuing bank. In ledger work the VPA is more reliable than the name field, which is often truncated or stale.
What do handles like @ybl, @okaxis and @paytm mean?
They identify the app that issued the VPA: @okaxis, @okhdfcbank, @okicici and @oksbi are Google Pay handles, @ybl, @ibl and @axl are PhonePe handles, @paytm is Paytm, and handles like @hdfcbank belong to the bank's own UPI app. One person often holds VPAs from two or three apps.
What is the RRN in a UPI transaction?
The retrieval reference number, a 12-digit identifier both banks record for the same UPI transaction. It lets you match the two sides of a transfer across different statements, chase disputed rows with the bank precisely, and detect duplicate rows in stitched exports.
How do I tell merchant UPI payments from personal ones?
Look at the VPA construction (gateway or QR-terminal style handles suggest merchants), the name (business names vs personal names), and the pattern (many small credits from many VPAs usually means the client collects via QR). The distinction matters because merchant rows and personal rows take different accounting heads.
Why should UPI rows be grouped by VPA instead of by name?
Because the name field is unreliable: it is whatever the payer's app held, truncated by the bank's systems, so one person appears under several spellings. The VPA is the actual address of the transfer and stays constant, making it the right anchor for building party totals.
See it on your own statement
Upload an Excel or CSV bank statement and get back a party ledger, categorised transactions and an ITR-ready summary. First statement free. Files are processed and deleted, never stored.
Keep reading
How to Extract Party Names from Bank Statement Narrations: HDFC, ICICI and SBI Formats Decoded (2026)
The counterparty is always in the narration, but every bank hides it differently. How to read HDFC's hyphen segments, ICICI's coded prefixes and SBI's transfer strings, and what breaks when you try to automate it with formulas.
Bank Statement Red Flags: 12 Patterns Every CA Should Catch in Ledger Scrutiny (2026)
A working list of twelve red-flag patterns to hunt for in every client bank statement: what each looks like in a raw date-wise export, why a party-wise rollup is what exposes it, and the first action to take.
Ledger Scrutiny Checklist for Finalisation (2026): What to Verify Before You Sign
A stage-by-stage checklist a practising CA can print and run before signing a finalisation or tax audit, from statement completeness and the party-wise rollup to the Section 269 cash-law tests, AIS and SFT tie-out, and suspense clearance.