Technology
Consolidation breaks in close. Design it before you build the ERP.
Multi-entity organizations that map intercompany flows, elimination logic, and reconciliation workflows before ERP configuration reduce close cycles by 2–4 days and eliminate 70–85% of post-close rework. Here's what that design looks like.
Intercompany accounting in ERP succeeds when you design the elimination process, reconciliation logic, and consolidation data model explicitly before configuration begins. This means mapping transaction types, chart-of-accounts structures, matching rules, and exception workflows upfront. Organizations that do this reduce their consolidation cycle by 2–4 days and avoid 70–85% of the post-close adjustments that plague implementations where consolidation design is deferred until testing.
What good looks like
| Metric | Minimum | Strong | World-class |
|---|---|---|---|
| Intercompany Transaction Reconciliation TimelinessPercentage of intercompany transactions that are matched, reconciled, and cleared within the standard monthly close window. | 75-85% | 85-95% | 95-99% |
| Intercompany Elimination Accuracy RatePercentage of consolidated financial statements where all intercompany transactions and balances are correctly eliminated without material restatement or adjustment in subsequent periods. | 80-88% | 88-96% | 96-99% |
| Days to Close Intercompany AccountsAverage number of calendar days required to complete all intercompany transaction identification, reconciliation, and elimination entries after month-end. | 8-12 | 5-8 | 2-5 |
| Intercompany Receivables and Payables Outstanding Balance VariancePercentage variance between intercompany receivables reported by the selling entity and intercompany payables reported by the buying entity for the same transaction set. | 5-10% | 2-5% | 0-2% |
The spread between tiers reveals where design discipline matters most. Reconciliation timeliness ranges from 75–85% (minimum) to 95–99% (world-class)—a 20-percentage-point gap driven almost entirely by automation and standardized documentation, both products of upfront design. Elimination accuracy follows a similar 8–11 point range, reflecting whether control logic is embedded in configuration or bolted on manually. Days to close shows the sharpest cliff: world-class teams finish intercompany accounts in 2–5 days while minimum performers take 8–12. That 6–10 day spread is the direct payoff of pre-configured matching and elimination workflows versus manual compilation. Balance variance (0–2% world-class versus 5–10% minimum) indicates whether transaction coding and matching rules were designed into the process or improvised during close.
Industry-Specific Benchmarks
These ranges are cross-industry. The figures differ materially by sector and company size.
Find benchmarks for your industry →What drives the difference
World-class organizations treat consolidation design as a distinct pre-configuration discipline, not a configuration detail. They map intercompany relationships (who pays whom, in what currency, on what terms), define elimination logic for each transaction type before a single GL account is created, and embed reconciliation checkpoints into the close calendar. When a subsidiary invoices a parent for management fees, the transaction flows into a pre-designed GL structure with built-in intercompany tags, automatic matching logic, and elimination entries that run without human intervention. Minimum performers discover these requirements during UAT or in production, then pursue them through custom journal entries and spreadsheet reconciliation.
The gap is not technical—every ERP can handle intercompany accounting. It is architectural. Organizations that invest in design before configuration decide upfront whether intercompany transactions will post directly to a subsidiary ledger or flow through a central intercompany clearing account; whether matching will be transaction-level or balance-level; whether eliminations will run automatically at close or require supervisory review. These decisions, made early, propagate through every subsequent choice in chart-of-accounts design, dimension hierarchies, and consolidation reporting. Teams that defer them face configuration rework in week 15 of implementation, when it becomes clear the general ledger structure cannot support the consolidation logic finance actually needs.
Speed improves because pre-designed organizations separate transactional close (entity-level account reconciliation) from consolidation close (intercompany elimination and reporting). Entities close their books in parallel; consolidation happens once all intercompany balances are pre-reconciled and documented. Minimum performers interleave these—entities finish closing, then discovery begins on which intercompany items are in dispute, creating serial close steps and extending the overall cycle. World-class performers complete intercompany reconciliation during the transactional close window, using automated matching and a clear escalation path for exceptions, so consolidation is assembly, not detective work.
Proven approaches
Design intercompany flows as a core ERP structure, not a post-transaction fix
Intercompany accounting in ERP is not about posting journal entries after the fact; it is about designing the general ledger and elimination logic so transactions flow correctly from their point of origin. This practice requires mapping every intercompany transaction type your organization uses—management fee charges, cost allocations, loans, royalties, goods transfers, service billings—and then defining, for each one, how it enters the system, where it lands in the chart of accounts, how it is tagged for consolidation matching, and what elimination rule applies to it at period close. The chart of accounts itself becomes part of the design: subsidiary ledgers are structured by entity and transaction type, intercompany clearing accounts are positioned consistently, and dimension hierarchies (if your ERP uses them) encode the consolidation structure so that reporting queries can separate legal-entity results from consolidated results without manual filtering.
The mechanism is configuration discipline upstream of build. Before your ERP team configures a single cost center or GL account, your finance and consolidation leads should have answered: Where will management fees to the parent post? Which entities can invoice which other entities? Will intercompany invoices match on transaction ID, invoice number, or balance? Who reconciles unmatched items, and what is the escalation path for items that do not clear? Should eliminations run automatically at period close, or should a controller review the elimination deck before posting? These decisions are encoded into the ERP configuration—transaction type definitions, account hierarchies, matching rules, and period-close batch jobs. Once they are live, they operate repeatably without re-inventing them each month. When they are not designed upfront, finance discovers gaps during close and works around them with journal entries, spreadsheet lookups, and manual reconciliation—the very work consolidation software is supposed to eliminate.
The payoff is structural. Organizations that design this way reduce their intercompany close window from 8–12 days (or longer) to 5–8 because they have eliminated manual matching and surprise eliminations. They reduce post-close rework by embedding control logic into configuration—exception resolution happens during the close cycle, not after consolidated reports are produced and auditors ask why an intercompany receivable balance does not match its payable counterpart. Audit findings on intercompany accounting decline because the elimination entries are generated deterministically from configuration, not hand-coded, and the audit trail shows the rule that produced each elimination entry, not just the entry itself.
Leading Practice Report
Full detail: Intercompany Transaction and Consolidation Process Design
The full report covers:
- Expected benefits
- Core principles
- Key success factors
- Key metrics
- Risks and mitigations
- Implementation roadmap
Automate intercompany recording at source, and design consolidation as a separate, controlled process
The second practice addresses where intercompany transactions enter the system. In many organizations, intercompany transactions are created in operational modules (a subsidiary records a sale to an affiliate, a service delivery team logs an internal charge) but then pulled out at period-end, reviewed, and re-recorded in a consolidation module or spreadsheet. This creates a dual-entry problem: the operational transaction exists in one system and must be manually replicated in another. It also creates timing gaps (some periods the operational entry was recorded, other periods it was not, leading to reconciliation variance) and decision points (which intercompany invoices should actually be recorded? which should be eliminated?). Automating this practice means capturing intercompany transactions in the ERP at their point of origin, in operational modules, with the same rigor as external transactions. A subsidiary records a sale to an affiliate in the sales module; the ERP recognizes it as an intercompany transaction (because the customer entity code matches a defined intercompany customer), assigns it intercompany tags automatically, and posts it to the correct subsidiary ledger and intercompany clearing account in one step. The transaction then flows to consolidation reconciliation already in the correct format.
This requires discipline on three fronts. First, intercompany transaction types must be defined and authorized before they flow through operational systems—this is policy work, not just ERP configuration. Can a manufacturing subsidiary invoice a distribution subsidiary for goods transfer? At what price? Can headquarters charge all entities a management fee, and if so, how is it calculated? These rules should be documented and enforced before they become ERP transactions. Second, the ERP must be configured to recognize and tag intercompany transactions at creation—sales orders to intercompany customers must route differently than customer orders; internal service charges must post to specific GL accounts, not operating expense accounts; intercompany loans must be recorded in a dedicated loan sub-ledger. Third, consolidation reconciliation must be a controlled, scheduled activity, not an ad-hoc sprint. Finance designates a reconciliation owner for each intercompany relationship, sets a target date for reconciliation during the close calendar (typically day 3–5 of the close cycle), and routes exceptions to the relevant entities for resolution. Unresolved exceptions are escalated; the closing checklist is not signed until all reconciliations are complete.
The benefit is a consolidation cycle that runs in parallel with transactional close, not after it. Because intercompany transactions flow in from operational modules already tagged and positioned correctly, consolidation reconciliation becomes matching pre-recorded balances and resolving timing differences, not recreating transactions. Consolidation cycle time contracts by 30–50% because reconciliation is not waiting for data to arrive, and eliminations are generated automatically from matched pairs rather than requiring a consolidation specialist to extract balances, load them into a consolidation tool, review the results, and post manual adjustments. Rework drops by 40–60% because the reconciliation process is deterministic: two entities either reconcile on their pre-defined matching key, or they do not, and unmatched items surface immediately instead of being discovered during audit.
Leading Practice Report
Full detail: Intercompany Transaction and Consolidation Process Automation
Benefits, core principles, success factors, metrics, risks and the implementation roadmap.
Get the full report →Getting started
- Map your intercompany relationships: which entities transact with which others, and what types of transactions (goods, services, fees, loans, allocations). Document the policy that governs each type—who can authorize it, at what price, on what terms.
- Identify how intercompany transactions currently flow into your systems. Are they recorded in operational modules at transaction time, or captured in a consolidation tool after-the-fact? Are reconciliations automated or manual?
- Design your elimination logic explicitly: for each intercompany transaction type, what elimination entry (if any) is required at consolidation, and should it run automatically or require supervisory review?
Ask Ask Kepler how to scope a consolidation architecture pre-design for your entity structure and how to sequence it against your ERP go-live timeline.
Start free with Ask Kepler →Where practice is heading
Advanced & Emerging Practices
Emerging practices are included with Ask Kepler Pro and Max.
Unlock these practices →Curious how Ask Kepler Research is produced? Read our research methodology.
Performance Playbook
Intercompany Accounting: The discipline that shrinks intercompany close cycles
Learn how to build automation, pre-close alignment, and centralized policy into intercompany accounting so mismatches resolve without escalation and accounts close in 2–5 days. This playbook shows you the three shifts th
Open the playbook →