UPI transaction references: tr and tn

Two fields, two audiences

The UPI deep link has two free-text-ish parameters that get confused constantly because both look like "a note". They serve different readers:

upi://pay?pa=shop@upi&pn=Chai%20Point&am=250.00&tn=Order%2042&tr=ORD-2026-00042&cu=INR

	tr, transaction reference	tn, transaction note
Audience	Your accounting system	The payer, on their screen
Comes back in settlement	Yes: this is the point	Often, but as a label
Charset	A–Z a–z 0–9 . - only	Free text, percent-encoded
Length	1–35 characters	Keep under ~25 characters
Should be unique	Yes, per transaction	No: repetition is fine
Example	INV-2026-014	Table 7

tr is the machine's field: an opaque ID that survives the round trip and reappears against the credit, so software (or a spreadsheet) can match payment to record. tn is the human's field: it renders on the confirmation screen, where its job is to reassure the payer that this is the right payment.

The charset trap

tr is deliberately restrictive: letters, digits, dots and dashes, up to 35 characters. No spaces, no underscores, no slashes, no #. INV-2026-014 is valid; INV_2026/014 is not, and a reference that violates the pattern is a code some apps refuse to parse, one of the causes behind a UPI QR not being detected. UseQR's generator validates the pattern before encoding, and the decoder shows you exactly what a code carries.

tn is looser because it is percent-encoded free text (Order%2042 decodes to "Order 42"), but every encoded character enlarges the QR matrix, so a long note buys you a denser code and a smaller effective module size at print. Short wins.

Uniqueness discipline

The rules that make references worth having:

1. One tr per expected payment. Invoice number, order ID, month-and-unit. Anything already unique in your records. Reusing a tr across transactions collapses the very distinction it exists to make.
2. Never encode meaning you will need to parse into tn. It is display text; treat anything that comes back through it as a label, not a key.
3. Static codes get a constant tn, no tr. A permanent standee cannot know the transaction in advance, which is precisely the line between static and dynamic codes. Per-location notes (tn=Counter%202) still tell you where, if not which.
4. Derive, do not invent. FLAT4B-2026-08 can be reconstructed from your ledger; a random string cannot. The rent-collection pattern is this rule applied twelve times a year.

Bulk generation with row IDs

Reference discipline scales through spreadsheets. One row per expected payment (VPA, name, amount, and a tr column carrying your row ID) fed to the bulk tool yields one code per invoice, seat, month or parcel, each carrying its own reference. The freelancer invoice workflow is the canonical case: tr equals invoice number, and reconciliation becomes a VLOOKUP.

The accounting loop then closes itself: export the settlement or statement, match its reference column against your ledger's ID column, and whatever fails to match is your exception list, the payments to actually investigate, instead of all of them.

FAQ

What is the difference between tr and tn in a UPI QR code?

tr is a machine reference of 1–35 letters, digits, dots or dashes that comes back in settlement for reconciliation. tn is a short human-readable note shown to the payer on the confirmation screen.

Does the tr reference appear in my bank statement?

Yes, carrying your reference back against the credit is the parameter's purpose. Give every expected payment a unique tr and matching statements to records becomes a lookup rather than detective work.

Can I use spaces or underscores in a UPI transaction reference?

No. tr allows only letters, digits, dots and dashes, up to 35 characters. Spaces and underscores belong in tn, the display note, which is percent-encoded free text.

Should a printed standee include a tr?

No. A permanent code cannot know future transactions, so a fixed tr would repeat forever and mean nothing. Use a constant tn to identify the location, and reserve tr for per-transaction codes.