Overview
Oracle’s Account Reconciliation (AR) is like an onion: there are layers to the functionality available and, therefore, a phased implementation approach is recommended. What are the three phases and the benefits of implementing each phase separately? Continue reading to peel back the layers of the AR onion!
Phase 1 – Tracking Only
The first phase of implementation is Tracking Only, which focuses on the built-in workflow capabilities within AR. Workflow is what allows users to be assigned to reconciliations and submit, review, and/or reject reconciliations within the system. With workflow, managers have instant access to reports and dashboards that display the real-time account reconciliation lifecycle. In addition, AR serves as a central repository where users can store supporting documents as well as make comments and certify reconciliations.
This phase is especially useful if a client does not have a current account reconciliation system and/or they would like to make changes to their current process. Because the Tracking Only phase is heavily process-focused, instead of technically-focused, the client can explore updating processes to match functionality available within AR.
Another benefit of Phase 1 is that requirements and design are transferrable to other phases. Oftentimes, when discussing processes and functionality, clients will begin to explain current pain points as well as their needs and nice-to-haves. While most of the requests will be filled in a later phase, it is helpful to approach Phase 1 with a holistic approach to allow for successful later phases.
Phase 2 – Reconciliation Compliance
The second phase of implementation is Reconciliation Compliance, which focuses on data integrations and allowing users to complete reconciliations within the system. Instead of uploading supporting documents after the reconciliation is complete, users will begin entering different types of reconciling items before submitting reconciliations. Users can also take advantage of built-in amortization and accretion schedules as well as aging calculations.
The other main benefit of the second phase is that data will be loaded from source systems. For example, balances from the Trial Balance will be loaded for all accounts. For specific accounts, additional data may be loaded to allow for Balance Comparison reconciliations. Generally, this data may come from either a sub-ledger or an external system. Examples include Accounts Payable Sub-Ledger, Fixed Assets Sub-Ledger, Bank Statements, and more. Now, all balances will be present in one system, allowing for a more streamlined and auditable reconciliation process.
Phase 3 – Transaction Matching
The third and final phase of implementation is Transaction Matching, which focuses on the auto-match capabilities available in AR. Because Transaction Matching is treated as a separate module within AR, this functionality can be layered on after the other two phases have been completed.
Based on how the client currently matches, as well as how they would like to match in the future, Match Rules are created in AR. These rules will dictate which transactions will be auto-matched and how the matches and unmatched items will be presented to the user. This functionality is especially useful for accounts that have a large number of transactions that can be matched based on criteria such as Amount, Date, Description, Invoice ID, Vendor ID, etc.
Further data integrations for transactional data will be required for this functionality to be used. That being said, this phase presents the most opportunity for process improvement as automated matching can decrease the time taken to complete account reconciliations considerably.
Interested in learning more about Oracle’s Account Reconciliation? Connect with our team today.
