Unstructured vs. Structured: A Guide To Remittance Information

One of the most important aspects of sending a payment is explaining what said payment is for to the recipient. Presently, there are a few options to achieve this goal. For starters, after a payment is sent, many finance teams will send an email to the recipient telling them to expect the payment and to apply it to a given invoice. This is called "out-of-band" remittance information, so-called because the remittance information isn't arriving with the payment but via a separate channel (e.g., email, telephone).

The main benefit in this scenario is for the originator, they can easily send the follow-up information after they've made the payment and can move on to the next. For the recipient, however, it's a different story.

When the recipient sees the incoming payment, the only information they have is a sender name and an amount. In order to reconcile and apply the payment correctly, the recipient will have to look up the sender, check their email or phone for a message to see what invoice they intended to pay, and then manually apply the payment to that invoice. Doing this occasionally for one-off transactions probably doesn’t take too much time, but when receiving hundreds or thousands of payments per month, it becomes an operational burden that slows down the entire accounts receivable process.

A slightly faster iteration of recipient reconciliation involves "in-band" remittance information; this is where contextual information about why a payment is being made is included in the payment itself. Around the world, different payment systems have differing limits on how much information can be included with a single payment. For most High-Value/Real-Time Gross Settlement (RTGS) systems, remittance information is generally limited to 140 characters (4 lines each, holding up to 35 characters). In most business-to-business contexts, 140 characters is enough to include an invoice number and a short memo.

This proverbial "luxury," however, disappears entirely for Low-Value/ACH-type systems. In the United Kingdom, the Bacs system supports just 18 characters while in the United States, the ACH system supports just 10. At these reduced levels, truncated invoice numbers are common, and many originators resort to single words such as "PAYMENT" or "CREDIT,” neither of which are adequately descriptive. Because the originator is solely responsible for the content included in these length-restricted fields, this data is commonly referred to as "unstructured" remittance information.

A Brief History

The prevalence of unstructured remittance information primarily comes from the underlying file formats used by the system's participants. In the case of ACH in the US and Bacs in the UK, both systems operate via fixed-width text files that follow a rigid structure that makes any change to existing fields extremely difficult. Until recently, most payment systems used their own proprietary formats or the Swift MT format.

But in the last couple of years, payment systems have been migrating to a new technical format: ISO 20022. One of the most interesting technical aspects of the format is the capacity to hold both "unstructured" as well as "structured" remittance information.

Structured remittance information means that the payment network itself can transmit data in specially reserved fields to help speed up the processing of the payment. Returning to the earlier example, structured remittance information would mean being able to include not just a single invoice number, but multiple invoice numbers, with the payment.

Benefits of the ISO 20022

In a report published last year by the ASC X9 ISO 20022 Market Practices Forum Remittance Content Group, the ISO 20022 specification was found to have over 350 unique remittance information fields. The group lays out scenarios where having structured remittance information can speed up straight-through processing such as:

• Payment where discount is taken within terms
• Payment with extensive adjustments and/or credits—partial payments, short pays, credit notes, overpayments, authorized and unauthorized deductions
• Payment for goods/services at multiple locations
• Payment with multiple references (e.g., PO number, sales order number, shipment reference)

However despite the technical capabilities, very few payment systems fully support the structured remittance information capabilities of ISO 20022. Many payment systems that are migrating or in the process of migration still haven't fully made the jump.

The notable exception to this are the numerous real-time payment systems around the world. FAST, NPP, SEPA ICT, RTP and FedNow all were built natively with the ISO 20022 spec and, at a technical level, support the sending of this rich remittance information.

Learn More

At Modern Treasury, we're currently exploring the ways in which we can combine the power of these 24/7/365 payment rails with the expressiveness of structured remittance information to improve payment operations for our customers. In combination with our invoice management features, our operating system will soon be able to receive this information from the payment networks and automatically apply payments towards outstanding invoices. To learn more, reach out to us.