SEPA: Corporate Reconciliation
By initiating a payment to your long-term and trusted vendor, how would you electronically express that you’re now paying all 30 of the vendor’s purchase invoices for last month when you are limited to 140 characters for this message? Or, vice versa, how could the vendor reconcile this payment with those 30 invoices in its accounts receivable? There might be a couple of invoices with discounts, and maybe a large credit note. The answer is: ‘There’s no way.’ Even though we as individuals can be very creative in expressing all sorts of ideas in a 160-character SMS message, the same is not possible in business-to-business electronic banking. Yet the European Payment Concil’s (EPC’s) rulebook only gives corporates this much space for remittance information per payment initiation. The limit applies to new Pan-European Automated Clearing House (PE-ACH) clearing, and banks are not obliged to deliver more remittance information.
Most payment transactions are one-invoice-per-payment transactions. In particular, private customers’ payments are made according to that rule. Also direct-debit transactions will pose no problem for remittance information delivery unless the national clearing system is able to manage direct-debit credit notes as netting transactions, as is the case in Finland.
Rather, the problem arises in business-to-business invoicing and payment processing. Primarily in those situations where the business is part of a long-term customer vendor network, where vendors invoice their customers many times per month, disputes could occur concerning delivered goods or services that create credit notes and still the customer pays the vendor only once or twice per month, with the payment initiation including tens or hundreds of invoices. The customer wants to optimise its payment processing to produce as few payments as possible, and also the vendor derives huge benefit in its reconciliation when the account statement or advice report contains few and only clear credits. Banks usually charge both payer and beneficiary according to payment level, creating another significant issue to be addressed in payment initiation optimisation.
At the moment in Finland, and other Nordic countries as well, the local payment and reconciliation format allows an almost unlimited set of invoices (with structured remittance information credit notes) under one payment initiation. The same applies to more generic EDIFACT formats (PAYMUL with A, B, and C level and the same structure in CREMUL). In other single euro payment area (SEPA) countries, expressing inbound credit notes is impossible, so the responsibility for net calculation of payment initiations has been part of ERP systems’ accounts payable or middleware applications operating between companies’ accounts payable (A/P) and banks; therefore, this compromise solution is understood.
This generates, were it not so serious, a potentially amusing situation for Nordic banks in implementation of their UNIFI ISO-20022-XML-based payment processing. While ISO 20022 XML doesn’t limit the remittance information, the EPC rulebook implementation guide does. If the international corporate payment factory implementation wishes to use ISO 20022 XML as the format for all outgoing payments – which is a huge benefit for integrators and the group itself – instead of local payment processes for each country, they send the ISO 20022 XML file to their ISO-20022-XML-aware bank. The file contains SEPA payments and local payments in, for example, Sweden. The receiving bank will route the SEPA payments into the PE-ACH in accordance with the EPC rulebook and, if the SEPA payment includes more than 140 characters of remittance information, it will be truncated or, in the worst case, the payment will be rejected. Then the Swedish payment will be routed to local Swedish clearing, where no remittance information limitations exist and the only requirement is to apply the Nordic implementation guide (in the draft stage) for ISO 20022 XML. This is perceived as being unfair.
If I were a Finnish corporate CFO, I would postpone SEPA payment implementation for local Finnish business-to-business payment delivery until the end of the transition period, even though this would go against all rational arguments and EU and EPC SEPA goals. ISO 20022 XML really provides a huge opportunity to harmonise international payment factory implementation and its processes, and now the SEPA implementation of this remittance information delivery will cause all CFOs to rethink it. In their eyes, this is a clear point of reduced level of service.
It has been said that it is already impossible to change the EPC rulebook for both corporate-to-bank and bank-to-bank credit transfer messaging in order to bring the remittance information to the level it has in all SEPA-scope countries’ local clearing systems. If this indeed is the case, the options include:
The EPC and the EACT are currently discussing how to resolve this issue. Separate remittance information delivery from payer to beneficiary (as in RosettaNet) has been suggested, but because this has been a normal bank and clearing system service, no corporate CFO is willing to invest and pay for a project to implement this. This means not only creating point-to-point file transfer and security solutions for its vendors, but also the payer itself acting as invoice issuer and expecting to have proper reconciliation information from its own customers.
And who should provide this separate remittance delivery service?
One solution that has been put forth is to optimise the 140-character remittance info by overlaying an unstructured field based on de facto abbreviations, such as /INV/ indicating that an invoice number follows and /BFR/ indicating a beneficiary reference. This approach clearly violates XML ideology, in which each logical data unit has its own unique and explanatory tag in the file. This system also means that the capability of using these agreed remittance information ‘sub-tags’ should be implemented in all ERPs and middleware applications.
Using UNIFI ISO 20022 XML is a huge advantage and enhancement for corporate payment factory implementation. After the bank account statement and transaction reporting implementation guides are ready – one hopes this is soon – we can finally achieve real STP wherein the payment message is sent from payer to beneficiary and remains intact after all bank and clearing system processing, with no conversion at any stage of the delivery chain. This is one of the biggest arguments for centralised payment factory implementations. At the moment, the limitations enshrined in the EPC rulebook SEPA credit transfer implementation guide is a threat to the whole process.