DCS recently completed EDI integration of a major company with its banks for SWIFTNet Network™ exchange of cash management and trade service financial documents.  The pairing of SAP financial IDocs™ and Sterling Commerce’s Integrator™ (formerly Gentran Integration Suite™) enabled a thorough, quick, and economical configuration.  The goal was to eliminate paper flow, delays, and inaccuracies.  A significant hurdle was the codes explaining the deduction taken.  Although the performance metrics are still being monitored, the cash management is now more precise.  The DCS customer also found that east Asian and South American banks have ample SWIFTNet experience and sound systems.

Overview

The key challenge with this company was to send accurate deduction information for invoices to minimize disputes. 

Here’s how it works:

1.     Financial data for vendors is extracted from SAP using an IDoc.  This means the existing payment control safeguards of the Treasury Module within SAP remain in place.

2.     A SWIFT format file is sent securely to the bank for forwarding to another bank. A copy can be sent to a third financial institution such as a factor.

3.     Simultaneously, the Remittance Advice (X12 820 or the EDIFACT PAYORD or PAYMUL) containing the payment information needed is sent to the vendor.

4.     The bank returns an immediate and detailed acknowledgement of the disposition of funds or error report.

GIS’s SWIFTNet module creates a map for all SWIFTNet Standards Release messages through the Map Editor.  All messages are validated by Gentran Integration Suite for syntax (that is, field types, field lengths, and so forth) and semantics. The SWIFTNet FIN standards data dictionary also contain the special exception and code word validations, as well as the code words and qualifiers necessary for the validation of the ISO 15022 messages (500 series) needed by you and the vendor’s bank.

The following messages are supported:

• All SWIFTNet 2006 message types
• SWIFTNet FUNDS
• SWIFTNet Cash Management (bulk payments, cash reporting, and exceptions & investigations)
• SWIFTNet Trade Services

The first step is to check your accounting or ERP system to learn if it has an EDI for payments module.  The next step, working with your treasury or accounts payable team, is to learn the potential savings.  A problem that some companies face is the perceived insecurity of e-payments.  Also, some vendors want the remittance advice information by Web form or fax. 

The treasury group works with their existing module, not the EDI system, so little disruption occurs. After a few key vendors are successfully implemented, you can get the rest on board at your own pace.

(SWIFT does not facilitate funds transfer. Financial institutions would need a corresponding banking relationship for financial transactions. The data format is standard; over 9,000 banks and 200 countries support the SWIFT format. In North America and elsewhere, most payees (such as your vendors, non-production vendors such as landlords, and government agencies) also support the X12 format for remittance advice data. Fortunately, the cost of modules and integration is declining so that even mid-sized companies can consider process automation for e-payments.)

Conclusion

DCS knows financial EDI and how to link existing EDI and ERP systems. Launching a few payees can be done quickly and economically to prove the concept. A roll-out of less than two months can then automate most payees and then payors. Considerable savings and a wider processing window can be achieved. Our DCS GROW™ Development Service ensures your implementation will be smooth and your cash flow uninterrupted. The first step is easy, e-mail DCS for your Free Assessment