When it comes to system integration, Electronic Data Interchange (EDI), interfaces etc., the weight mostly lies with the architecture and technology supported by any of the systems communicating with each other; particularly with interfacing SAP to banks at a global level for processing bank payments and statements electronically. The design, to support scalability and alignment with future electronic banking standards, and the varying technologies used by banks, are often key drivers for such implementations. Now that we have accepted the enormous challenge involved, where does one start?
Below is a summary of some key areas to focus on during the blueprint and realization phase of implementing bank interfaces between SAP and internal/external electronic banking systems.
Architecture
Solution and Technical Architecture, taken through iterative phases, and validation across all stakeholders (often including the business/customer and the bank), is an exercise to not underestimate. I would in fact strongly encourage utilizing the SAP EAF methodology, or at the very least TOGAF, to get through this exercise successfully and produce the relevant planning and architecture artifacts.
At a more granular level, and this is usually the more exhaustive part of the exercise, take attention to work closely with technical experts from the bank and your ABAP developers to document the details behind each connection point (e.g. field mappings, file formats, transport mediums etc.). Having a comprehensive set of architecture diagrams, matrices and catalogs, that is “signed off” by your development team, the bank and the business (i.e. Finance/Treasury Departments), is a necessary exercise to establish clear understanding and confidence in the implementation.
Bank Directory
Configuring SAP with all your bank accounts, bank addresses, bank codes, branch codes etc. can be a long and exhaustive process, particularly when you need to validate every entry with the bank, and often times smaller banks in remote locations will have difficulty in providing this data accurately.
The satisfactory approach for this effort is to manage this information in a central database/file (e.g. MS Access or Excel), and purchase bank directory software to cross-check against and extract valid information from. Dedicating someone from your finance department to complete this exercise is often good practice, as they will likely have a relationship established with the banks and their respective account managers to streamline and expedite the process. Your technical team will also have to work very closely with your finance department resource and the bank to articulate the context/meaning of the relevant SAP fields that need to be collected (i.e. field lengths, descriptions, uses etc.).
Bank Software
Prior to your SAP implementation, it is very likely that you will come across bank software already being used by the A/P and A/R teams in your finance department. For example, Citibank’s CitiDirect online tool, or RBC’s AP Link software. Often times these client-based software tools will provide payment upload and statement download functionality via electronic methods. They would have already been setup with secured connections to their respective banks, and the end-users would most likely be familiar with the accepted file formats/structures. Involving these end-users at an early stage in the design is beneficial to validating field mappings, file formats, usability etc.
The complexity around this area is whether post-SAP you continue to use these tools simply as a file transport medium (i.e. SAP produces the outbound payment file, and the bank software automatically/manually uploads the file to the bank). This decision usually hinges on the level of automation needed, cost and time. Ideally, a fully integrated and automated solution via SFTP, direct connection or other means are preferred, however technical feasibility within your landscape can also be a challenge (i.e. security, network constraints etc.).
Field Mappings
Whether you go with SWIFT or EDIFACT or XML, you will need to invest a significant amount of time in mapping the fields of these standard banking files to the SAP IDOC fields accordingly. This exercise involves very close participation with the technical team at the bank, online resources (i.e. UN/EDIFACT standards/conventions) and mapping/modeling software.
More preferably, implementing Seeburger’s Cross Industry Adapter can help in minimizing the workload here, as it provides template mappings and tools to conduct the mapping exercise more effectively. Close to a necessary piece of software, one can argue.
Monitoring
When it comes to monitoring inbound/outbound bank interface files, mastering the IDOC monitor (e.g. WE05) and PI Workbench might not be enough. Satisfying the real-time proactive behavior of your end-users will require something more usable, providing the necessary information to diagnose and resolve issues effectively. Navigating a wide variety of monitoring tools, one that comes as a preference is the Advantco PI Monitoring tool.
Project Management
Instituting some basic project management techniques, even Agile Management, is crucial during every phase of such an implementation. Consider using tools such as a regularly tracked and monitored issue list, weekly or bi-weekly status calls with all key stakeholders (i.e. bank, developers, business users, functional resources, IT department etc.). Keeping a steady pace, and closely monitoring every open technical issue is crucial.
EDIFACT vs. SWIFT vs. XML
Cost is a key consideration when it comes to selecting your bank interface standard; you could be looking at development and licensing costs varying on the order of 2-3 times and sometimes even 10 times more depending on the volume of bank payments and statements moving across your interfaces. The number of banks you interface to is also a key cost consideration; particularly when banks can be technologically challenging to interface with (e.g. banks in more remote locations that do not adhere to common standards practiced in North America or Europe).
From a technology perspective, SWIFT is the most ideal and effective technology to leverage as it is a more unified/centralized model for most banks, whereas XML and EDIFACT fall in second and third place. From a cost factor, you can expect the same order of each technology from most to least cost.
Transaction Codes
No, not SAP transaction codes… Bank transaction codes for every transaction line in your bank statement. More specifically, every bank has a set of credit/debit codes they use to identify a transaction (e.g. XC05 for Bank Clearing Fee etc.). Ok, so what’s the complexity here? Very simply, and shockingly, you will be looking at 100s upon 100s of transaction codes per bank to configure accordingly in SAP and map to their respective Clearing/GL account.
There is a sign of relief however, in that most of these codes can be defaulted to a set of accounts in SAP accordingly; this all depends on how your finance department prefers to configure them in SAP and what level of financial granularity you can compromise on. Again, maintaining a centrally managed list of these codes per bank in Excel is key; keep it aligned amongst everyone involved and updated as banks might change these codes over time.
Alternatively, and with respect to SAP transaction codes, part of conducting the end-to-end design, including business processes involved (for those fellow BPX’ers), consider the accounting transactions necessary pre/post the input/output of these electronic banking files (e.g. FB05, FEBAN etc.). Particularly key when conducting your integration testing.
Transport Medium
Several choices exist for transport mediums: Secure FTP (SFTP), Value Added Network (VAN), Odette FTP (OFTP), HTTPS etc.
Typically, this does come down to a cost and time factor; using one from the other can cost more or less depending on data volume, and can also be more/less complex to implement within your project time line.
Technologically, VAN, OFTP and SFTP are preferable due to their more wide support by banks. Implementing the right transport tool/software can also be an important decision; from the SFTP standpoint, one that comes as a preference is the Advantco SFTP Adapter tool.
In summary, effective planning, coordination with the bank technical team, concise and complete architecture and technology selection are some of the key ingredients to an effective implementation of SAP bank interfaces.
Supplemental to this is an interesting tool from SAP that supports a gamut of electronic banking features that might satisfy the needs of your project.