SAP Banking XML Transformation As a Phased Approach Bolsters Success Rate

DOI : 10.17577/IJERTV13IS120041

Download Full-Text PDF Cite this Publication

Text Only Version

SAP Banking XML Transformation As a Phased Approach Bolsters Success Rate

Shaik Gouse Basha,

Hyderabad, India

Abstract: Collections and payments are two very distinct activities pivotal to every Business organization. Depending on the size and nature of the business, the volume of the above can go into millions and more. These transactions are recorded as documents in SAP. Payments to Beneficiaries and collections from Customers are routed to and from the Banks where the Businesses hold Accounts. Large Organizations have specialized Treasury departments managing and monitoring these Accounts. SAP Banking XML transformation is a structured way of establishing this functionality in consonance with the infrastructure of the Banking partners. While embarking upon the transformations, Businesses have a choice to go for either a big bang approach or a phased approach in a staggered manner. This article describes the most effective approach to be pursued in order to achieve the highest success rate. A phased approach discerns and reckons the challenges in banking XML transformations and facilitates the seamless means of implementing the collections and disbursements.

  1. INTRODUCTION

    Business payments can be executed in various ways, predominantly of which are the ones executed directly from the Banks portal. Payments are required to be made on account of expenses, purchases (P2P), settlements and the like. In the present day, payments through the Bank apps are even more renowned. However, considering the levels of authorization and approvals, majority of bulk payments may be through the Banks portal. After the payments through portal, the accounting entries ought to be posted in the system manually. In case of SAP automatic payments, the erstwhile process was to use the flat file generated by the payment run in SAP and manually route it to the Bank for release of payments to the beneficiaries. The files contain the payment instructions according to which the banker pays the payees. But with the continuous improvements in technology, Organizations are recommended by the Banks to follow the XML specification for sending the files. The XML specifications are mapped in the DME file in SAP configuration and routed to the Bank without manual intervention. Many Organizations are using the XML files today for their payment needs.

    Collections are receivables from the Business customers on account of incomes, incoming invoices, sales, Order to Cash and so on. Customers can directly deposit into the Organizations Bank account against the invoice. In case of SAP, the Organizations collections team has to post the documents in SAP on receipt of the funds from the Customers, which is intimated by the Bank. This would be a manual process. When Sales orders are created in SAP, invoices are generated. Banks collect the money from the Customers. Businesses have leveraged XML files for the incoming payment details from the Banks. These files are processed in SAP for posting the documents.

  2. ROLE OF TREASURY, SOLUTIONS ARCHITECT AND SOW

    1. Treasury envisioning: For any Banking XML transformation to become a reality, role of Treasury department is very conspicuous and vital. For shortlisting of Banking partners and decision making on the Accounts in scope of the transformation, numerous considerations are factored by Treasury. First, the decision whether to go with a single Bank or multiple Banks is very meticulously dealt with. With the presence of businesses and offices worldwide, it may not be feasible to have a single Banking partner across the globe. For instance, a Bank like Citi may not have adequate branches in Australia and New Zealand. Likewise, RBC is popular in Canada for their presence and operations. Hence, it is usual for an organization to do business with multiple banking partners. Another important reason for preferring multiple Banks is to mitigate risk of relying on a single Bank at any point of time. Some organizations may, however, go with a single bank worldwide for disbursements and collections while implementing the XML solutions. It is termed as the Global Bank. Treasury may also choose to have distinct Accounts for collections or receivables and payables to streamline their operations. It is hence an important treasury function to choose the correct Bank(s) not only for the business functions, but also for setting up the configuration and customization in SAP as needed.

    2. Solution scoping: The Solution Architect in Banking Projects plays an interesting role in the sense that there is a unique skill set involved encompassing complete understanding of the banking nomenclature, processes and procedures both from the relationship and technical perspective. He is a person that knows SAP and has hands on SAP consulting experience. He can understand the Business processes and correlate them with the feasibility of technical solution. He has the ability to appraise what is good and not good for the Business and at the same time maintain the balance with the technology teams. He speaks the Banking language and has a profound understanding of payments and collections and how they emanate from and to the Bank. Besides working hand in hand with the solution delivery teams, this function has a strong trait to co-ordinate with the banking partners. Once the countries for a release are identified for Banking XML disbursements, the Solution Architect ought to assess thoroughly all the Bank Accounts covering various Banking partners that are to be scoped. It is a multi-fold effort wherein the existing documents are analyzed to know which of the bank accounts are active and dormant. The SAP set up of House Banks and Account IDs plus the GLs (General Ledger accounts) assigned are checked. A series of discussions are held with various geographic treasury groups to close in on the scope of accounts. The SAP transactions pertinent to the relevant GL accounts are also visited. The AP teams are consulted on a need basis. So also, the AR teams are liaised for any clarification required on the collections side.

    3. Statement of Work (SoW) is a comprehensive ready reckoner: The SoW comprises complete information of the number of Bank Accounts scoped for disbursements/collections. It outlines the SAP technical details such as Company Codes, House Banks, Account IDs, actual GL accounts, clearing GL accounts associated with each of the Bank Accounts and so on. It also gives information on location, country, currency, and payment methods of the accounts. The payment methods can be Cross Border wires, domestic ACH, RTGS, check payments, etc. It is a ready reckoner for all the stakeholders, viz, treasury, SAP delivery teams, business teams, etc. There are country specific requirements for some countries and those are captured too. For instance, the Boleto payments in Brazil need to be handled in a special way and a separate payment method is set up in SAP for the same. So also, ISR procedure in Switzerland needs special payment method and KIDNO for Norway. It should be noted that the relevant data, mostly derived from the master data such as vendor master or customer master may have to be shared in case of the special payment methods. The SoW also specifies if any new bank accounts have to be set up as part of the transformation. If so, it needs extra coordination by the Solution Architect with the Banks and the business teams. Each of the banking programs would need a separate SoW. It is very unlikely that payables and receivables transformations are andled through the same teams or in parallel. Hence, disbursements banking and collections banking projects will always have discrete SoWs. Collections SoW specifies the mode of incoming payments, GLs pertaining to the Bank accounts, currencies, country where the account(s) is held. The SoW, whether for collections or disbursements banking XML projects is signed off by the various stakeholders such as Accounts payable team, Accounts receivable team respectively and the respective treasury stakeholders including the Solution Architect.

    4. Agile or Waterfall model & DevSecOps : Agile is the usual preferred model for executing programs as of today. However, banking XML projects are on a different footing. It involves an enormous amount of coordination with not only Banking partners, but also with versatile business teams internally. Tracking program progress may sometimes pose challenges as the third parties operate as per their own response times and there will not be control over the timelines in case of the agile mode. The traditional water fall model is apt. However, it will depend on the buy-in from banks vis-vis responses on file validation before a firm decision can be taken on agile. DevSecOps can help ensure efficiency in development and operations. It will help in automation of testing, especially negative and volume testing which are important in banking projects.

  3. BANKING XML SOLUTION DELIVERY

There are specific stages of solution delivery regardless of waterfall or agile modes of execution. Although the

stages resemble those of other types of projects, there are subtle differences. The features of solution delivery are briefly elucidated based on case studies.

    1. Blueprinting, Realization, Testing, UAT, Cut-over & Go-Live:

      The foremost step is Blueprinting which refers to the complete design of the solution. Whether it is collections/disbursements, there will be complete analysis of the scope in terms of the company codes, geography, banks and accounts. The SAP Subject matter experts (SMEs) drive this process with the involvement of the stakeholders, namely, Solution Architect, business teams and designated treasury SPOC. The various payment methods covered will be studied and validated with what is present in the SAP system. For the payments XML project,

      any new payment methods, House Banks, Account IDs, DME changes, XML mappings, etc are all determined during this step. The mandatory country specific changes are validated and factored appropriately. Also, deviations from the standard SAP functionality needing ABAP customization are also identified. The outcome of the blueprinting is the functional and technical specification documents.

      Blueprinting for collections is pretty much the same design process except that the set-up of accounts for receivables is validated. The formats of the incoming files are agreed upon with the confirmation from Banking Partners. That SAP Lock box functionality is specific to USA is a well-known fact. The Banker collects the receivables of the Client organization from the customers of the Client organization and bundles them into a file against the invoices issued by the Client organization to its customers. The lock box file is sent to the Client organization by the Bank. The posting then takes place in SAP system of the organization. However, in EMEA, XML solution has been used wherein the Bank collates the receivables from various customers and puts it in the agreed upon XML format. The file is then transmitted to the payee organization through the host-to-host connectivity. Customers are dunned in SAP through a dunning program and the invoice details are communicated to the debtors, for them to make the payments to the Bank account of the organization. Details of SAP document posting expected of the solution are elucidated below. These are driven by the accounting principle of credit what goes out, and debit what comes in.

      IJERTV13IS120041

      (This work is licensed under a Creative Commons Attribution 4.0 International License.)

      Realization is the development of the solution as per the design arrived at, during the blueprinting. It includes completion of the SAP configuration and development, or enhancement of any customized ABAP code as required. For disbursements, payment methods, house bank(s), payment run settings in FBZP (transaction code in SAP) are accomplished. The Bank accounts in SAP are validated and new accounts are configured per design requirements. The relevant actual GL accounts for the Bank accounts and the clearing GL accounts in payment run settings are appropriately configured. The Data Medium Exchange (DME) mappings are done to ensure that the outcome of the payment run in SAP will result in an XML file acceptable at the Banks end.

      For collections, the Bank accounts for the incoming receivables are validated and the GL account mappings for accounts are completed. The dunning settings are configured. As the XML or other format file will be received from the Bank, the configuration for the posting of documents in SAP on receipt of such files is completed. The program envisages posting against the invoice information of various debtors contained in the Banks file.

      Testing in most scenarios is three-fold Unit, Quality Assurance (QA) and User Acceptance (UAT) testing. In Unit testing, the individual chunks of solutions are tested, mostly by the SAP functional and technical Consultants to ensure that the solution developed is working as per expectation whether it is disbursements or collections. Unit testing is followed by integration testing, which is end to end, may again be done by the Consultants as second part of unit testing. QA is performed by specialists other than the functional and technical personnel that developed the solution. For payments, automatic payment runs are executed, and the end-to-end flow is validated. The host-to host connectivity or the multi-bank connectivity between the System and Bank is tested by routing a few files to the Bank and examining the results. The push-pull process with the outgoing XML files is tested.

      For collections, sample invoices are shared for testing purposes. The Bank collates the incoming payments and populates the file(s) which is then routed to the organizations SAP system. The processing of the file(s) in SAP is tested and the document postings against the invoice information are validated. The GL balances are verified. Solution is thus unit and integration tested.

      UAT is the ultimate testing where the Business users themselves test end to end and check the functionality from all directions. Some organizations leverage Business Process Regression Testing (BPRT). But in most cases, individual business teams test. Business explicitly signs off the solution on successful testing which paves way for the movement of changes to the production environment of SAP. The process is alike for disbursements and collection transformations. It is important that regression testing is also covered as part of QA and volume testing assumes significance in the Banking XML transformations.

      Cut-over is about making the preparations before the changes are moved to the production environment. For instance, master data such as Customers and Vendors are updated in SAP production. File share paths are kept up and running, SAP transport movements are scheduled and monitored, stage is set for one dollar payment or one dollar collection. Cut over will have stipulated timelines and owners that take care of their respective tasks.

      Go-Live is preceded by the mandatory sign off by UAT and the stakeholders involved. It is based on Go/No Go decision and will factor results of the extensive end to end testing including volume testing.

    2. Collections perspective: Customers are dunned in SAP implying that the information related to the invoices against which receivables are ue from the former are communicated to those from whom amount is due. There are different types of solutions for the incoming payments. In the non-USA regions, customersâ payments into the Organizationâs Bank account are collated by the Bankâs software system and an encrypted XML (camt.053.001.02 or camt.054.001.02) file is generated that is routed to the Organization through a SFTP host-to- host connection. The encrypted file is then decrypted and processed in the SAP system. These files contain the invoice information for posting the documents in SAP for the receipts. There is another functionality wherein the Bank sends statement in BAI format which may contain the data pertinent to both payments and collections. The incoming bank statements are

IJERTV13IS120041

(This work is licensed under a Creative Commons Attribution 4.0 International License.)

  1. processed in SAP as part of the electronic bank statement functionality in SAP. The posting rules are set and configured to post documents based on the BAI codes contained in these bank statements. In case of disbursements, the BAI file shows the payments which have been made by the Bank, to the Beneficiaries from the Client organizations bank account. Hence these BAI codes are read in SAP and the relevant GL account is credited going by the accounting principle – credit what goes out. Similarly, the BAI codes for collections correspond to the funds collected by the Bank into the Client organizations bank account. Therefore, the relevant GL account is debited in SAP going by the accounting principle – debit what comes in. In some cases, Bank may transmit statements exclusively for collections. The statement is then processed to post the documents in SAP.

  2. Validation of files by Bank: A major prerequisite for all the banking disbursement and collection projects is the validation of files received from the SAP system of the Client Organization. The payments from SAP are triggered through the payment run, the outcome of which is the XML file containing the payment instructions to the Bank. The Bank essentially tests each aspect of the payment files to ascertain the accuracy of the payment instructions. Eventually, it is the Bank which releases the payments to the Beneficiaries through the appropriate payment method (Checks/domestic wires/cross border wires/ACH, etc). The Project team, especially the functional Analyst and the SA will have to work extensively with the Banks technical teams in the validation of the files and results communicated by the Bank. All the inconsistencies are meticulously examined and corrective actions are taken. The connectivity is also checked prior to the sign-off. The communication between each Bank and the SAP system of the Organization is either through individual Host-to-Host connection or through the SAP Multi-Bank connection. Multi Bank connection facilitates connectivity with various banks and financial institutions without the organization having to worry about the connectivity aspects. Same applies to collections too. Receivable XML Files are sent by the Bank to Client Organization where the files are validated in minute detail during the testing. Any defect or offending piece of information is appropriately handled either by asking Bank not to include such data or by eliminating such data on receipt of the files. The clean files are processed in SAP and the document posting is checked. Regular meetings between the technical teams of the Bank and the Organization are imperative. Timely responses from either side play a very vital part in the success of these programs. During the go live, it is a well-known practice to do one dollar test. In the case of payments, a one-dollar payment is initiated and validated with the Bank. Similarly, the Bank may send a minimal value collections file for processing in SAP on the first dispatch of incoming payments.

The Dashboards reporting the incoming and outgoing files from the Bank(s) dynamically give an accurate view of the file(s) transmission. These are useful for the technical team to monitor in a timely manner. The incoming statements are utilized for automatic reconciliation postings, where now a days Machine Learning algorithms are selectively applied for optimal coverage.

(IV) Phased Approach increases success rate

Apparently, XML transformations whether payments or collections are two distinct Programs and need not be clubbed together. It is up to the Business to decide what type of approach will be apt in the larger interests of Treasury and organization. Treasury needs to know the availability of funds in a group of selected Bank accounts at any point of time. A lot of strategic decisions emanating from the CEOs office solicit this visibility most dynamically. While it may be a wishful thought process to go for a big bang approach for Banking transformation, the versatility of regions, Banking partners, local laws and business teams must be taken into consideration. Treasury has operations all over the world, but the Banking partners may differ geographically. So do the business teams such as Accounts Payables, Accounts Receivables, General Ledger, Authorization, etc. These are diversified across geographies and will cater to the functions of their respective areas. So, to have the same transformation cover global regions is a high risk plan and may most likely falter. Why should it be so? There is a lot of dependency not only on the Organizations business teams, but also on the various other teams including third party agencies such as the Banks. For instance, the Banking partners are different in APAC, EMEA, North America and LATAM. Each Banking partner will have its own solutions and technical plans and timelines which may not synchronize with the other Banking partners. The solution being rolled out globally may not be totally compatible with all the Banks in which case there will be a compromise/adjustment on the design and plan. Some of the countries such as Norway/Brazil have country specific payment methods and functionalities which will have to be taken care of. This may be difficult when a global big bang solution is pursued. There is a risk of too many meetings involving too many teams with the various Banks running in parallel. Tracking and managing the transformation will become a challenge and will very likely result in slippage of schedules and milestones. This will in turn impact the budgets adversely, let alone the loss of time. This will also have an adverse impact on the other Projects that are on hold due to the banking XML transformation thus leading to chaos. As the Banks follow their own schedules in the validation of the files, whether disbursements or collections, it is a huge challenge to secure synchronization or alignment amongst the Banks response times and updates. This will badly hit the program schedules. The Host-to-Host connections and their maintenance with discrete Banks will be overwhelming where there is 1:1 connectivity. Dropping of files during the various phases of testing needs enormous monitoring. It is in the best interest, under these circumstances, to go for a staggered approach targeting a group of geographical regions one at a time. It could involve the same Banking partner for the region or there may be multiple Banks across the countries in scope of the wave. The scoping, demand management, project execution, UAT, Bank validation, etc will be smooth in a phased approach. There is very little chance of schedule slippage in case of phased approach to Banking transformations.

V. CONCLUSION

A staggered or phased approach to implementing the collections and disbursement XML solutions has a high probability of success and can hardly see any slippage. Phases based on geographic scoping suit all the stakeholders including Treasury, AP/AR Business teams, SAP Delivery teams. The collaboration with different Banks is seamlesly facilitated as there is a structured alignment with the Client Organizations IT teams. Based on experience of Banking XML Programs across the globe (Case studies considered: North America, Canada, EMEA Canada based world class information/media Company, APAC/EMEA/LATAM US based world class IT product company, Middle East/Africa North America based world class information services company), it is observed that there is more than 95% success rate in transformations executed in phases and these are completed on time with no misses.

REFERENCES

  1. SAP Help Portal – Overview on Automatic Lockbox Processing

  2. SAP Learning – Processing Automatic Payments

  3. clear.in – https://www.clear.in ACCOUNTS PAYABLE, SAP Transaction Codes List for Accounts Payable Clear

  4. SAP Help Portal – Manage Automatic Payments: FAQ

  5. Fiori Apps Library – Post Incoming Payments – SAP Fiori Apps Reference Library

  6. SAP Community – SAP Multibank Connectivity Integration: BASIS Perspective

  7. Intelligent Automation with SAP S/4 HANA Situation Handling for Cash Management – Nibedita Gantayat

  8. SAP Help Portal – Post Incoming Payments

  9. Enterprise System Integration Capabilities: A Case Study Using the SAP Exchange Infrastructure and BPM – Andrew Ciganek[1], Marc N. Haines[2], William D. Haseman[3], Thomas Ngo-Ye[4]

  10. SAP bank interface example – Cao Xiaoming

  11. Enterprise Resource Planning (ERP) Systems in Banking Industry: Implementations Approaches, Reasons for Failures and How to Avoid Them – Salim Ahmad1, Suleiman Ibrahim1, Salisu Garba2