By Sander Klaren en Marnix Theijssen
Currently companies from Honk Kong to Chicago are seeing the benefits of using a centralized accounting engine, in particular the Oracle Financial Accounting Hub (FAH), to connect their core business applications to the General Ledger. In earlier posts on this blog, the benefits of such a solution have already been noted:
- Finance can really be in control of their own accounting rules being applied throughout the company.
- Processing can be made more efficient and accurate, especially compared to manual efforts,
- Full audit and control becomes possible from financial report down to (accounting) event.
- The centralized processing provides accurate and consistent data across Finance applications such as General Ledger, Data Warehouse and Risk Management.
With this blog we mean to demonstrate Financial Business and Application Architects involved in improving the finance and accounting application architectures in their organisations, how to take the next step: to actually embrace the principle of a centralized accounting engine and move towards a more time and cost efficient, reliable and flexible solution for the Finance domain. From experience we know this requires more than just installing the software! So what are the pre-conditions that have to be met for the Oracle FAH to be successfully embedded in a modern, future-proof Financial Accounting Architecture? This will prove vital to really move forward in Finance and not let the FAH become a “toy” for IT!
The pre-conditions are related to:
- Vision on Financial Accounting Architectures.
- Sources providing accounting events.
- Control model aspects.
- Master data and process management.
- Supporting data warehouse.
Vision on Financial Accounting Architectures
A common vision on the business process of accounting is that it should be accurate, fully traceable, very cost and time efficient and reliable. Bringing Finance in control on their own business rules is an additional objectives meant to reduce risks: operational risks of not fully compliant rules and implementation risks by the reducing the dependency on critical knowledge and limited resources from IT.
Legacy architectures put heavy constraints on realising this vision by the fact that they are rigid and changes are cumbersome to make. A centralized accounting engine provides a way of taking away such constraints and to take the next step towards realising the vision:
- Finance becomes owner of the rules applied to accounting. This allows for more control and from there more accuracy and insight.
- Workarounds (e.g. manual efforts) that have been implemented to circumvent issues with legacy systems can be reduced. This improves cost and time efficiency.
- The accounting entries arising from the source system transactions can now be accessed through the standard Oracle E-Business Suite functionality. This improves the traceability.
We believe Oracle is going to make this architecture the corner stone of their accounting solution, doing so providing a sound basis for today’s and future requirements. Applying these concepts requires changes that cannot not be achieved over night. Preparing yourself for this kind of architecture should therefore be a priority today. We see implementing a centralised accounting engine as part of a process moving the Finance organization and the IT landscape towards the vision of an new Financial Accounting Architecture. This process can start right now with implementing FAH, but will not end there!
The picture below gives an overview of an architecture with an accounting rules engine.
Sources providing accounting events
In the target operating model sources deliver (enriched) transactions or events. For each event a set of accounting entries is derived based on a set of accounting rules. The generated accounting uses the shared Chart of Accounts and dimension values.
Examples of events for an Insurance organization are:
- New Interest Capitalization.
- New Interest Billing.
- Medical Bill Payment.
In Telecom, one could think of:
- (Aggregated) Revenue from usage based billing.
- Obligations from new contracts.
- Turnover from retail activities.
A key success factor in adopting the centralised accounting engine is to move the creation of accounting from the source systems to the centralised engine. This means that the standard (accounting based) output of the source systems needs to be replaced by a transaction or event based output. This is a necessary step in reaching the target architecture and will modernise not only the technical data delivery, but also the source related processes (e.g. reconciliations).
Making changes in the sources will have technical, cost and lead time impact but are essential for a successful adaptation of the new model. Luckily, a strategy can be adopted in which the change is made gradually across the application landscape (one source system at a time). This also means that the implementation can be started early on in the migration roadmap.
Being in control is one of the most essential characteristic of the Finance environment. The elements that ensure that Finance is in control are collectively called the ‘control model’. It details all the technical and functional controls that allow for a full reconciliation from source to balance in the General Ledger (or even in the Group Consolidation).
The shift in architecture from accounting data towards an event based approach also requires a shift in the design of the control model. Preparations for a new control model should start well in advance and be an integral part of the design of the new Financial Accounting Architecture.
The new control model is to be based on the principle of two separate flows: one consist of accounting events and the other of ‘inventories’ (i.e. aggregated control totals that can be matched with entries in the GL). The inventories are translated into accounting data with the same centralized rules but they are based on different but fully related data sets. The accounting events should over time add up to the accounting inventory. In fact, over a chosen comparison period (e.g. quarterly) these should be fully equal. One could say that the sum of the events explains the inventory as the sum of the journals explains the balance of the account.
The steps in the model look schematically as follows:
Each number is a technical or functional control step. Technically meaning that data is automatically compared without user interference (except when errors are found). The functional control allows the user to compare something (e.g. account balances) between one end of the chain and the other in fully functionally understandable terms.
Another important aspect of the control model is the drill down that supports the audit trail. What level of details and aggregation are needed in the drill-down depend on the business / accounting requirements. If necessary the details of this trail can be stored in a DWH.
In the ideal situation all the pieces of functionality that are needed in the control model (reports, inquiries, drill-downs, etc) are made to be an integral part of the solution so that the control model can be supported hands-on by the appropriate applications such as the GL and the ARE and not by some additional process on the side.
Master data and process management
One of the main reasons of implementing a centralised accounting engine is to have each of the source systems comply to accounting rules that are governed on the corporate level. This means that the corporate accounting principles are applied, but also that the corporate financial master data is used (accounts, cost centres, product-codes, etc). Managing the shared master data is therefore just as important as managing the shared accounting rules.
The transition to an event based approach to accounting has also impact here: instead of the source system deciding, based on instructions from Finance, what cost centre (for example) to use in the GL accounting entry, it now only delivers (in the example) the internal customer ID of the internal revenue event from which the cost center for the GL accounting entry may be derived in the accounting rules engine based on rules set up and maintained by Finance.
This means that Finance does no longer push the changes from financial master data to the source systems, but in stead has to receive changes to the local master data that impact the accounting rules (and mappings). This should be fully incorporated in the operational processes of the source. When introducing a new product, for example, do not only create a new pricing model, but also let Finance determine the correct accounting. Or, when a reorganisation is effectuated, make sure that the internal customer ID’s are redirected by Finance to the correct new cost centres.
In addition, the process of data delivery and creating accounting in the accounting rules engine will become very similar for each of the source systems. This means that procedural elements such as communication of period closing and process controls such as the checks on completeness of data delivery are shared across the source systems.
The various information flows between source systems are presented in the picture below:
Note: the reconciliation data was treated as part of the control model.
In the ideal situation all of these flows are fully automated, but in reality it will be more cost effective to leave some to be done procedurally. Factors such as data volume, frequency and complexity may help to decide which flow to automate and which to do manually. At the very least, the flow of transactional data should be automated.
Supporting data warehouse
In the target architecture for accounting, the main purpose of the accounting rules engine is to perform as an engine. Its job is to translate the individual events within the set time frame to accounting entries that can be posted in the GL. But, as seen from the GL, it is also a subledger for a particular financial process. In some case, this may lead to reporting requirements that cannot easily be met by the (smoothly running) accounting rules engine and the (thin) GL. In those cases it is worthwhile to investigate the benefits of an additional supporting data warehouse.
Such a data warehouse will be fed primarily by the accounting entries posted in each of the subledgers of the GL, which for the accounting rules engine sub ledgers means the accounting entries created for the business events, but it may be enriched by data coming directly from the source systems or from other places.
The data in the supporting data warehouse can then be used to fulfil all sorts of (operational/management) reporting requirements, while keeping the GL thin for financial reporting and the accounting rules engine optimised to run as an engine.
In this blog post we have focussed on additional topics that need to be covered in the implementation of a centralised accounting rules engine such as the Oracle Financial Accounting Hub in order to successfully embed it within the Finance organisation. We hope to have made clear that as the benefits of such a solution are not particularly IT-related, but are in the domain of control and process efficiency, actually obtaining these benefits requires a broader perspective than just IT. FAH should not become a “toy” for IT, but should be the centrepiece in a more elaborate transformation towards a modern, future-proof Financial Accounting Architecture.