The reconciliation and settlement of a company’s intercompany trading balances is a challenge that grows exponentially with the number of subsidiaries. While it’s possible to manage a small number of subsidiaries manually, using spreadsheet-based tools or workarounds, there is a tipping point in the growth of each organization that requires a more robust solution.
Large multi-subsidiary organizations need either daily or monthly reconciliation and settlement of intercompany balances to satisfy requirements that encompass:
Large companies also require a robust solution that is scalable and secure, as well as predictable and affordable. Such a solution isn’t available from any of the major ERP or finance software providers, nor is it even in their development program. So an alternative solution is required.
This document summarizes Wipro Consulting Services’ point of view on a Target Operating Model and roadmap for large global organizations to create a robust solution for the reconciliation and settlement of intercompany transactions.
Target Operating Model
The Target Operating Model (TOM) is comprised of four integrated components: business processes, organization roles and responsibilities, enabling technology, and data and reporting requirements. They are described below:
Business Processes
There are two options to consider for the end-to-end process, depending on whether settlement is monthly or daily. These are shown in Figures 1 and 2.
Option 1: Monthly settlement of balances
In a monthly scenario, the transactions are reviewed and reconciled as part of the month-end close prior to settlement, then reported for group accounts. This approach is better suited to smaller groups with lower volumes of intercompany transactions and data inconsistency.
Option 2: Daily settlement of balances
In a daily scenario, the transactions are settled daily and reviewed and reconciled throughout the month. This approach avoids a peak in the month-end close cycle, streamlining the reporting for group accounts. This approach is better suited to larger groups with higher volumes of intercompany transactions and data inconsistency.
Figure 1: Monthly Settlement of Balances
Figure 2: Daily Settlement of Balances
Intercompany Trading:This is ‘business as usual’ trading between subsidiaries using standard P2P and O2C processes but specific intercompany accounts, with liabilities recorded in Accounts Payable or debts being recorded in Accounts Receivable.
Pain Point: All data must be correct at the time of entry to enable zero-touch/no rework at the reconciliation and settlement process. This includes standard intercompany vendor/client IDs, currency rates, payment, and trading terms. Failure to establish data standards and trading terms before processing will result in an expansion of the teams required to resolve exceptions.
Extract Intercompany Transactions: Transactions are extracted from the subsidiary ledgers and posted to the solution.
Pain Point: It is unlikely that one method of sharing transactions will suit all subsidiaries due to size, volume, local regulations, and the like. Consequently, we recommend three different methods to create options that should reduce resistance to adoption:
Settlement Processing: The solution generates settlement transactions, which are payments from the customer to vendor, when the due date is reached for both trading partners. These payments will result in realized currency gains and losses which should be accounted for (separately from any intercompany profit) in the accounts of each subsidiary. The duration between the date of the original transaction and subsequent settlement provides a window for currency forecasting and hedging.
Reconciliation: Transactions in the solution are balanced and reconciled monthly using automated routines that report exceptions only. These intercompany balances should also be reconciled to the Group Reporting values at the end of each month.
Pain Point: Automated reconciliation is required to enable a scalable solution so that transaction volume increases avoid a linear relationship with support team size.
Dispute Management: Disputes can be raised manually by trading partners and manual transactions can be applied to resolve disputes. Since this is a manual process that consumes skilled resources, it should be used sparingly.
Reporting: Intercompany balances for group consolidation can be loaded into reporting systems or reconciled with subsidiary ledger balances prior to consolidation. Exception and data integrity reports should also be available to enable rapid resolution of any discrepancies.
Additional setup and governance steps are required to:
Organization Roles and Responsibilities
For the Target Operating Model to work effectively, there must be strong governance and a clear understanding of the roles and responsibilities held by those who set and direct strategy, those who establish the processes, and those who actually run and support the system, as well as their relationships with one another, as shown in Figure 3.
Governance Board: This organization has global responsibility for the strategic fit and direction, policy, compliance, and change control, as well as management of the governance framework.
Global Process Owner: The Owner controls process refinement, roll-out, data compliance, dispute resolution reviewed and reconciled throughout the month. This approach avoids a peak in the month-end close cycle, streamlining the reporting for group accounts. This approach is better suited to larger groups with higher volumes of intercompany transactions and data inconsistency.
Figure 3: Organization Roles and Responsibilities
manages the change board, leads issue resolution, SLA exception resolution, and financial close compliance.
IT Application Owner: The IT Application Owner ensures smooth running of the system, ownership of the Support Model, upgrades and improvement execution, issue resolution and testing, maintenance of SLAs, and reporting performance to other teams
Finance Processing: The responsibilities include initiating intercompany transactions, compliance, reference data setup, assisting with issue resolution, and testing by shared ser vice centers, accounting units, and subsidiaries.
IT Support Team: IT Support Team’s responsibilities include issue tracking and resolution, performance monitoring, system tuning, integration, and interface management. This element of the organization could be delivered as an offshored managed service.
Other IT Support: This can include providing assistance with issue resolution, upgrades, and testing.
Pain Point: Transaction values are expected to be very high and there can be realized gains or losses even with intercompany transactions (for example, missed hedging settlement dates). It is also likely that this application will feed directly into group reporting. Consequently, the entire support network must agree to the priority given to issue resolution and blackout dates for changes.
Enabling Technology
There are two basic assumptions that must be acknowledged. The first, as we stated previously, is that no off-the-shelf application can satisfy a multi-national company’s unique process, organization, and information requirements, so a custom solution is required. The second is that because reconciliation and settlement is a basic accounting function, performed by all multi-nationals, the objective is to have accurate, efficient processing at low cost with no product or strategically sensitive information being shared. With these as givens, technology must be developed that effectively, economically, and discretely fulfills specific business requirements.
At a high level, there are two key non-technology questions to be decided that will require technology solutions:
1. How will the solution be delivered?
2. How do we accommodate the multiple subsidiary systems and data formats?
The delivery options that follow will help determine the highlevel design and the full-life cost of the solution:
The approach for normalizing subsidiary data and extraction to avoid secondary processing includes the following, which will help determine the implementation and support costs of the solution:
1. The technology selected for this solution (Java, HANA, Oracle, etc.) does not need to match the current or future corporate IT strategy, but does need to match the capabilities of the subsidiaries within each organization.
2. Subsidiaries may use alternate ERP systems or previous releases of ‘core’ systems. The solution should be able to overcome the need for widespread system and data rationalization but should support that change, if selected.
Pain Point: It is unlikely that a single method of sharing transactions will suit all subsidiaries due to development plans, system and data constraints, and the like. Consequently, three different methods are recommended to create options that should reduce resistance to adoption:
1. Manual entry directly into the application
2. Semi-automatic transaction extract and posting to a mailbox
3. Fully automated extract and data load with controls and exception reporting
3. Intercompany vendor and customer IDs may also be different among subsidiaries, which may require either:
a. A prerequisite Master Data Management project to establish and maintain standard intercompany vendor IDs in all subsidiaries or
b. Include mapping tables to be maintained in each subsidiary.
Regardless of the above variables, because the solution requires global access, we believe a resilient web or cloud-based solution would be most appropriate. Such a solution would require three layers:
Application Layer: Including security, user profiles, transaction processing and controls, reporting, and so forth
Web Layer: Including GUI, security, communications, interface processing, and controls
Database Layer: Including data management, data integrity and other controls, as well as reporting
Data and Reporting Requirements
Because the data integrity and accurate reporting are at the crux of reconciliation and settlement, and because they are the primary drivers for the business process and technology design, as well as organization roles and responsibilities, information requirements should be established at the start of the design stage and reviewed throughout the implementation.
The data requirements include:
Pain Point: Failure to involve all information providers and users and failure to agree on requirements in the design stages will result in expensive rework and reimplementation at a later date.
Roadmap
The Target Operating Model is your basic schematic for your solution. But how do you implement it for your organization? A program of this magnitude will require the involvement of multiple stakeholders and changes to business processes and roles. To launch your solution effectively, you need a roadmap that details key steps and the people and teams involved.
Before considering the Target Operating Model, a small senior team should be convened to identify the fundamental shape of the proposed program. It should address:
With these basics established, you then need to dig deeper and make several strategic decisions before the program roadmap can be defined in detail. These decisions include:
Internal or Hosted Solution:The solution is going to operate in a similar way to UK BACS, processing payments between corporate entities. Would you want a similar solution for managing your organization’s intercompany payments? What is your organization’s risk response for outsourcing payment processes, especially to processes that will transact billions annually?
Internal or Outsourced Development: Do you have a development team with scope in the near future to develop a solution? Do you have the organizational capacity to lead and staff a project of this magnitude?
Availability of Existing Functionality: Some components required for the reconciliation and settlement of intercompany transactions may already be available in the organization, such as auto-reconciliation tools like Chesapeake and Blackline or Treasury and payment applications. These assets can be utilized to perform specific functions and can be integrated into an overall solution.
Once these major decisions have been made, your senior team should appoint a program management team to define the program as shown in the roadmap below.
Pain Point: There will be a step change in knowledge, skills and experience required when the program moves from Identifying to Defining. It is a common error for inexperienced program teams to underestimate the resource requirements as well as the level of detail required in the Target Operating Model and in the project plan. Failure to address the full project lifecycle and prepare a detailed vision of the future will result in unexpected over-runs, cost increases and solution gaps.
One option is to hire a Solution Integrator with experience of both the business process and largescale development and business change programs.
Figure 4: Roadmap
At a high level, a combination of program and software development lifecycle management should be applied and follow the roadmap shown in the Figure 4.
Conclusion
While accounting for intercompany reconciliation and settlement is not complex, establishing a solution that is accurate, costeffective, and manageable across a number of subsidiaries has proven to be a common problem faced by large multi-nationals. By adopting this Target Operating Model, organizations now have a basis on which to develop a custom solution that addresses all their pain points. Fortunately, the lack of complexity in this type of accounting simplifies communications and later adoption. And, since several components of the solution may already be used within your organization, it could reduce the potential cost of a solution and may also help drive its design.
With a model in hand, you’ll be better prepared to develop the basics of your vision for a solution and the roadmap to implementing it. Remember, your key decisions that will determine the cost, scope and duration of the program include whether you want to own the solution or have someone else host it, and whether you want in-house or outsourced support for the solution.
At a time when your organization is wrestling with a host of business issues around product or service development and sales, managing costs, and optimizing profits, the last thing you need to be distracted by is intercompany reconciliation and settlement. This should be a part of the business that is humming along smoothly. With that key issue resolved, you’l contribute to the success of a more competitive business.
Get in touch: global.consulting@wipro.com.
