View source | View content page | Page history | Printable version   

Projects:Flexible Bankstatement Rematching


Flexible Bankstatement Rematching


Generic: Account reconciliation is a very common financial best practice ( 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).


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:

Both ways above need to be supported by the new mechanism.

It is of paramount importance to have:

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:

Wiki Documentation

[Match Statement Force]

Retrieved from ""

This page has been accessed 3,612 times. This page was last modified on 17 March 2014, at 15:58. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.