Consolidation Software (#132)
/In this podcast episode, we cover the basic requirements for consolidation software. Key points made are noted below.
When the request came in, I sent it along to a partner at a really large accounting firm, and she passed me along to a director who specializes in consolidation software. This seemed like a good thing. He wrote up some notes for the podcast, but then he had to have it reviewed by their legal department. And their attorneys said, no, he could not be involved. So, he passed along the notes, on the condition that I can’t say his name or the name of the accounting firm. Which was very nice of him, but just incredible that they don’t want their name involved. This podcast goes out to multiple thousands of listeners, so if this isn’t good marketing, I don’t know what is.
Consolidation Software Functional Requirements
So, let’s get on with the topic. The question was, what to look for in consolidation software. Our unnamed director listed the functional and technical requirements separately. Here we go with the functional requirements:
First, currency translation using multiple exchange rates. For example, you need the average monthly rate for the income statement, month-end rates for balance sheets, historical rates for selected investments, and management rates for budgeting purposes.
Next, we have intercompany reconciliation and elimination. This is where the intercompany balances and differences can be tracked by entity for quick resolution.
Next, alternate hierarchies. The system can provide data for multiple hierarchies, which can include statutory, management, and tax-related hierarchies.
Next, regulatory initiatives. The software should be able to do XBRL reporting for the SEC. And by the way, we talked by XBRL in Episode 108. This also means helping to do dual reporting for both the GAAP and IFRS frameworks.
Next, requirements for multiple accounting standards. This means maintaining data for local reporting purposes, and then modifying the data for the accounting standards used by the parent company.
Next, audit trail and adjusting entries. The system should provide detailed audit trails for all of the data collected, and it should generate automated adjusting entries.
Next, data categories. The system should be able to store multiple data categories, such as actuals, the budget, budget variances, and all of that.
And the last functional item is, reporting. This means a web-based drag and drop report creation system. You should also be able to set up a reporting calendar, which the system uses to create and automatically distribute reports. The system should also generate reports in PDF format.
Consolidation Software Technical Requirements
So that was the functional requirements. Next up, we have technical requirements.
First, workflow and task lists. There should be task lists for critical activities. I’ll just read this next part off his list. It says, if possible, there should be an ability to track activities that are scheduled to be completed outside of the consolidation system. For example, reconciliation of subsidiary ledgers is a critical closing activity that could be included in the task list and managed through the work flow process. Some tools offer the capability of entity-based certification from local controllers.
Next, we have the user interface. There should be a user-friendly front end for the collection and validation of data. And he notes that most consolidation packages offer interaction with an Excel front end.
Next up is data validation. There should be user-defined field validations at the point of data entry. This can be things like debits always equal credits, and net income on the income statement equals the current year profit or loss listed on the balance sheet.
Next is rule development. He’s listed this as being a self-service function, and I’m guessing this means you can develop your own macros in the system to automate some tasks.
Next is security. There should be security by module, which keeps users from getting access to data that they don’t need. This can also mean that you can read information in certain areas, but you can’t change the data.
Next is drill down capability. You should be able to drill down to the source data from the consolidation level.
Next is the allocation engine. There should be an easy-to-use allocation engine, which is used for allocating expenses across business units, regions, and so forth.
Also, there should be integration with spreadsheets. There should be quote unquote, “dynamic integration” of spreadsheets with the consolidation database.
And finally, there is system maintenance. You should be able to do system maintenance without having to log users out of the system.