Background
The financial services industry is rapidly moving to the ISO 20022 standard. Numerous ISO 20022 programmes are in-flight across SWIFT, banks, clearing houses and software vendors. Much is discussed about global standardization, syntax independence, uniformity across business processes, increased interoperability and the associated straight-through processing (STP) improvements along with cost reductions. Within the payments’ domain a specific benefit is the ability for richer remittance data to be carried end-to-end thereby allowing better (automated) bulk reconciliation by the Creditor.
The are many terms for this remittance data. This white paper will refer to it as Extended Remittance Information (ERI) and will focus on a supply chain/trade payable use case as this often generates a large volume of ERI.
SWIFT, along with various market infrastructures, as part of their ISO 20022 programmes are upgrading their ERI capability and capacity.
Purpose
The purpose of this white paper is to outline the customer need for ERI within a typical supply chain scenario but also to more objectively determine how much ERI can be passed, in a meaningful measure rather than number of text characters. The meaningful measure will be the number of supplier invoices.
What Is ERI?
Extended remittance information is the associated information for which the payment is being made. Within business-to-business payments this will often be purchase orders, contracts, bills of lading, invoices or credit notes. Corporate Account Payables departments usually execute automated, periodic payment runs which batch invoices into payments based on various criteria such as approval status, supplier, due date, currency etc. The supplier’s Accounts Receivables department will want to reconcile the received payment against the relevant outstanding invoices using various data points such as invoice number, amount etc. In the supply chain arena, significant remittance information may need to be passed with the payment between buyer and supplier. If the ERI cannot be included and passed through the banking system, the buyer will usually generate and send a separate remittance advice notice to the supplier, often by email, which adds complexity to automated reconciliation.
Unstructured vs. Structured ERI
Historically, when sending an MT 103, remittance data could be included in field 70 which permitted only 4 lines each of 35 characters. The MT 103 REMIT message extended this with 9,000 characters in field 77T (an additional subscription service). Both formats permit data in a single field, therefore if multiple data points are needed per invoice, such as invoice number, invoice gross amount, invoice net amount, invoice date etc, and there are multiple invoices, the ERI becomes complex and individual data points difficult to identify and parse. Usage rules, to structure the data in these fields, have been defined and many parties bilaterally agree their own rules however they are implicit, difficult to ensure consistency, difficult to validate and open to error.
The key point is, regardless of usage rules, unstructured remittance information is entered entirely under the control of the buyer (initiating the payment) and may contain free-format text.
Remittance Information (RmtInf) Structured information that enables the matching, i.e. reconciliation, of a payment with the items that the payment is intended to settle, such as commercial invoices in an account receivable system.
In ISO 20022, remittance information is defined as structured information however a payment can carry either unstructured (XML element called Ustrd) or structured (XML element called Strd) remittance information[1]. The unstructured remittance item is a simple field of up to 140 characters and therefore offers similar capacity and constraints to the MT 103. Unlike the MT 103 however, this is a repeating field so the ERI for 2 invoices could be placed in 2 unstructured fields.
The structured remittance item is also repeating but is a complex field, containing many sub-fields, each designed for a specific data point which must conform to a specific data type. The sub-fields, such as document date, can be easily and consistently identified and can have specific validation rules applied to ensure data integrity and support automated reconciliation.
An example of unstructured vs. structured remittance information can be seen below at Figure 1. This shows 2 commercial invoices each with 3 data points; invoice number, invoice date and invoice due amount. In the unstructured fields, implicit usage rules are evident given the data is structured into the 3 points; {invoice number} {invoice date: YYYY-MM-DD} {invoice due amount: 0.00}
SWIFT has laid out usage rules for populating the remittance data in the MT 103 tag 70 and apply similar rules to the unstructured data in the MX messages, as have other organisations who are also trying to bring order to what is otherwise a free-format text field.
Market Infrastructure ERI Limitations
The structured ERI on the right in Figure 1, whilst more verbose, is easier to understand, easier to validate and ideally suited to automated reconciliation. Unfortunately, whilst the ISO 20022 messages and business processes support structured ERI, most clearing systems and market infrastructures currently do not, hence the importance of the various ISO 20022 programmes around the world which include features to improve the situation.
Meanwhile, SEPA payments (SEPA credit transfers) are a good example of the current limitations. Whilst they use PAIN.001s to initiate the payment and PACS.008 between FIs, which provides for structured ERI, the infrastructure limits what can be passed to 140 characters. Generally, 2 options are permitted:
- to carry XML-structured remittance information of up to 140 characters including tags OR
- to carry unstructured remittance information of up to 140 characters
Using the 2 structured invoices in the Figure 1, according to the SEPA limitations, under option #1, only the following 140 characters of ERI would be passed through to the Creditor’s Agent with the payment:
<Strd><RfrdDocInf><Tp><CdOrPrtry><Cd>CINV</Cd></CdOrPrtry></Tp><Nb>94584337</Nb><RltdDt>2009-10-31</RltdDt></RfrdDocInf><RfrdDocAmt><RmtdAmtThe above extract demonstrates the disadvantage of the verbose nature of XML; the XML tags consume most of the available 140 characters and only 2 data points from the first invoice will be passed. Within SEPA, most corporates are accustomed to this limitation and instead will adopt option #2 – sending only a single unstructured field in their PAIN.001 payment, usually a space delimited string of invoice numbers.
It is important to note that within SEPA, not all banks apply the same logic as described in the 2 options described above. Some, for example, will iterate through the structured ERI and extract their own defined fields, copying these into the unstructured tag with their own delimiter symbol in the onwards PACS message.
The European Association of Corporate Treasurers (EACT) also identified this SEPA ERI limitation and proposed their own set of formatting/usage rules[2] to bring some order to this unstructured ERI field.
Observation of corporate SEPA payments will also show another common effect of the ERI limitation. Many corporates, who would normally want the efficiency and cost-effectiveness of batching invoices into single payments, instead will generate one payment per invoice. This ensures the key invoice data is passed to the supplier but significantly increases the number of payments with the associated cost and related impact.
Planned Improvements
Given that business-to-business transactions have a considerable and recognised need to carry ERI, around the world there are several market infrastructure upgrades ongoing, most as part of wider ISO 20022 migration programmes. Some are ambitious – Payments Canada modernisation programme[3] plans to support 100,000 structured remittance items per payment, this improving from the existing Standard 005 payment message which doesn’t support any ERI. Others, for various reasons, will initially be adopting a like-for-like ERI migration.
PACS.008, REMT.001/002: Payment Remittance Information
“FIN MT 103 limits ability to convey remittance information to 140 characters and even the 9000 characters in the MT 103 REMIT might not be sufficient.”
SWIFT ISO 20022 Migration Consultation Study, 23 April 2018
Whilst these improvements are welcomed, those programmes adopting a like-for-like migration, for example UK CHAPS system and SWIFT CBPR+, the latter offering the same 9,000 characters of ERI as the MT 103 REMIT, may still fall short of meeting the needs of corporates. In its own consultation in April 2018[4], SWIFT acknowledged the need to potentially rethink this 9,000-character limit. As at the time of writing this white paper, this limit remains extant. Other upgrades, planning to impose a similar limit on ERI, will potentially impact corporate payments and it is therefore, worth examining the implication this will have on business-to-business transactions.
Corporate Requirements and Volumes
For business-to-business transactions such as supply chain scenarios, the 2 end-to-end parties, the buyer and supplier, need to know the limits imposed and configure their AP / AR processes to work within them.
Corporate AP departments will want to know how many invoices can be batched and sent in a single payment through the given bank/system/currency without causing the payment to be rejected. Generally, the number of invoices able to be carried in a payment without exceeding the limit, will be determined by the richness of the data in each invoice – the invoice profile.
Generally, in a simple, happy path scenario, a supplier would be able to reconcile using only the invoice number/ID. In our earlier example, there were 2 invoices for EUR 101.98 and EUR 1287.71. The supplier’s AR department would, when reconciling these 2 invoice numbers passed with the payment, be expecting to receive a payment for the sum of the invoices – EUR 1389.69. If this matched the instructed amount of the payment, no other ERI would be needed.
In an unhappy path scenario, for example where the buyer sends a payment for less than the sum of the invoices, such as in a short-pay scenario (e.g. pricing error or incorrect quantity of goods received) which is common, the AR department would not be able to reconcile on the invoice number alone. They would require more data about each invoice to determine exactly why the payment amount did not cover the sum of the invoices – which invoices can be set to paid, which need investigating further. To facilitate this, more data points will be required, such as the invoice gross amount, due amount, adjustment amount etc.
Current ERI Benchmark – US Nacha CTX
ERP systems are often configured to include the optimum invoice data (Strd remittance information) in the payment instruction (PAIN.001) they generate. To better understand the volume of invoice data needed, we should look at the clearing system and payment format that sets the current benchmark for ERI – the US Nacha, ACH Corporate Trade Exchange (CTX) message.
A domestic, USD, business-to-business ACH payment through the US Nacha network, can use the CTX payment format which, like the PAIN.001, multiple payments can be included and batched according to the debtor account and execution date. Each payment (record 6) can have up to 9,999 addenda records (record 7) which carry the ERI. CTX is a fixed width format and each record 7 is 80 characters which therefore offers a total of 799,920 characters of ERI. Further details of CTX and how ISO 20022 currently integrates with it, can be found at Appendix 1: US Nacha CTX.
As with the SWIFT CBPR+ ERI limit, quoted in number of characters (9,000 less tags), we need to convert the CTX limit of 799,920 characters (or 9,999 record 7s) into a meaningful measure – the number of invoices.
The following estimates have been derived from collaboration with a Nacha participating bank, sending and converting test PAIN.001.001.03s into CTX. These results, which will vary between banks given they apply different conversion logic, demonstrate that CTX can support between approximately 2,400 – 12,400 invoices per payment depending on the richness/profile of the invoice.
It is important to note that CTX carries the ERI as an embedded EDI 820 message, split into 80-character lengths in each record 7. This means some of the available capacity is consumed by the data labels/tags in addition to the data values.
– Lightly Populated Invoice Profile
- Estimated number of Record 7s per Invoice: 0.8
- Estimated number of Invoices per Payment: 9,989[5] / 0.8 = 12,486 invoices
– Average Populated Invoice Profile
- Estimated number of Record 7s per Invoice: 1.5
- Estimated number of Invoices per Payment: 9,989 / 1.5 = 6,659 invoices
– Heavily Populated Invoice Profile
- Estimated number of Record 7s per Invoice: 4
- Estimated number of Invoices per Payment: 9,989 / 4 = 2,497 invoices
Planned SWIFT CBPR+ ERI Capacity
If we apply the same invoice profiles as above – lightly, average and heavily populated – the planned 9,000 characters of ERI for SWIFT CBPR+ would support between 43 – 272 invoices per payment. This limit includes the data values and excludes the tags.
Afternote: both Swift CBPR+ and BoE CHAPS, along with other FMIs, have implemented a textual rule supporing up to 9,000 characters.
– Lightly Populated Invoice Profile
- Number of characters (excl. tags) per Invoice: 33[6]
- Estimated number of Invoices per Payment: 9,000 / 33 = 272 invoices
– Average Populated Invoice Profile
- Number of characters (excl. tags) per Invoice: 71
- Estimated number of Invoices per Payment: 9,000 / 71 = 126 invoices
– Heavily Populated Invoice Profile
- Number of characters (excl. tags) per Invoice: 205
- Estimated number of Invoices per Payment: 9,000 / 205 = 43 invoices
To maximise the number of invoices per payment, the use of ISO 11649, Structured Creditor Reference, should be considered with bilateral agreement between supplier and buyer. The sole use of a Creditor Reference (maximum 25 chars) with no other invoice data, could extend the number of invoices to approximately 310 (depending on whether the SCOR code is included). As mentioned previously however, without other data such as invoice amounts, unhappy path scenarios may be difficult to fully reconcile.
Invoice Batching
Corporates invariably want to batch invoices into as few payments as possible. Table 1 offers an indication of the number to be expected based on the indicative company size. This is based on observations across various markets/countries but focussed on the US, where the CTX format doesn’t unduly constrain the AP batching processes. Corporate payment files containing 10s to 100s of invoices are common (weekly), 1000s of invoices relatively common and whilst there have been instances of more than 10,000 invoices to a payment, these are relatively rare.
Overlaying the number of invoices that were calculated in the previous section, will show that CTX has the capacity for all the company sizes in the table below. SWIFT CBPR+, with only 9,000 characters of capacity, would meet the requirements of micro, small and medium enterprises. Large and mega corporates, wanting to send more than 2,400 invoices, would need to use smaller batches and more payments.
Summary
ERI is essential in business-to-business transactions and the capacity offered in the US, through CTX, even though domestic and not cross-border, should be considered the current benchmark against which market infrastructure upgrades should strive to match and, ideally, exceed.
Corporates should work with their banking partners to understand the constraints in the end-to-end payment chain and optimise their AP processes accordingly.
Appendix 1: US Nacha CTX
[1] PAIN/PACS XSD permits both Ustrd and Strd but usage convention only permits one or the other.
[3] https://www.payments.ca/resources/iso-20022-resource-centre/technical-documentation
[4] SWIFT ISO 20022 Migration Consultation Study dated 23 April 2018
[5] 9,989 is used as it assumes the first 10 record 7s contain EDI 820 mandatory payment data.
[6] Assumes the CINV (or other) code and currency attribute are included.
