SAP ERP provides a bank statement reconciliation process that reconciles open items based on the statement provided by the bank in predefined formats.
In many a cases, the banks provide a consolidated bank statements and supplementary lists with itemized details. The bank statement and the supplementary lost can be used as an input for reconciling non-financial or Non-FI documents in the same transaction control loop processing the message or a bank statement file. Here, the support required would be to take the input instructions and format this as per the structures that the reconciliation processes would expect and to ensure that the sequence expected by the reconciliation process is adhered to. In a typical case the adapter that is interfacing with the bank will need to transform the instructions and trigger the processes encompassing the different elements of reconciliation. Alternatively a better control would be if the reconciliation process will trigger the follow ups and the interface provides the structures that will trigger such a set of processes.
A challenge that the banks have is in providing reconciliation parameters itself. Many of these parameters have less banking values unless the banks want to mine the data which is not theirs. The banks - in this case - have to store the data and provide this information in the response to the corporate. These data can be subject to the business that the corporate is in. The bank will need to provision for large data stored and ability to access historical data.
If the payments in the corporate are structured in a way that a bank adapter - a central banking interface - has the reconciliation data that was triggered in the payment instruction to the bank, then the response from the bank can be enriched by the adapter to provide for the reconciliation parameters. Here reconciliation will not be on the end of the period bank statements but the status responses sent against individual payment sent by the bank. The advantage for the corporate would be that they will not be dependent on the bank for providing this data when an appropriate response that can be matched to the original instruction is received. The bank itself will not require storing the reconciliation data in a structured format and instead just route the instructions to the counterparties. Comprehensive reporting information on parameters other than that of payment will not be required to be elaborately maintained by the bank.
Each of the above has positives and negatives. The nitty gritties change depending on the nature of reconciliation and the size of the corporates. These are the stepping stones of the payment factories and shared service centers. There can be cost optimizations and efficiencies in terms of bank switch and others that can be addressed. There have been wide spread demands for online real time reconciliations. When we know that the payment systems give significantly quicker response than before why should the reconciliation process lag behind? The bank adapter should enable this and orchestrate the trigger.
The trends that I see shows that reconciliation is now one of the biggest pain points along with Remittance advice in corporate to bank connectivity. It is about time this issue is standardized and resolved.
