NovA payment reference has to survive the bank’s character limits
How to preserve the meaning of a property payment reference when a bank form cannot accept the seller’s full wording.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
The payment reference looks like a minor field until the buyer pastes the seller’s instruction into online banking and half of it does not fit. At that point, the buyer has to make a decision that feels technical but can affect reconciliation later. Truncating the text blindly may remove the unit or invoice identifier. Rewriting it freely may change the meaning. The safest approach is to treat the reference as part of the transaction record, not as an informal note to the recipient.
Payment systems are increasingly built around richer, more structured data. Swift describes ISO 20022 as a standard that can carry more granular information and improve reconciliation. That does not mean every retail banking interface exposes unlimited free text. Individual banks and channels can still impose their own field lengths, character sets and structures. The practical job is therefore to preserve the identifiers that matter within the form that actually exists.
Find the information the recipient genuinely uses
Take a hypothetical instruction: “Payment under SPA No. 17/2026, Unit A-1204, second instalment, buyer Ivan Petrov.” If the field is too short, there is no universal rule saying which words can disappear first. The seller may reconcile by contract number, invoice number, unit number or another internal identifier.
That is why I prefer an approved short version to a buyer-invented abbreviation. The question to the seller is simple: “My bank’s payment-reference field cannot hold your full wording. Which shortened reference should I use for this instalment?” If the bank provides separate fields for an invoice reference, payment purpose or beneficiary information, those should be used according to the bank’s instructions rather than merged into one line by guesswork.
A complete short reference is more useful than a longer line that is cut off at an arbitrary point. If the last characters contain the only unit identifier, automatic truncation may remove the very data the seller needs. Shortening should preserve function, not preserve as many characters as possible.
Do not turn abbreviation into misdescription
There is a material difference between shortening a truthful description and disguising the nature of a payment. A property purchase should not be labelled as “family support,” “personal transfer” or another unrelated purpose merely because a different label appears easier to submit.
Banks may also use structured regulatory or purpose fields that are separate from the free-text remittance information visible to the recipient. The correct choice depends on the bank, jurisdiction and transaction. A buyer should not assume that a phrase copied from another person’s transfer is suitable. If the interface asks for a specific payment category, the bank is the right source for how to complete it accurately.
At the same time, a payment reference cannot repair a bad transaction. Perfect wording does not make the wrong beneficiary acceptable. It does not validate an unsigned agreement or fix a mismatch between the amount being sent and the contractual schedule. The reference is one piece of the evidence trail, not a substitute for the underlying documents.
Discover the constraint before the deadline
Most reference problems become stressful because they are discovered on the payment date. The buyer opens the form, sees a character limit and starts negotiating abbreviations in a chat while the contractual deadline is approaching.
A better sequence is to preview the payment form in advance without submitting it. The buyer can see which fields are available and where the seller’s wording does not fit. The seller or its finance team can then approve a short version. If the bank says that a particular identifier belongs in another field, that advice can be recorded too.
This advance check is especially important in an instalment purchase. The reference should distinguish one payment stage from another. If each instalment has its own invoice or stage identifier, the abbreviated reference can still preserve that distinction. Reusing one generic phrase for every payment may make the bank transfer technically valid while making the seller’s internal ledger harder to reconcile later.
Verify what was actually transmitted and credited
The buyer normally sees the front end of the payment. The transaction may then pass through several systems before reaching the recipient. The record is not only what the buyer intended to type, but what appears in the bank’s final confirmation and how the seller recognised it.
If the payment had to be shortened, I would keep the sending bank’s confirmation showing the actual reference and then obtain the seller’s acknowledgement that the correct obligation was credited. That closes the loop. If the seller allocates the money to the wrong instalment, the problem can be corrected while the transaction context is still fresh.
Structured remittance information under ISO 20022 is intended to improve this type of reconciliation. The broader industry direction is helpful, but it does not remove the need to check the user-facing implementation of the buyer’s own bank. Standards can support richer data without guaranteeing that every bank presents or accepts identical fields.
A good short reference remains understandable later
My final test is retrospective. Could the owner open the bank confirmation a year later, place it beside the contract and identify the obligation without relying on memory or an old chat? If the answer is yes, the shortened reference did its job. If the line only makes sense after somebody explains a private abbreviation, too much meaning was lost.
The exact content should follow the official payment instruction for the transaction. Contract number, invoice number, property identifier and instalment stage are examples, not a universal formula. The buyer does not need to become a payments-message specialist. The practical discipline is enough: identify the constraint early, get a truthful shortened version approved, and preserve the record of what was actually sent and how it was applied.
Sources
- Swift — About ISO 20022: richer and more structured payment data; accessed 6 October 2026.
- Swift — ISO 20022 document centre, guidance on Purpose of Payment and Structured Remittance Information: separation of payment-purpose and reconciliation data; accessed 6 October 2026.
- NovAsia Estate — “Payments and banking when buying property in Cambodia”: documented payment instructions and consistent payment references; accessed 6 October 2026.