I was recently talking with a Record to Report (R2R) thought-leader at a $30B food and beverage retailer and they were in the process of reviewing their R2R organizational structure. Their global team included the expected responsibilities of Account Reconciliation, Disclosure Management and Statutory Reporting but it was great to see that they had expanded their scope of conversations to include Payroll, Tax, Treasury and a few other key areas. I asked him why these were included to which he responded in a two-part answer:
- Each of these areas are involved in a core system of controls for Account Reconciliations
- Each of these areas performed financial controls utilizing their dedicated systems of record (Tax, Treasury, Payroll, etc.) which are primarily resident in their main ERP
As you could imagine, despite the brokenness of the underlying systems, they wanted full visibility of the global Record to Report (R2R) process so they could ensure the accuracy and reliability of their financial reporting.
Now, to understand what would happen in the above, let me take us down a slightly more technical tangent where I address the idea of an API, which is critical to creating that completeness in the R2R process. An API stands for Application Programming Interface and it enables different applications to communicate with each other in a standardized format. If that is not helpful, maybe an example might be better. Let’s say you develop Tax Software to do tax returns and want to submit them to the Internal Revenue System (IRS) or some other government organization on behalf of your customers and also get communication back from them. To simplify this, the IRS creates a standard way you can talk to their computers. This standard includes how to start a conversation, how to identify the tax payer, how to send the tax information in, how to get a confirmation, etc. This standard way would be published to all Tax Software developers and used by them (and you, in this example) to communicate to the IRS from your software and is an example of an API.
Trintech’s Record to Report solution, Cadency®, has APIs that allow customers to link their unique Payroll, Tax, Treasury, etc. systems of record to their financial system of controls.
The most recent API in Cadency enables the Close workflow to communicate bi-directionally. This is the highway which enables you to link your systems of record (ERP or non-ERP – Tax, Treasury, P-Card, etc.) to the Cadency Close Action Plans. As such, Cadency can document all of your controls in the close workflow, without making you change your utilization of your existing systems. The Cadency Close Action Plan Router (APR) then enables you to link your financial controls from these activities and automatically update your system of controls as they occur. This then provides you the visibility needed to know that all the controls activities needed for an accurate financial close and reporting cycle are done without requiring extra human interaction. It also leverages your investment into these other systems of record and does not disrupt those processes.
For example, if your intercompany and treasury controls are linked, you can ensure that once the intercompany controls in Cadency are completed, automation can trigger a Treasury report to run on your Treasury system which is then pulled back into Cadency (using the bi-directional API) as another close task and updated as completed. This ensures these controls are linked and automated in every scenario possible.
Going back to my initial discussion with one of our customers – He is currently leveraging Trintech’s APIs to link their controls from some of the systems which impact their controls and expanding it to touch all of their systems. This way, they will know that when their Close Controls in Cadency are completed, each system of record is “closed” and “ready to report”. Conversely, when something is not completed, they now have a quick and easy way to discuss which controls are affected and the impact it will have on their financial statement integrity in real-time.
Trintech is actively enhancing our API roadmap, and we’ll be adding the ability to source the Account Reconciliation data and add:
- Supporting documents to reconciliations
- Validating “certified” accounts from other systems of reporting such as disclosure reporting or statutory reporting
- Compliance APIs to link other systems of controls and/or RPA systems into your compliance framework
- Data APIs to enable you to use your in-house BI systems with your controls data
Read on to discover Trintech’s Record to Report Automation Framework Pillar 3 – 3rd Party RPA Connectors.
Written by: Michael Ross, Chief Product Officer at Trintech
Explore the Full 8-Part Series on Trintech’s Record to Report Automation Framework
Part 1 – How a System of Controls Can Move Your Financial Reporting from Flipping a Coin to a Sure Investment
Part 2 – How to Improve Controls, Reduce Risk and Lower Costs with a Record to Report Automation Framework
Part 3 – R2R Automation Framework: ERP Connectors
Part 5 – R2R Automation Framework: 3rd Party RPA Connectors
Part 6 – R2R Automation Framework: ERP Bots
Part 7 – R2R Automation Framework: Risk Intelligent RPA
Part 8 – R2R Automation Framework: Artificial Intelligence