Information Flows in the Financial Supply Chain - Part 1: Acceleration Through Collaboration
Bank of America’s William Jetter talks to GTNews about the perennial problems of Information connectivity in the financial supply chain
GTNews: There seems to have been quite a lot of discussion lately about the concept of collaborative capital management by agreeing payment terms across the entire supply chain upfront. How common is this in practice?
WJ: I have to say that this is the exception rather than the norm at present, though you do see some examples in industries such as electronics. For example, a contract manufacturer will take on the role of managing and agreeing payment terms between the customer and the suppliers. Some companies don’t see the value of this and would simply prefer to squeeze the balance sheet of everybody downstream of themselves in the supply chain in order to improve their own working capital position. However, others see this as a short-term attitude that is likely to result in supply disruption as suppliers are forced out of business as a result.
GTNews: Would direct participation by the banks in this collaborative capital management process serve to make its adoption more widespread?
WJ: I think that’s certainly a possibility. We’re certainly considering ways in which we might finance accounts receivable and payable to equalize the payment timings between buyers and sellers within the chain.
GTNews: What about bank participation in managing the information flows rather than just the finance element?
WJ: That’s already happening – dealing with the transfer of information relating to payments has been part of our working capital management services for some time. We can obviously do this via EDI, but also by using generic Web technology to facilitate information flow between buyers and sellers with widely differing levels of automation and technology adoption. For example, a payer using an ERP system and wishing to pay electronically can send the details to us and we can send the payment electronically and deliver the associated remittance information to the recipient via Web browser.
GTNews: So is the process always triggered by a payment?
WJ: Not necessarily. We’ve observed that in many cases in order to achieve true end-to-end automation it’s necessary to become involved even earlier in the value chain process by working with client purchase orders or invoices. For example, a complete purchase order to pay service will allow the buyer or importer to submit purchase orders electronically – either in EDI or proprietary format. That purchase order, plus details of any associated payment conditions, can then be presented to the vendor in an appropriate format. In the case of a cross border trade, the automated creation of a suitable payment instrument (such as letter of credit) can also be included in this process.
Once the order is complete, a paper-based vendor would present all the relevant paperwork (such as an invoice or trade documents) to our operations department where it would be keyed into our automated matching system, reconciled with the original purchase order, and an invoice automatically transmitted to the buyer electronically. We are currently investigating how best to replace the manual re-keying stage with a mechanism that will allow vendors to create electronic invoices that can then be automatically reconciled with the original purchase order details.
Under this scenario the vendor benefits through paperless document submission, while the buyer receives all the necessary electronic information to perform automated payables reconciliation. If the buyer is using paperless delivery processing, then the automation will even include the goods inwards stage, where the bar codes on the shipment will be scanned to confirm delivery electronically.
GTNews: But that of course assumes that the buyer is taking a paperless approach in the first place?
WJ: Precisely. In fact it’s rather ironic that despite all the effort that has gone into creating standards, one of the biggest problems is that there are still some large corporates that prefer to print checks and send literally boxes of paper remittance information to their suppliers. The sheer size of these companies means that they represent a very significant obstacle to the free flow of financial information along the supply chain. Part of the challenge from a banking perspective is encouraging these corporations to move, if not onto a browser based system, at least onto EDI.
GTNews: One of the most commonly quoted obstacles to optimal sharing of financial information across the supply chain has been the lack of common standards. What’s your view on this – do you see the situation improving?
WJ: Yes, but there are some caveats. One of the problems from a banking perspective is that, for example, with XML we are seeing a lot of vertical marketplace standardization going on, but very little horizontal, regional, or even global standardization happening. So you might have the chemical industry define its own XML standard, but the electronics industry will choose something different. Initially this isn’t too much of a problem as the focus is on supply chain activities, such as manufacturing requests and planning. However once this is extended to purchasing, financial settlement and the banking industry become involved. Since banks have to deal across multiple industry sectors, their preference is understandably for horizontal standards, but instead they are being asked at present to support a raft of industry-specific XML standards for financial processes, which simply isn’t practical.
GTNews: So how does that affect the bank’s role in the chain?
WJ: It means that one of the more important functions we still fulfill is that of data translation hub between buyers and sellers. For example, a buyer may be sending remittance information in an ANSI X12 format, but the vendor wishes to receive that information in EDI format – we will perform the necessary data translation between the two.
Another increasingly important area is the interface between clients’ ERP systems and the bank. Establishing these interfaces usually takes weeks, or even months. To address this we have been working with various ERP vendors to establish ‘off the shelf’ integration packages to cut the implementation time – typically to a matter of a few days. In view of the XML issues I mentioned earlier, we’ve also been working with ERP vendors as they develop XML interfaces for their systems.
GTNews: Given the number of vendors and versions of ERP systems that some companies operate, surely you have the proliferation issue with these interfaces as you do with industry-specific XML standards?
WJ: In practice it isn’t too much of a problem as many corporations have been trying to rationalize their disparate ERP systems and will often use an internal hub, such as shared service centre or payment factory, as an aggregation point. As a result, there is only one ERP interface between bank and client through which, for example, payment requests are made and the associated bank reporting information is returned. As a result, it is very seldom that one has to interface with dozens of ERP systems within one corporation.