Cloud Maturity Model – Part 2
Oracle Financial Close, Data Management, & Account Reconciliations
During Cloud Maturity Model part 1, the EPMIcast discussed where they see our clients before their Oracle Cloud EPM journeys. Additionally, we presented strategies to roll out EPM functionality across Close, Planning, and Reporting business processes.
Cloud Maturity Model part 2 goes in-depth on advanced use cases of the Oracle Cloud EPM platform. The following short videos (2-4 mins) discuss Financial Close, Data Management, Account Reconciliations, and introduces Transaction Matching.
Limits of Microsoft Excel
Some of the biggest drivers to move off of excel include version control, broken formulas, and liability. Without automated version control, verifying the final version of a spreadsheet is difficult with multiple authors on a single report.
In terms of broken formulas, a single cell level mistake within excel can have cascading impacts on the entirety of any financial statement.
For publicly traded companies, relying wholly on Microsoft Excel for consolidated financials presents a risk for audit and fraud when reporting to Wall Street.
Automated Integrations and Data Management
Typically, we see our clients start with a file-based integration approach, leveraging an employee and Cloud Data Management to load the data into Cloud EPM. For a more detailed or live view of source data, we enable our clients to deploy the EPM Integration Agent to build direct connections to ERP source systems without human intervention.
Cloud EPM comes standard with a variety of integration utilities to reduce the legwork when exporting, translating, and loading data from source to target applications. The entire EPM platform is source system agnostic, and our team has integrated with everything from major tier 1 ERPs to industry specific niche systems.
Streamlining Account Reconciliations
When we are confirming reconciliation requirements at the subledger level of detail, we recommend the client is familiar with the type of data we are reconciling. Oftentimes, we can bypass heavy configuration work by leveraging out-of-box reports designed for specific subledger data types. However, we’ll only be able to align out-of-box functionality to subledger reconciliation formats if the client is knowledgeable in the type of reconciliation they seek to build. In a perfect world, we team with our clients to configure the ideal reconciliation format and report, develop a wireframe, and then work backwards to match out-of-box functionality to the desired end goal.
What is Transaction Matching?
When evaluating potential accounts for transaction matching, any account with a high volume of debits and credits is a great place to start. Examples include Cash Clearing, AP Clearing, and inter-company accounts between entities are all great candidates for transaction matching.
The jist of transaction matching is to make sure that invoices are being paid on time and to identify at risk or late payments.
As we configure the application, we define the match rules in the system. Essentially: “we need to match x invoice at y date based on amount/invoice number (or any other relevant and consistent metadata point).” The application will then pull invoice data and match them based on the rules in place.
The goal of transaction matching is to eliminate human error and time commitment in manually validating transactions from a data export. While human intervention is still required for high-risk matches based on the rules in place, implementing transaction matching makes for happy staff accountants.
Do you want to learn how the cloud maturity model fits into your business processes? Schedule a meeting with our solutions team!