A successful multi-entity (ME) ERP project can migrate all subsidiaries successfully yet fail on the first consolidated close. Usually the problem begins before any data is even entered. No one thought about how the individual ledgers are going to be combined as a single ledger report.
Typically, teams develop their ME implementations by migrating one company at a time. After configuring the parent and migrating the largest subsidiary, they continue to add the remaining companies in the same way. At the end of each migration, the financials appear to be intact on their own.
Then comes the month-end. Financial has to combine these individual company ledgers eliminating any internal processing activity. Now, what appeared to be local financial decisions have now become issues that affect the entire organization.
The first close should be part of the design
There should be some planning done prior to migrating the first entity regarding the first consolidated close. It doesn't mean you need to know every entry before you start moving data; however, it does mean there should be an understanding of how the various processes will interact with each other regarding sequencing, who owns the elimination/reconciliation entries and what the expected output should be.
Start with your final group reporting package. Determine which entities are included in it and when each will need to be closed. Work backwards through your eliminations, reconciliations and entity level tasking.
By having a target other than just getting your transactions loaded into the new ERP system, you give yourself a focus point for your overall implementation.
Chart decisions become consolidation decisions
An entity can have a perfect chart of accounts for itself. However, if you take ten entities and allow them to have ten completely unrelated charts of accounts, you begin to see a different issue. When trying to produce a group report, you no longer have a simple translation of each entity's local account to a common structure.
You can make this type of translation happen, but it has to be deliberate. A shared chart can simplify your group reporting needs, while meeting local reporting needs may require different chart structures. The worst possible scenario is to let your charts drift without establishing a definition for translating each local account to a common structure. All differences between entities will be exposed when performing the first consolidated close.
Intercompany should be identified when it happens
When you try to determine internal transactions within a company at month-end, intercompany accounting becomes very challenging. An example of this could be a management fee that exists in the parent company but not in the subsidiary company. Additionally, one company may record a recharge this month while the other company records the recharge next month.
Your ERP design should capture both counterparties when each respective transaction occurs. This will provide your finance department with something tangible to use for matching purposes before consolidating.
Additionally, capturing counterparties early will help reveal missing entries sooner. If intercompany activity is determined via descriptions or spreadsheet analysis, then determining missing entries becomes investigative versus analytical in nature.
The group needs one close calendar
This would seem to provide flexibility to each company when closing; however, having multiple companies' closings occur at various times creates a timing issue in regards to consolidation. Each company in the group has to be completely finished (closed) prior to beginning consolidation. Thus, a single delayed subsidiary could cause the entire group's closure to remain open.
The close calendar should include all of the company close dates, along with group close dates. Additionally, it should display when intercompany account balances need to be reconciled and when “late” journals stop.
While local teams still require adequate time to complete their own work, the key difference is that their close dates now support one common group close date as opposed to several separate schedules.
Entity sign-off needs a clear meaning
When a person completes a checklist does not necessarily mean that an entity was closed. In fact, the entire group team needs to have confidence in the stability of the trial balance so that the correct numbers are rolled up. Without such assurance, late corrections continue to change numbers after the roll-up begins.
Determine what must be completed by an entity prior to submission. For example, bank accounts must be reconciled; accounts payable (AP) and accounts receivable (AR) must match against their respective control accounts; material accruals must be booked; and intercompany differences must be settled. The actual list will vary, but the definition of sign-off should be consistently applied throughout the group.
Currency rules cannot wait until reporting
A multi-currency organization adds yet another layer of complexity to the initial close. Each entity may maintain accurate records and still create confusion in the consolidated financial statement(s) if translation rules were never defined or agreed upon. Furthermore, changes in exchange rates during the reporting period make the problem even more apparent.
In addition, the implementation should determine the functional currency, reporting currency and source of exchange rate information prior to migration. Further, the implementation should define how different balance types are translated.
This way finance knows exactly what the consolidated financial statements are intended to reflect. Postponement of currency translation until the first close converts an accounting policy decision into an emergency configuration function.
A historical close is a better test than sample transactions
Testing typically demonstrates that individual transactions operate properly. An example would be creating a purchase order, processing an invoice and clearing a payment. These are valid tests; however, these tests alone do not demonstrate that the group can close.
Test using a previously completed history month as a dry-run. Load the necessary balances and execute each entity through the proposed close processes. Once you have executed the consolidation process, compare your result with approved previous group statements.
Any discrepancies identified in this phase can be addressed at this stage since there is still ample opportunity to modify the design prior to relying on it for live reporting purposes.
Where this argument is weak
Not every multi-entity implementation requires extensive design for consolidating financial data. There exists some organizations that consist of only two entities with minimal intercompany activity where no advanced consolidation infrastructure is needed. Implementing enterprise-level controls for such organizations simply generates unnecessary work.
Similarly, for organizations that are operationally distinct from each other and whose only group reporting requirements are basic, a simple mapping and manual elimination of like items may suffice. However, this simplicity needs to be done intentionally.
Organizations with less complex structures benefit from the ease of use when it is representative of their organizational structure as opposed to an unspoken premise that consolidation will take care of itself over time.