Articles / Learning brief
Structured remittance information
Your notes
In simple terms / 01
What this means in plain language
The difference between structured and unstructured remittance information in a payment: why structured references such as invoice numbers improve automatic reconciliation, and what detail can be truncated when a message is translated to a legacy MT format.
Remittance information is the part of a payment that tells the beneficiary what it is for, so an incoming credit can be matched to the invoice or obligation it settles. It comes in two shapes. Unstructured remittance is free text, a line of narrative that a person reads by eye. Structured remittance breaks the same information into labelled fields, for example a referenced invoice type, an invoice number, a date, and a creditor reference with a check digit. The difference matters for reconciliation. When the reference arrives in a labelled field, the beneficiary's system can read it directly and match the payment to an open receivable automatically, without anyone keying it in. ISO 20022 (International Organization for Standardization standard 20022) messages such as the pacs.008 (payments clearing and settlement message 008) can carry either shape. The risk appears when a structured message is translated into a legacy MT (Message Type) format, whose short remittance field can truncate the detail and flatten the structure.
Complete lesson / 02
Understand the full idea, step by step
Every payment quietly asks the one who receives it: what is this for? A company taking in hundreds of credits a day cannot answer that from the amount alone — it needs the payer to say which invoice this clears. Where that answer lives, and how it is written, decides whether a machine can match the payment or a person must.
Remittance information
Remittance information is the reference data a payer attaches so the beneficiary can tie an incoming credit to the specific invoice, order, or obligation it settles. It comes in two forms. Unstructured remittance is free narrative text — a human-readable line the payer types. Structured remittance carries the same meaning in labelled fields, each holding one defined piece: an invoice type, an invoice number, a date, an amount, or a formal creditor reference. ISO 20022 supports both, and a single payment can carry some of each.
Why structure lets a machine reconcile
Reconciliation is the work of matching money received against what was owed. When a reference sits in a labelled field, the beneficiary's accounts-receivable system reads it directly, finds the matching open item, and clears it — no person involved. When the same reference is buried in free text, software has to scan the narrative for something that looks like an invoice number, and often gets it wrong, so the item drops into a manual queue. The payoff of structure is straight-through reconciliation: a credit arrives, its reference is read, the receivable is cleared, and no one keys anything.
Creditor reference — a payer-quoted code, standardised by ISO 11649
A common structured form is a creditor reference: a code the beneficiary defines and asks every payer to quote back on payment. The ISO 11649 standard adds a check digit, so a mistyped reference is caught rather than silently matched to the wrong invoice. Structured document information can also name the invoice type, number, date, and the amounts due and remitted — so a partial payment, or one settling several invoices at once, can still be matched precisely.
| Unstructured | Structured | |
|---|---|---|
| What it is | Free narrative text | Labelled fields, each a defined piece |
| How it matches | Software guesses; often a person reads it | Read directly by field; matched by machine |
| When it is wrong | Mismatch may pass unnoticed | Check digit catches a mistyped reference |
| Result | Manual queue for many items | Straight-through reconciliation |
WHAT IF — A structured ISO 20022 payment is translated into the legacy MT format
What happens: MT keeps remittance in a single narrow free-text field, with room for only a few short lines. The labelled fields are flattened into that one space: longer references are cut to length and the separation of invoice number from date from creditor reference collapses into an undifferentiated line.
How it is handled: This is truncation — not a fault in the translation, but a consequence of moving structured data into a container never designed to hold it. Once flattened it cannot be rebuilt by translating back, because the labels that gave each piece meaning are gone. The safe practice is to carry structured remittance natively end to end rather than route it through a format that cannot hold it.
COMMON CONFUSION
“As long as the invoice number is somewhere in the payment, the beneficiary's system will find it.”
Where and how the number is written is what decides. In a labelled field a machine reads it; buried in narrative it may be missed, and if the message is later translated to MT the structure can be truncated away. A payment can arrive technically complete yet no longer machine-matchable.
STRICTLY SPEAKING
Strictly speaking, exactly how much structured remittance a message can carry, and precise field limits, vary by message version and by usage guideline. The MT limits and the ISO 20022 structured elements both change over time, so the durable point is not a character count but the direction: keep remittance structured and native, and check the current guideline for limits before relying on them.
FOR NOW, REMEMBER
- Remittance information answers what a payment is for; it can be unstructured free text or structured labelled fields.
- Structure lets accounts-receivable software match a credit to an invoice by machine — straight-through reconciliation.
- A creditor reference (ISO 11649) adds a check digit; structured document detail supports partial and multi-invoice payments.
- Translating to legacy MT can truncate structured remittance, and it cannot be rebuilt afterwards — so carry it natively end to end.
TRY IT YOURSELF
Asha Traders receives two EUR 3,200.00 credits: one quotes its invoice number in the structured creditor-reference field, the other only in a free-text note. Which is more likely to reconcile automatically, and why?
You have followed ISO 20022 from the model, through the header, the initiation, the SEPA families, camt, and the remittance that makes reconciliation work. The topic behind it ties the model together with more depth.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Remittance information tells the beneficiary what a payment is for; it can be unstructured free text or structured into labelled fields.
- 02
Structured remittance, such as a referenced invoice number or a creditor reference, lets the beneficiary's system match a payment to an open invoice automatically.
- 03
Translating a structured message into a legacy MT format can truncate the detail and flatten the structure into free text, which cannot then be rebuilt.
Practical use cases / 04
Where you would use this
A supplier's accounts-receivable system reads a structured invoice reference from an incoming payment and clears the matching open item without manual keying.
A corporate treasury asks its customers to quote a structured creditor reference so incoming payments reconcile automatically.
An operations analyst traces an unmatched payment to a truncating MT translation that dropped the structured invoice detail upstream.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional supplier, Alder Freight Ltd, issues invoice INV-88213 for EUR 9,500.00. Its customer pays through an ISO 20022 pacs.008 carrying structured remittance: the referred document type 'CINV' (commercial invoice), the number INV-88213, the invoice date, and a structured creditor reference. Because the reference sits in labelled fields, Alder Freight Ltd's system matches the EUR 9,500.00 to the open invoice automatically, within seconds and with no manual keying. Had the payer instead written the free-text line 'payment for services', a clerk would have had to find the invoice by hand. Now suppose the payment is translated into a legacy MT103 for an older system: its remittance field allows only 4 lines of 35 characters, 140 in total, so the structured block of roughly 190 characters is compressed into free text and the labelled invoice fields collapse. The receiving system can no longer read INV-88213 as a reference, and the automatic match is lost.
Evidence & review / 07
Evidence & review
ISO 20022 structured remittance generally; character limits and translation behaviour depend on the message version, usage guideline, and MT mapping in force.
What this brief simplifies: Describes truncation qualitatively rather than quoting fixed field lengths; creditor reference presented via ISO 11649 as the representative structured form.
Sources for this brief3
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · Structured and unstructured remittance information elements
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT remittance field constraints
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.