Some enterprise systems with cash management modules deliver integration but sacrifice functionality. And linking specialized cash management software to integrated systems poses a host of problems. But companies are saying it's all worthwhile.
Corporate financial managers who work in shops that are converting to enterprise information systems (EIS) like SAP, Oracle, PeopleSoft, Baan and J.D. Edwards are rethinking the way they receive and apply information from their banks. It some cases, integrating systems and data streams is changing how and where cash is managed.
"Managing cash will require a new mind-set," reports Sandra Mortakis, manager of cash management for $20-billion (sales) International Paper Co. (IP), Purchase, NY. International Paper is 26 months into a big SAP installation that has not yet reached cash management, but Mortakis knows it is coming. In about eight months, the corporate general ledger will convert to SAP, and cash management will need to build an interface to record cash transactions, she reports. "Fortunately, one of my staff members has joined the SAP A/R implementation team and can raise issues related to cash management," she adds.
"We continue to get our balance reporting in standard BAI format," Mortakis explains. "We track the aggregate transactions that affect our cash position and the details for cash accounting. Cash accounting is also where we reconcile our total cash/accounts receivable numbers with those accounts receivable/individual accounts. Once we're connected to SAP, the balance reporting for cash may go directly to A/R and do the reconcilement automatically; there will be no need to reconcile two different data streams."
At this point, cash management is a discrete activity. "Currently my staff controls all cash movements and entries to cash, but that might start to decentralize and be done within the enterprise system at the shared service centers," she notes. "We will need to be open to new processes and who will perform these functions."
IP has been using an InSight workstation from Chase Manhattan Bank, New York. SAP has its own module for managing cash. "We are not planning to use the SAP treasury module at this point," Mortakis reports, "but once we move to the SAP general ledger, we will take another look at that in 1999."
"U.S. companies typically get daily reports from five to 20 different banks and need detail of previous-day activities, some current-day controlled disbursement and lockbox reports and the ability to send payment information to two or three of those banks," says Lyndon J. Harvey, vice president of development for Selkirk Financial Technologies Inc., Vancouver, B.C., a vendor of treasury workstations specialized software that, among other things, collects and massages bank-reported data.
Press for Real-Time Information
Stimulated by the high interest rates that developed in the 1970s, corporate financial staffs made cash management a well-defined, centralized, high-priority activity. At most progressive companies, cash has been managed quite consciously, with keen awareness of the importance of liquidity and the time value of money. Even when staffs were downsized and specialized cash management positions were eliminated, cash management remained an important component of somebody's job. It was often automated but never eliminated. Solid, up-to-date knowledge of the company's cash position has become one of the key points financial managers steer by.
Financial managers in the future will know more about the corporation's liquidity, but they may no longer need a separate cash management function to collect and distribute that information. Cash management, as Mortakis suggests, may become an effortless by-product of other financial systems and data streams operating in an integrated environment.
Banks, the primary providers of cash management services, have been reading the writing on the wall. "We're taking a whole new view of information, considering it vertically as well as horizontally," notes Sue Jones, senior vice president in Wachovia's treasury services, Winston-Salem, N.C.
"We are used to providing end-of-day data transmissions, communication events that occur after all transactions for the day have posted," she explains. "In the future, that may be too late. Practitioners want to be able to slice and dice the data on a real-time basis. Instead of one daily transmission, we may see multiple transmissions throughout the day. We could be heading for a database that is constantly updated in real time as transactions occur, database enterprise information applications we will be able to tap at any time."
Specific cash management services like account reconcilement, something banks often sell today, could become extinct as single integrated systems no longer leave separate sets of numbers that need to be reconciled, she notes. "Banks will have to study exactly how the enterprise systems work and then build products that will integrate with these systems," Jones says.
But some bankers find the corporate movement to enterprise systems is actually making their jobs easier by consolidating the reporting process and reducing the number of separate accounting applications bank reports have to feed, says Ian Emery, client access product executive for Chase Manhattan Bank in Europe and liaison for the strategic alliance Chase has formed with SAP. And if companies use a treasury workstation specialized software for collecting bank reports as well as debt and investment activity, foreign exchange and risk management getting bank-reported data into the enterprise system is quicker and easier, he reports.
Lines to Three Camps
Currently, banks feed data to some or all of "three camps" in a corporation, Jones says:
- 1. The cash management camp, which needs summary information showing the debits and credits to cash but not details about who is paying or being paid.
- 2. The accounts payable camp, which needs specific detail identifying individual payments that have cleared the banking system.
- 3. The accounts receivable camp, which also needs specific detail identifying which customers have paid what invoices so that it can post the payments and close the receivables.
One company that receives bank data in all three camps is Orica Australia, Melbourne Pty. Ltd. Some camps are tougher to interface than others, Orica learned. It took many hours of internal programming three or four years ago to develop an interface between the A/P system and the Chase PaySource service, recalls Ron Willis, information technology (IT) consultant. Orica exports files of payments it wants Chase to make on its behalf, payments that originate at a host of Orica business units based in New Zealand as well as Australia. Orica is phasing in SAP but has yet to switch over its A/P, so transmissions originate in the Millennium legacy system.
Part of the interfacing cost went for security, including authentication software that had to be purchased and linked to the sensitive transmissions. Partly due to security concerns, all payment files were passed through the Orica mainframe and its one authentication routine and interface with PaySource.
Orica also uses Chase for wholesale lockbox and a receivables matching service. Once a week, Orica sends Chase a file of outstanding invoices, and Chase tries to match incoming payments to open invoices to create a lockbox transmission that will post automatically to Orica's accounts receivable and close a high percentage of the open receivables. The transmission comes "in a format we can load up to a screen within SAP in what is known as a BDC session and apply," Willis explains.
Orica gets balance reporting statements from Chase that "with some massaging are converted to journal entries and passed back to the Millennium G/L," Willis explains.
When there is an enterprise system on the corporate end, it means interfacing with up to three different modules of the system. What these modules need to perform their functions governs the content that the bank sends and the format that it uses. Lockbox data transmissions usually come in BAI format. The A/R components of most enterprise systems are built to receive BAI files, Jones notes, so complex translators and interfaces are not required.
For outgoing payments from A/P, including a growing number of international payments, the emerging standard is another banking format known as SWIFT (Society for Worldwide Interbank Financial Telecommunications). Normally companies with enterprise systems want to receive A/P data in SWIFT or EDI format, Jones reports. Most banks use translators that contain multiple formats; the company can pick the format that best suits its enterprise A/P system, and the bank just sets the dials and transmits in the format specified by the company, she explains.
Translators sound like just what the doctor ordered, but corporations balk at using translators in A/P, where the primary process often is exporting data from the enterprise A/P system to the bank, not taking bank data into the enterprise system. "If corporations want to outsource payments to a bank, it takes some customization on the front end," notes Terri Cahill, vice president and senior product manager for global receivables management at Chase.
"They don't want to invest time or money in translators," she reports. "They are asking their banks to develop a convention that will allow them to export a flat file without running it through a translator." Banks would need to develop one such convention for each major enterprise system, essentially providing a translator on the bank end that converts SAP payables files into something the bank can use. A second convention would be needed for Oracle, a third for PeopleSoft, and so on.
Bumpy Road to Automated Cash Application
The nearly universal use of BAI format for domestic lockbox transmissions relieves banks and corporate finance managers of a need for translation or reformatting software, but the application of the payments is not always so slick. Enterprise systems are well integrated and good at distributing data across a large workforce, but the functionality in many areas tends to be standard and shallow.
Stories abound about companies that switched to an enterprise A/R system and then discovered that they had lost their auto-cash application in the process: The transmissions coming in from their lockbox bank or banks no longer would post automatically to the new A/R system.
By all accounts, this situation is improving. "All major enterprise system vendors now have auto-cash processors in place," says Chase's Cahill, but there still are great differences in A/R functionality among the systems, she states. "Corporate financial executives will tell you which enterprise systems have good A/R systems and which don't. Many keep their old system operating until they are sure the new enterprise system will work," she explains.
Wachovia's Jones agrees that the receivables matching applications of some enterprise systems are "not as robust as the old systems." So banks that eventually may lose cash management services are being asked to take on new duties, at least temporarily, to protect the "hit rates" companies need to avoid a lot of manual posting in the cash application area, she observes.
And when companies with enterprise systems ask for a single integrated data transmission that combines data once directed to separate cash management, A/P and A/R addresses, that creates a lot of work for the bank. Receiving such a file makes life easier on the corporate end but harder on the bank, at least at first, Jones adds.
Buy Only as Much Integration as You Need
Maximum integration is not always optimum integration in the real world. At Canada's Manitoba Hydro, an electric utility company based in Winnipeg, for example, bank reports get from the company's high-tech Treasury Manager workstation to its high-tech SAP system by manual input. Treasury Manager, made by Selkirk, has a G/L interface that could automate the transfer, "but we don't use it," reports Gord Masters, cash management supervisor.
Why pass up available automation? Because the volumes of data to be input are so low that the $10,000 cost of the G/L interface is hard to justify. "It's not a particularly onerous task; entering the data manually into SAP takes five or six hours a month at the most," Masters explains of the month-end investment, borrowing and foreign exchange activity summaries that must be fed to SAP.
Where the volumes are high, the company does exploit interfaces. A file of cashed checks, for example, is prepared by Manitoba Hydro's disbursement bank in a form that can be fed directly into SAP's A/P module. And data from the remittance processing done by Hydro's banks are reported through the company's in-house customer service system. Hydro's internal information technology staff wrote programs to interface that system with SAP, and the connection is working well, Masters says.
|"Companies also are springing for new enterprise systems to avoid Year 2000 problems and to help them consolidate operations of acquisitions."|
Many companies place a low priority on interfacing banking data to an enterprise system. In the typical treasury operation, accounting takes between 2 percent and 5 percent of staff time, notes Selkirk's Harvey. "Integration with outside sources like banks, Reuters, TeleRate or Bloomberg are more important to treasury," he explains. Importing data from an enterprise system has more value for treasury than exporting banking data to one, he says.
Much of the efficiency of automation comes from programming business rules into software like a G/L interface, Harvey points out. "Instead of having to identify bank transactions manually to account for them, you can assign a journal entry profile based on things like a BAI code. When a transaction conforms to rules written into a template, the accounting code is assigned automatically," he explains. Writing those rules is about 90 percent of the work of creating an interface, he estimates.
Enterprise Solutions Here to Stay
The trend for corporations to adopt enterprisewide systems is no fad, Jones insists. They are expensive and disruptive to implement, but a lot of CFOs and other corporate financial executives have been sold on the long-term payoff, she notes.
"CFOs, treasurers and controllers are being measured on how much they add to shareholder value, so they are looking at how they can get results across the whole business," Jones points out. "It makes sense for them to invest in systems that let them manage information and inventories better across the enterprise.
"Companies also are springing for new enterprise systems to avoid Year 2000 problems and to help them consolidate operations of acquisitions," she notes.