The remittance data you finally get and cannot use
For twenty years the industry complaint was that remittance data never travelled with the payment. It is starting to. Almost nothing downstream is ready to read it.
- Structured remittance elements let a payment carry the invoices it settles rather than a narrative someone has to interpret.
- Cash application logic in most companies was built around parsing free text, which structured data makes redundant rather than easier.
- Adoption is uneven, so a receivables team will be reading both structured and narrative remittance for some years.
- The gain is largest in partial payments and deductions, where a narrative rarely explains what was short paid or why.
- Getting value from this is a receivables project rather than a treasury one, and it is usually funded by the wrong budget.
Ask a receivables team what would make the biggest difference to their week and the answer is rarely a new dunning template. It is knowing what a payment is for without ringing the customer to ask.
That information has always existed. It just travelled separately, in an email, a portal, a PDF attachment or a narrative field truncated at thirty five characters.
Structured remittance changes the transport. The invoices being settled can travel inside the payment message itself. The question is whether anything on your side is built to read them.
What structured remittance carries
In a structured remittance block, each referenced document gets its own entry. An invoice number, an amount applied, and where the payer chooses to provide it, an adjustment with a reason.
That is a different object from a narrative. A narrative is a string that a human can usually interpret and a machine can sometimes parse. A structured block is a list that a machine can apply directly.
The practical effect is on partial payments. A customer settling four invoices and deducting two credit notes produces one bank line, and the narrative almost never explains the arithmetic.
This is the receivables mirror of the payables changes running through the same standard. Both come back to the same point made in a data model is not a file format.
Why existing cash application cannot use it
Four reasons the arrival of better data does not automatically produce a better matching rate, when preparation is the part worth automating, as in the first draft of the numbers should not be a person.
The deduction problem underneath
Most unapplied cash is not a mystery payment. It is a payment that is slightly short, where the shortfall represents a dispute, a promotional allowance, a freight charge or a pricing difference nobody recorded.
Structured remittance helps identify what was paid. It does not, on its own, tell you why the balance was not paid, and that second question is the one that consumes receivables time.
The teams that make progress treat the shortfall as a separate object with its own ageing and its own owner, rather than as a residue left behind by the matching process.
Left alone, those residues become the population described in credit losses on receivables you thought were safe, discovered when the provision is recalculated rather than when the deduction was taken.
The payment tells you what was settled. The gap tells you what your commercial terms actually are in practice.
Three populations, three different answers
Cash application is usually treated as one process. It behaves as three, and only one of them is genuinely improved by structured remittance. Thresholds set years ago distort the split, as materiality thresholds set in 2019 shows.
| Population | What structured data does | What still needs a person |
|---|---|---|
| Exact settlements | Applies automatically with references carried in the message. | Nothing, once the tolerances are reset for exact data. |
| Partial payments | Identifies which invoices were intended and by how much. | The reason for the shortfall, which is rarely in the message. |
| Unidentified receipts | No change, because a payer who does not populate references usually does not populate anything. | Investigation, which is where the time goes today. |
Adoption of structured remittance varies by payer, bank and country. Expect a mixed population for some years and design the process for both formats.
The data arrived. The process that needed it was built to live without it.
ChatFinRebuilding the process around exact references
The change is small in configuration terms and significant in operating terms, because it moves work from matching to dispute resolution. Keep the evidence with the entry, since the document you cannot find is the control.
Separate exact from approximate
Route receipts with structured references down a different path than receipts without. Mixing them forces the whole population onto the weaker logic.
Reset tolerances for the exact path
A tolerance designed to absorb missing information is dangerous when the information is present. Differences should surface, not be absorbed.
Give the deduction its own record
Amount, reason, owner and age. Without those four fields the shortfall is invisible until someone reviews the ledger.
Report on the split
Track what proportion of receipts arrive with structured references. That number is what tells you when the old logic can be retired.
Who should own this
The funding question decides whether this happens, and it is usually asked in the wrong place.
Treasury sees the change
Treasury notices the format change first because it manages bank connectivity, and treats it as a technical migration with no business case attached.
Receivables gets the benefit
The value lands in collections, deductions and unapplied cash. If receivables is not in the room, the migration completes and the process stays the same.
Where ChatFin sits in cash application
Cash application is a matching problem with a judgement tail, which is the shape of work that benefits most from preparation rather than replacement.
It does not resolve disputes or contact customers. The judgement about whether a deduction is valid stays with the team that owns the relationship, in line with human in the loop as a design decision.
AI Cost Estimator for the CFO Office
Four inputs. A first year range, a timeline, and three delivery models compared. No login required.
Frequently Asked Questions
Is structured remittance widely used yet?
Not yet. Adoption depends on the payer populating it and on both banks carrying it through. Expect a mixed population for several years, which means the process needs to handle exact references and narrative parsing at the same time rather than switching from one to the other.
Will this reduce unapplied cash?
It reduces the part of unapplied cash caused by not knowing which invoices a payment covers. It does not reduce the part caused by short payments and deductions, which in most companies is the larger share. Treating those as two different problems is the useful step.
Should we change our matching tolerances?
For receipts that arrive with exact references, yes. A tolerance set to absorb missing information will quietly write off real differences when the information is present. Keep the old tolerance for the narrative population and apply a tighter one where references are explicit.
Who should own the project?
Receivables, with treasury supplying the connectivity. The format change is noticed by treasury and the benefit is realised in collections and deductions, so a project funded and measured purely as a treasury migration usually delivers the format and none of the operational gain.
Better data only helps if the process changes with it.
Structured remittance is arriving unevenly, so the winning design reads both formats and routes them differently rather than waiting for full adoption.
If you want a first year range for putting prepared cash application on your own ERP, the estimator will give you one in about a minute.
Open the estimatorBook a Demo
See what this looks like in your ERP.
We will walk through the workflow behind this article on the system you already run, using your own data, and show what a first phase would actually cover.
This article is general information for finance and accounting teams. It is not legal, tax, accounting or investment advice. Dates and thresholds are given as published at the time of writing and several of these timelines have moved before, so confirm the current position with your advisers and with the relevant authority before acting.