Projects:Flexible Bankstatement Rematching
Contents |
Flexible Bankstatement Rematching
Background
Generic: Account reconciliation is a very common financial best practice (http://www.accountingweb.com/article/best-practices-account-reconciliation-process/219543). Let me highlight three statements on this article:
Account reconciliation is an under appreciated yet critical control to help ensure an organization's financial integrity.
Weaknesses and inefficiencies in the reconciliation process often lead to mistakes on the balance sheet and overall inaccuracies in the financial close Ensure that the reconciliation actually supports the balance and is not just a repeat of the general ledger or a roll-forward of the balance.
The individual preparing and reviewing the account should have a basic understanding of what the account is used for and what should be used to support the balance.
For example, cash accounts will most often need the general ledger and a bank statement in order to perform the reconciliation.
In this project we are talking about a common utility provided by ERP systems to support Financial Accounts (Cash Accounts) reconciliation.
The design of this utility in Openbravo is quite standard: provides a way to compare bank information in the ERP (financial transactions) with real information in bank accounts (bank statements).
Financial departments need to synchronize these two sources before closing the accounting period.
The utility helps to clear bank-statement lines with transactions, so once cleared you can consider that information is OK and it does not need to be reviewed anymore.
This clearing gets confirmed by the reconciliation document, that reports the real balance in the bank in comparison with the bank balance in the ERP system, and explain differences on these balances (all bank statement lines not cleared yet).
Reconciliation is based on account balances so it is accumulative (the initial balance of a reconciliation is the ending balance of the previous reconciliation)
In general it should be exceptional to change a reconciliation since it is the document in which someone said "I've checked this info and it is OK".
In general it is a bad practice to change an "old" reconciliation since it means that all the reconciliations made after that one are invalidated (because the balances that were checked and validated are modified).
Purpose
All this said, there are two realities that we need to address: Many companies do not follow the best practice of reconciliation as a financial check, but just as the mechanism to "complete" the management of those Receivables and Payables, and get rid of those transactions from the management process (so they don't validate account balances during this reconciliation) Even in the case of "good practices" there are VERY exceptional cases in which the bank includes "old" transactions in a recent bank statement or even notifies mistakes on old bank statements.
With current design of the process in Openbravo, addressing the two realities above is a HUGE pain. So it makes sense to enable a mechanism in the process to "relax the rigor" and allow changes in old reconciliations that retroactively will update the balances of all subsequent reconciliations.
Design considerations
Some design considerations on this new mechanism:
There are two ways to change an old reconciliation in Openbravo:
- Import new bank statements with dates previous to the latest reconciliation
- Reactivate and modify an existing (not-latest) reconciliation
Both ways above need to be supported by the new mechanism.
It is of paramount importance to have:
- Full control on the usage of this mechanism (there should be a special privilege to use it, so our Customers can decide who is granted to use it)
- Full awareness of the impact of this mechanism (it can not be that someone changes an old reconciliation without being fully aware of the impact of that change). Before executing the change the system should raise a clear message explaining the list of reconciliations that are affected by that change (in general those should revisited and confirmed again, although we will not enforce it that).
Functional Requirements
Of course this change will require to unpost from the GL the accounting entries of the reconciliation to be modified, so it will not be possible if the accounting period is closed.
The new mechanism will not require a new UI since it will use the existing ones:
- Import bank statement will leave the bank statement not-processed if it includes old lines, and user will be able -with a new button- to process it (with the protection and awareness mentioned above).
- Reactivate reconciliation, now only available for the latest reconciliation on each financial account) but adding the new button to reactivate old reconciliations (with the protection and awareness mentioned above).