Treasury and Trade Solutions

Emerging Trends in Straight-Through Reconciliation

For an increasing number of payment factories and SSCs (shared service centres) that already
achieve high rates of STP (straight-through processing), optimised expense savings and efficiency
gains, this article asks what many organisations want to know across the cash management and
liquidity spectrum: whats next on the agenda?

Phil Hong
EMEA Channel & Enterprise Services,
Treasury and Trade Solutions, Citi
Many companies reaching this position have turned their
attention to other costly operational activities such as
statements reconciliation. Companies anecdotally reporting
auto-reconciliation rates of 20% or 30% of bank statement
entries are struggling with largely manual processes to
complete the task. Their new target is achieving high
rates of STR (straight-through reconciliation), built on the
greater automation of the statement-matching process, and
significantly reducing the entries left to manual reconciliation.
Improving STR rates not only yields further process
efficiencies and savings, but also helps best-in-class SSCs to
achieve greater effectiveness by delivering real value-added
outcomes to their businesses. For example, better STR rates
help drive quicker cash application, reducing DSO (days
sales outstanding) and freeing up customer credit lines for
more business.
Citi recognised the new focus on STR several years ago, and
responded with a package of statement enhancements and
specialised reconciliation tools to help customers realise
their goals in this area. This is now an opportune moment to
reflect on recent experiences and pick out the trends that
point to future development.

Reconciliation best practices

Spend any time speaking to different companies about
their statement processing and reconciliation needs, and
you soon appreciate how these can vary by department
(treasury, accounts payable, accounts receivable), by local
in-country practices and even by system (e.g. TMS or
treasury management systems versus ERPs or enterprise
resource planning systems).
There are several ways of looking at these contrasting
needs, each of which brings a different understanding of
how to approach the issue.
Developing understanding of reconciliation needs
Improved Visibility
of Account Balances
OUTGOING vs
INCOMING

Adoption of direct
debits means
collections can also
be reconciled like
outgoing payments

PAYABLES vs
RECEIVABLES

FINANCIAL vs
OPERATIONAL

Traditional approach
applying different
processes and logic to
debits versus credits

Reconciliation viewed
in terms of TMS versus
ERP requirements

Accurate Invoice
Matching
Quicker Cash
Application
Reduced Manual
Intervention
STR Rates Up !

Financial versus operational reconciliation

A key part of the morning ritual in any TMS is the updating
and reconciling of cash positions across company bank
accounts via a daily upload of electronic bank statements.
From here, treasurers build an accurate picture of liquidity
and working capital, investment opportunities and funding
requirements for the day. This financial reconciliation
focuses on balances and net credit and debit movements
across the accounts.
By contrast, ERP systems need to operationally reconcile
payments and collections generated by the respective
purchase-to-pay and order-to-cash cycles of the business.
This level of reconciliation is more detailed and informationhungry, requiring transaction references, remitter
identification and remittance information delivered via the
payment networks and banks.
Proclaimed rates of statement reconciliation are generally
very high for a TMS but much less so for an ERP tasked
with operational reconciliation. Companies looking to
raise STR rates are typically those that recognise the
underperformance of their operational reconciliation, and so
they seek improvements in statement content for their ERPs.
Payables versus receivables
The operational reconciliation of payments and receivables
is traditionally conducted separately, applying different
reconciliation logic to the debits versus the credits on a
statement. Payments reconciliation recognises that a payment
run is a controlled activity against which there is a clear
record in the ERP of what debit amount should appear on the
statement and on which date. Finding a match for a statement
debit entry should therefore be quite straightforward.

Conversely, statement credits, representing receivables

from incoming payments and cheques, present a tougher
challenge. Additional remittance information might arrive
by separate means, in different formats and even at
different times than the bank statement. Achieving a threeway match between statement credit entries, remittance
information and open invoices in the ERP/sales-order
system will require sophisticated techniques with effective
automation relying heavily on accurate and complete
remittance information.
Payments reconciliation is clearly the low-hanging fruit,
and companies have invariably focused on improving STR
for payables first. Receivables reconciliation requires more
complex processing, spawning several specialist vendor
products in the market that employ powerful rules-based
matching engines to improve automated reconciliation.
Outgoing versus incoming transactions
With the increasing popularity of direct debits as a method
of collection, companies can initiate receivables as they do
payments, meaning that receivables can also be reconciled
on statements as payments are. By initiating a collection
run as a controlled activity on the ERP, there will again
be a clear record on the system this time for a known
credit that should appear on an account statement on
a given date. Reconciling a direct debit can then be as
straightforward as reconciling a payment.
Reconciliation best practices can therefore be seen in terms
of outgoing transactions, initiated by the company versus
incoming transactions initiated by its counterparty.

STR Best Practice

Outgoing Transactions

Incoming Transactions

STR-savvy companies assign unique transaction

references to each and every transaction (both
payments and direct debits).

Reconciliation logic must allow for different levels of

remittance info being supported by different payment
clearing systems.

Transaction references, also known as End-to-End IDs,

should not exceed an agreed length that banks can
support on statements.

Remitter behaviour is key; STR-savvy companies

educate their remitters on what info & references
should accompany payment.

Common practice is to limit references to max 16 chars,

in line with MT940 tag 61, subfield 7 (Reference for the
Account Owner).

Tailoring remittance instructions to respect local

clearing and reporting limitations will help address data
truncation concerns.

Bank account statements should report each

transaction as an itemised entry to include companies
transaction references.

In some markets remitter account numbers are

considered confidential, and cannot be reported in full
on statement entries.

Transaction references can also be used to uniquely

identify transactions on any reject response file or
payment status report.

Consider products and services that match externally

collected remittance info to bank statement entries.
Check whether these can automate matching in
non-BAU scenarios, e.g. aggregating invoices, split
payments, partial receipting, credit notes.

Recognise when batch booking entries are more

appropriate, e.g. payroll payments where confidentiality
needs to be respected.

STR and enriched statements

Conventionally, companies receive and load the same daily
electronic bank statement into both their TMS and ERP
systems. Yet for companies striving to improve STR rates
on their ERPs, there is a growing acceptance that different
types of statements, maybe even formats, are needed to
better address the different information needs of TMS and
ERP systems.

T
he need for reasonably generous 140 characters of
remittance information for receiving parties, supported
with options for structured (tagged fields) and
unstructured (free text) forms.

Some banks have responded to this by offering separately

generated enriched statement files for ERPs alongside their
standard SWIFT-delivered MT940 and MT942 reports for
TMS consumption. The enriched statements offer better
support of itemised transactions, detailed remittance
information and customer end-to-end references. As banks
develop greater sophistication in their file-based ERPoriented statements, the gulf between these and standard
TMS-oriented statements grows, giving companies real
choice to match their reconciliation needs.

Some communities, notably the Finns, have implemented a

SEPA AOS (additional optional service) to further enhance
the amount of remittance information that can be passed
with payment, eschewing the standard provision of 140
characters as inadequate.

A typical differentiated statement solution would feature:

The timely delivery of standard SWIFT MT940 statements
plus real-time MT942 intraday reports over the SWIFTNet
FIN channel to a company TMS.
The delivery of enriched file-based statements into one
or more company ERP systems via a host-to-host internet
protocol or the SWIFTNet FileAct channel.
Differentiated reporting for TMS versus ERPs

Bank 1

Financial Reconciliation

Bank 2

Standard SWIFT messages

FIN MT940
FIN MT942
FIN

INTERNET

Bank 3

FILEACT

Enriched statement files

SWIFT MT940
BAI
EDIFACT
ISO XML

Operational Reconciliation

STR and SEPA

Given that key parts of what companies look for in account
statements depend largely on what information can be
transported through the payment-clearing systems, you
might ask if there are payment methods that support STR
particularly well.
SEPA is an excellent example of a payment scheme that has
incorporated many of the information requirements needed
for efficient reconciliation, like:
T
he need for initiating parties to have unique transaction
identification embodied in the end-to-end reference.

T
he need to include distinct party identifier fields,
covering debtor, creditor, ultimate debtor and ultimate
creditor roles to help support POBO (payment-on-behalfof) and ROBO (receipt-on-behalf-of) scenarios.

Well, if information is king, could we now expect STRfriendly SEPA to help European companies achieve better
reconciliation efficiencies and cost savings than companies
operating with less STR-friendly payment schemes? Could
Finland, benefiting from an even more STR-friendly AOS,
enjoy a competitive advantage over the rest of Europe?
And where does that leave UK corporates, tied to an older
clearing system that caters for only 18 characters of
remittance information?
Levity aside, there is no doubt from recent experience in
Europe that the migration to SEPA is leading many companies
operating in the region to adopt STR best practices, such as
using end-to-end IDs to automate reconciliation.
STR and ISO 20022 XML
If SEPA is having a beneficial impact on helping
companies achieve better STR rates, can the same be
said of the format that is most closely associated with it:
ISO 20022 XML?
In recent years ISO 20022 XML has been very much in
vogue, with banks across the globe helping customers
re-engineer their payment and direct debit files into
this format. In Europe, SEPA has helped drive greater
corporate adoption of ISO 20022 XML, yet the camt.053
account statement message has been somewhat lagging
behind, despite it being a structurally better format for
presenting statement information compared to older
formats, such as MT940, BAI2 and EDIFACT FINSTA.
As a universal financial messaging format, ISO 20022
XML has enabled many companies to streamline and
standardise their use of payment formats globally,
replacing many of the local file formats that corporates
used to have to deal with.
However, for electronic bank statements, there has not
been the same proliferation of local formats to tackle,
and most multinationals have already standardised their
reporting on current widely-supported formats, such
as MT940. Some banks have also upgraded their more
established statements to report the richer data content
of newer payment schemes, such as SEPA, just as well as
the camt.053.

Ultimately, system support also becomes a major factor,

with out-of-the-box availability of ISO 20022 XML still
developing, even among some of the more popular TMS
and ERP systems.

Transforming the way treasuries do business

So how does a world-leading bank like Citi help leading
organisations and institutions the world over transform
the way they do business?

What can we take away from all this?

Corporate interest in STR rates and statement content
in general has never been higher. There is both a
growing recognition that statements reconciliation
is multi-faceted and a growing understanding of the
differentiated needs between financial and operational
reconciliation, TMS and ERP requirements, and the
different logic needed to reconcile outgoing transactions
and that of incoming transactions.

Treasury and Trade Solutions

Citi Treasury and Trade Solutions (TTS) offers the
industrys most comprehensive range of digitally
and mobile enabled treasury, trade and liquidity
management solutions, platforms, tools and analytics,
leading the way in innovation and customisation to
support its multinational corporate, financial institution
and public sector clients.

SEPA will have a beneficial impact on STR. While ISO 20022

XML promises the same, it has some way to go to rival the
popularity of older formats. Both developments confirm the
rising importance of information content as a prime driver
of achieving better STR rates.

With the industrys largest proprietary network, banking

licenses in over 100 countries and globally integrated
technology platforms, TTS offers deep local market
knowledge, expertise and insights to ensure its clients
can meet their strategic business objectives.

Banks, like Citi, and system vendors that have recognised

this trend in recent years have responded through various
product enhancements that today present customers with
a richer, more sophisticated set of statement capabilities
than ever before.

Find our more

Contact your Citi representative or find us at
transactionservices.citi.com.

transactionservices.citi.com
2013 Citibank, N.A. All rights reserved. Citi and Citi and Arc Design are trademarks and service marks of Citigroup Inc. or its
affiliates, used and registered throughout the world. The information contained in these pages is not intended as legal or tax
advice and we advise our readers to contact their own advisers. Not all products and services are available in all geographic areas.
Any unauthorised use, duplication or disclosure is prohibited by law and may result in prosecution. Citibank, N.A. is incorporated
with limited liability under the National Bank Act of the U.S.A. and has its head office at 399 Park Avenue, New York, NY 10043,
U.S.A. Citibank, N.A. London branch is registered in the UK at Citigroup Centre, Canada Square, Canary Wharf, London E14 5LB,
under No. BR001018, and is authorised and regulated by the Financial Services Authority. VAT No. GB 429 6256 29. Ultimately
owned by Citibank Inc., New York, U.S.A.
GRA24818

12/13