Matching or Reconciliation?
We all use the term 'reconciliation' in a business environment to mean different things. This series of articles has sought to clarify its meaning. Let's revisit the typical lifecycle of transactional reconciliation activity: first gather the data and import it into a tool, next match the data applying any number of rules, then deal with any exceptions that are identified, and finally reconcile the account. Here we talk about the fourth phase of the lifecycle: Reconciliation. Often people refer to the matching process as reconciliation ("I have just completed today's bank reconciliation") when what they really mean is that they have completed the initial data comparison but not completed the reconciliation of the account.
Types of reconciliation
In practice there are two common types of reconciliation activity that take place. The first includes the frequent reconciliation of transactional based accounts. The production of a bank reconciliation (report) at end of day showing opening and closing balances with outstanding items provides a good example. Responsibility for this activity typically resides within a small focused team within Treasury or Finance.
The second, which occurs less frequently and typically at month or quarter end, can be spread across a much wide cross section of the business. It is the review of general ledger accounts - sometimes with supporting transactional activity, sometimes just beginning and ending or ledger to sub-ledger balances without such. The last decade has seen greatly increased focus on the periodic review and attestation of "significant" accounts that represent potential risk to the business as legislation such as Sarbanes-Oxley in the United States has mandated senior executives to certify that the financial statements they are issuing are accurate.
History of reconciliation solutions
Looking back to when automation started being used to across the reconciliation lifecycle we see some evolving trends. Initially the focus was all on automating matching activity to drive labor and, with it, cost efficiencies. Next came automation around the resolution of exceptions that the prior matching activity had identified, helping to better mitigate risk while driving down costs further. The second round of automation often built upon the first.
Then things changed. The last few years has seen the emergence of a number of tools to handle the attestation and certification of general ledger accounts, designed for a wide audience not involved in the daily matching and exception resolution activities of transactions. The primary focus has been on compliance to regulatory and legislative needs. But these tools have mostly been developed standalone and disintegrated from other reconciliation lifecycle activities, though they share many attributes in common.
Enterprise reconciliation
In an optimized environment the entire reconciliation lifecycle for all areas of the business and for all types of user should exist within a single environment. Whether it's a more frequent transactional reconciliation lifecycle, or a periodic balance only reconciliation, both share common activities: importing information, reviewing and comparing it, explaining any differences and how operational risk is being managed, and signing off on the reconciliation. Of course period end certification may require additional and multiple levels of review with prescribed workflows, but this is not wholly dissimilar to case management for the resolution of transactional exceptions.
We all use the term 'reconciliation' in a business environment to mean different things. This series of articles has sought to clarify its meaning. Let's revisit the typical lifecycle of transactional reconciliation activity: first gather the data and import it into a tool, next match the data applying any number of rules, then deal with any exceptions that are identified, and finally reconcile the account. Here we talk about the fourth phase of the lifecycle: Reconciliation. Often people refer to the matching process as reconciliation ("I have just completed today's bank reconciliation") when what they really mean is that they have completed the initial data comparison but not completed the reconciliation of the account.
Types of reconciliation
In practice there are two common types of reconciliation activity that take place. The first includes the frequent reconciliation of transactional based accounts. The production of a bank reconciliation (report) at end of day showing opening and closing balances with outstanding items provides a good example. Responsibility for this activity typically resides within a small focused team within Treasury or Finance.
The second, which occurs less frequently and typically at month or quarter end, can be spread across a much wide cross section of the business. It is the review of general ledger accounts - sometimes with supporting transactional activity, sometimes just beginning and ending or ledger to sub-ledger balances without such. The last decade has seen greatly increased focus on the periodic review and attestation of "significant" accounts that represent potential risk to the business as legislation such as Sarbanes-Oxley in the United States has mandated senior executives to certify that the financial statements they are issuing are accurate.
History of reconciliation solutions
Looking back to when automation started being used to across the reconciliation lifecycle we see some evolving trends. Initially the focus was all on automating matching activity to drive labor and, with it, cost efficiencies. Next came automation around the resolution of exceptions that the prior matching activity had identified, helping to better mitigate risk while driving down costs further. The second round of automation often built upon the first.
Then things changed. The last few years has seen the emergence of a number of tools to handle the attestation and certification of general ledger accounts, designed for a wide audience not involved in the daily matching and exception resolution activities of transactions. The primary focus has been on compliance to regulatory and legislative needs. But these tools have mostly been developed standalone and disintegrated from other reconciliation lifecycle activities, though they share many attributes in common.
Enterprise reconciliation
In an optimized environment the entire reconciliation lifecycle for all areas of the business and for all types of user should exist within a single environment. Whether it's a more frequent transactional reconciliation lifecycle, or a periodic balance only reconciliation, both share common activities: importing information, reviewing and comparing it, explaining any differences and how operational risk is being managed, and signing off on the reconciliation. Of course period end certification may require additional and multiple levels of review with prescribed workflows, but this is not wholly dissimilar to case management for the resolution of transactional exceptions.
No comments:
Post a Comment