By Kars Stal, Kaushik Sarkar, and Marc Atos
Given the plethora of accounting tools with overlapping functionalities, we have been increasingly getting more questions from current and potential Clients on why should they use Oracle Account Reconciliation Cloud Services (ARCS), when their current Enterprise Resource Planning (ERP) systems already have reconciliation and transaction matching capabilities built-in.
While it is true that various ERP modules provide similar functionalities like ARCS, there are often times major and subtle differences which warrants a comparison on a case by case basis. In this article we have compared ARCS against Oracle EBS with AR, AP, GL and Cash Management modules enabled. We limited the scope of discussion to data control and matching capabilities inherent in the two applications, and excluded other important ERP functionalities. We have also not commented on any future enhancements projected in the products’ roadmap.
The overview of the comparison provided below can also be used as a framework to compare any other ERP based reconciliation solution to ARCS, for an informed decision.
Overview of Comparison:
| ARCS (with Transaction Matching) | Oracle EBS (with AR, AP, GL and Cash Management) | |
| 1 | Designed to be a Software as a Service (SAAS) platform; therefore it provides the associated benefits of SAAS like reduced time to market, lower cost of ownership and monthly updates to functionality (versus having to perform software upgrades) | Oracle EBS is an on-premise tool. Oracle does have Cloud Financials as an offering as well, however this is not part of this comparison |
| 2 | Designed to be a purpose built standalone reconciliation and transaction matching tool which can be agnostic to data sources and hence can operate with multiple ERPs and external transaction sources | Designed to be operated within the framework of Oracle EBS modules to maximize the benefits from all the integration features. |
| 3 | Provides the ability to organize reconciliations and reduce process risks through a “Dynamic Risk Rating” method which is applicable to the entire Chart of Accounts | Oracle EBS modules (AR, AP, Cash Management etc.) are designed for specific reconciliations and do not view the organization wide reconciliation process holistically as a function |
| 4 | Provides the ability to enforce control on the ending balances of each Account through a Flux analysis (variance analysis) process | Designed primarily with the intent to book transactions and does not provide any out-of-the-box framework to perform variance analysis or enforce the associated governance / commentary process |
| 5 | Provides a ready framework for implementing the workflow necessary for Accounting Close. Additionally the frequency of reconciliation is customizable; therefore can be used outside of Close cycle | Typically associated with matching and clearing of near real time transactions. Primarily used towards the beginning of Accounting Close process |
| 6 | Provides the ability to “transform” data through Attribute (column) calculation for data enrichment or normalization, to facilitate the matching process | Does not support “transforming” a transaction during reconciliation. Transactions are primarily matched based on the associated transaction details |
| 7 | Provides the ability to build a ready list of suggested matches | Does not provide any analytical suggestions pertaining to matching |
| 8 | Designed primarily to execute and enforce an organization wide governance workflow for reconciliation. By default it does not clear a transaction to invoke an automated accounting entry (although it does have the ability to create a journal and have it flow through the ERP journal posting workflow) | Designed to match and clear transactions to facilitate accounting entries (Note that Payables payment, Receivables receipt, cash management cash flow or open transactions can be matched and cleared. However Payroll payments or GL Journal Entries can be matched but not cleared) |
| 9 | Lacks the ability to perform foreign currency translation inside the application, by design. Ideally currency translation should be performed outside ARCS and imported into ARCS | Designed to reconcile foreign currency transactions to the ledger currency |
Conclusion
The features and differences mentioned above indicates that the reconciliation and transaction matching capabilities of the ERP vis-à-vis ARCS supplements each other, and both can coexist in the enterprise financial data flow. Notably, ARCS becomes especially relevant in certain situations when:
a) Companies want to streamline the enterprise wide financial reconciliation process holistically, across ERP, Payroll, Treasury, Tax and other accounting transaction systems
b) Multiple ERPS exist due to Mergers and Acquisitions (M&A)
c) Companies want to re-engineer the financial accounting close processes
ARCS is not designed to substitute the inherent capabilities of an ERP module to clear and auto-post accounting entries or perform currency translations. However, it is an important tool to utilize, if a Company wants to refocus their workforce’s attention from collecting and matching data from disparate sources, to other activities.
Account Reconciliation Transformation 