Remittance information is the part of a payment message that explains the purpose of the payment to the person or business receiving it. Typical content is an invoice number, a customer or contract number, a credit note being deducted or a short free-text description. It travels from the payer, through the banks and clearing systems, to the payee's bank, which passes it on in statements and notifications.
The term is used mainly for wires, SEPA transfers and other account-to-account payments, and it has nothing specifically to do with migrant remittances. Its practical importance lies in cash application: a payee that receives thousands of credits needs the remittance information to work out which customer paid and which invoices to mark as settled. It is closely related to the payment reference, which is often the single key value within it.
Unstructured and structured forms
Payment standards distinguish two forms. Unstructured remittance information is free text, written by the payer for a human to read. It is easy to produce but hard to process automatically, since payers abbreviate, mistype or omit details. Structured remittance information places each item in a defined field, such as document type, document number, amount and creditor reference, so that software can read it without guessing.
A structured reference is the most widely used structured element. It is a reference issued by the payee, usually with check digits, that the payer must quote exactly. The international format is the ISO 11649 creditor reference, which begins with the letters RF, and several countries have national equivalents printed on bills and payment slips.
How different systems carry it
Each payment system sets its own limits on what can be sent.
- Swift MT messages. In the MT103 customer transfer, remittance information sits in field 70, which holds four lines of 35 characters, 140 characters in all.
- SEPA. A SEPA Credit Transfer carries up to 140 characters of unstructured text or a structured creditor reference, and the scheme rules require it to be delivered to the payee unchanged.
- ISO 20022. Messages such as pain.001 and pacs.008 contain a remittance information block with both unstructured and structured options. The structured option can describe several invoices, with amounts and adjustments for each.
- US ACH. Remittance data travels in addenda records attached to an entry. A corporate CCD entry can carry one addenda record of up to 80 characters, while the CTX format can carry thousands of records holding a full electronic remittance advice.
- Instant payment systems. Real-time schemes built on ISO 20022 generally support the same remittance block, though each scheme decides how much of it participants must accept.
Use in reconciliation
When a payment arrives, the payee's bank reports it in an account statement or a credit notification such as camt.054, including whatever remittance information was received. The payee's accounting system then tries to match the credit to open items in accounts receivable. A clean structured reference allows a fully automatic match. Free text has to be parsed for anything that looks like an invoice number, and failures go to staff for manual review.
Where one payment covers many invoices, the detail often does not fit in the payment. Payers then send a separate remittance advice by email or through a portal, and the payee has to link that document to the payment, a process described under remittance advice matching. Some businesses avoid the problem by giving each customer a dedicated virtual account number, so the payer is identified by the account credited instead of by the text.
Loss and truncation of data
Remittance information does not always survive the journey. A payment may pass through several banks and systems with different formats, and data that fits in one may be cut short or dropped in another. This has been a long-standing weakness of cross-border payments that pass through correspondent banking chains, and of older domestic systems with short reference fields.
The move of major systems to ISO 20022 is intended to reduce the problem. High-value systems in the euro area, the United Kingdom and the United States, and cross-border payment traffic on the Swift network, have adopted the standard, which allows richer structured data to be carried from end to end. The benefit depends on banks' internal systems and customer channels being able to accept, store and report the extra data, which is still uneven.
Compliance considerations
Remittance text is also read by compliance systems. Banks apply sanctions screening to free-text fields, and an ambiguous word in a payment description can stop a transfer for review. Some jurisdictions require a purpose code or a statement of purpose for cross-border payments, and this may be carried with or alongside the remittance information. Payers are generally advised to keep the text short, factual and limited to what the payee needs.