Multi-Entity & Intercompany Consolidation: 7 spreadsheet hazards, one system
One tab per entity, intercompany markups and transfer pricing computed by hand, FX revaluations across subsidiaries, chart-of-accounts segments mapped after each acquisition, intercompany charges matched manually, statutory statements consolidated from local files, and CTA on equity recomputed each period. This blueprint resolves entities and accounts once and posts eliminations and translations deterministically.
Built for: Group controllers and consolidation teams with three or more entities.
Edit this selection in the directoryEntity Resolution & Intercompany Consolidation Platform
7 spreadsheet hazards consolidate into 9 software modules, 2 source integrations, and 14 deterministic controls.
What the selected hazards have in common
Every component below traces to at least one selected hazard. No timelines or savings figures are estimated; measurable outcomes require your baseline data.
The same vendors, customers, or legal entities exist as unlinked records across departmental sheets.
Entity Resolution & Master Data Service resolves 5 of 7 selected hazards and should be built first after source systems are connected.
One spreadsheet pipeline, several failure points
The selected hazards are placed on the stage of the manual workflow where they do their damage. Sources on the left arrive as exports today.
- ERP / General LedgerTrial balance and subledger CSV exports
- FX Rate ProviderRates copied from websites into the workbook
Entity Resolution & Intercompany Consolidation Platform
A single system replaces the workbook. Shared modules are deduplicated across hazards; each card shows how many of the selected hazards it resolves.
What each component does, and what it needs
Modules are reusable across hazards. Inputs, outputs, enforced controls, and the point where a person still decides are listed for each.
Pulls transactions, balances, and master records directly from source-system APIs and file feeds, replacing every manual export.
- Scheduled and webhook-driven API pulls
- Idempotent loads keyed on source record IDs
- Schema validation on every payload
- Read credentials for each source system
- Field mapping per source
- Normalized transaction and master-data tables with source lineage
- Rate assertion: every translated balance must reference a stored rate record whose date and type (closing, average, historical) match the account's policy class, or the revaluation does not post.
- Rate freshness: a revaluation run halts when any currency lacks a rate for the period-end date.
- Equity assertion: the consolidated translation adjustment must equal the sum of per-entity adjustments computed from stored historical and closing rates, and consolidation cannot finalize while the equity section is out of balance.
- Component integrity: an equity component without a stored historical rate blocks the translation run for its entity.
Maintains one canonical record per vendor, customer, legal entity, or contract and resolves aliases, subsidiaries, and duplicates deterministically.
- Tax ID, bank-account, and legal-name uniqueness checks
- Alias and parent-entity resolution rules
- Golden-record propagation back to ERP, procurement, and billing
- Vendor, customer, and entity masters from each system
- Contract and registration documents
- Canonical entity IDs referenced by every downstream module
- Intercompany zero-sum assertion: eliminating entries must balance to zero before group balance sheet generates.
- Entity onboarding: adding a subsidiary registers it in the entity graph without touching any formula.
- Elimination assertion: every intercompany receivable must have an equal and opposite payable at the counterparty entity before consolidation runs.
- Policy-driven markups: intercompany percentages come from one policy table, never a per-entity cell.
- Mapping assertion: every active subsidiary account must resolve to exactly one group account and segment set before its balance enters consolidation, or the run stops with the unmapped list.
- Mapping change control: remapping an account requires approval and preserves the prior mapping for restatement.
- Bilateral assertion: every intercompany transaction must have matched entries in both entities at the agreed rate and amount before the period closes, and unmatched items block consolidation with the counterparty listed.
- Rate agreement: both sides of a transaction use the hub's stored rate for the transaction date, never an entity-local lookup.
Matches records across two or more systems on amount, date window, and reference and isolates everything that does not match.
- Two-, three-, and multi-way matching
- Configurable tolerance and date windows
- Partial and many-to-one match handling
- Normalized transactions from each side of the match
- Canonical entity IDs
- Matched sets, unmatched items, and variance explanations
Evaluates deterministic control rules on every record before it can proceed, so a failed assertion blocks the transaction instead of a person catching it later.
- Versioned rule definitions with effective dates
- Balance, threshold, and completeness assertions
- Pass/fail evidence stored per record
- Normalized records
- Policy thresholds and limits
- Assertion results attached to each record
- Reconciliation assertion: local GAAP equity must equal group GAAP equity plus posted adjustment entries for every entity and period, and a statutory pack can only generate when that reconciliation holds.
- Filing calendar: each entity's statutory deadline drives a readiness check that lists open reconciling items.
Routes every failed assertion or unmatched item to an owner with the evidence attached, and tracks it to resolution.
- Owner assignment by rule and department
- Aging and escalation timers
- Resolution codes with required evidence
- Assertion failures and unmatched items
- Resolved exceptions with disposition and approver
Enforces role-based, limit-based approvals inside the system so that decisions are recorded where the transaction lives, not in email or chat.
- Role and limit matrices
- Dual control for high-value or high-risk actions
- Signed, time-stamped approval records
- Approval policy and authorized roles
- Transactions requiring release
- Approved or rejected actions with approver identity
Posts balanced, validated entries to the ERP through its API so nothing is retyped and every entry carries its source lineage.
- Balanced double-entry generation
- Idempotent posting with duplicate suppression
- Subledger-to-GL tie-out on every batch
- Assertion-passed records
- Chart of accounts and mapping rules
- ERP journal entries with source references
Publishes reports, board metrics, and monitoring dashboards from reconciled data only, with each figure traceable to its ledger snapshot.
- Versioned report snapshots
- Publish only from reconciled, locked data
- Drill-through from figure to source record
- Reconciled ledger and operational data
- Board packs, variance reports, and compliance dashboards
Records every load, rule evaluation, approval, and posting in an append-only log so auditors can trace any figure to who did what and when.
- Append-only event history
- Hash-chained records
- Evidence export for external audit
- Events from every other module
- Audit-ready evidence trail
Traceability from hazard to automated control
Each selected hazard maps to the module that resolves it, the deterministic rule that replaces the manual check, and the result once the rule is enforced.
| Hazard | Software module | Automated control | Result |
|---|---|---|---|
#08One tab per entity | Entity Resolution & Master Data Service | Intercompany zero-sum assertion: eliminating entries must balance to zero before group balance sheet generates. Entity onboarding: adding a subsidiary registers it in the entity graph without touching any formula. | Consolidation and eliminations run from the entity graph; new entities do not break the rollup. |
#15Intercompany markup & transfer pricing calculated manually | Entity Resolution & Master Data Service | Elimination assertion: every intercompany receivable must have an equal and opposite payable at the counterparty entity before consolidation runs. Policy-driven markups: intercompany percentages come from one policy table, never a per-entity cell. | Paired intercompany entries eliminate to zero before consolidation runs. |
#22Manual FX rate conversion revaluations across 8 foreign subsidiaries | Integration & Ingestion Layer | Rate assertion: every translated balance must reference a stored rate record whose date and type (closing, average, historical) match the account's policy class, or the revaluation does not post. Rate freshness: a revaluation run halts when any currency lacks a rate for the period-end date. | Translation adjustments derive from stored policy rates; the equity section balances on every consolidation run. |
#42Manual chart of accounts segment mapping across acquired companies | Entity Resolution & Master Data Service | Mapping assertion: every active subsidiary account must resolve to exactly one group account and segment set before its balance enters consolidation, or the run stops with the unmapped list. Mapping change control: remapping an account requires approval and preserves the prior mapping for restatement. | Acquired charts resolve to the group chart through a governed graph; consolidation no longer waits on a bridge sheet. |
#77Manual matching of intercompany charges across foreign subsidiaries | Entity Resolution & Master Data Service | Bilateral assertion: every intercompany transaction must have matched entries in both entities at the agreed rate and amount before the period closes, and unmatched items block consolidation with the counterparty listed. Rate agreement: both sides of a transaction use the hub's stored rate for the transaction date, never an entity-local lookup. | Intercompany charges post to both entities from one record; the consolidated close no longer waits on elimination plugs. |
#78Manual consolidation of statutory financial statements for overseas entities | Rules & Assertion Engine | Reconciliation assertion: local GAAP equity must equal group GAAP equity plus posted adjustment entries for every entity and period, and a statutory pack can only generate when that reconciliation holds. Filing calendar: each entity's statutory deadline drives a readiness check that lists open reconciling items. | Statutory packs generate from parallel ledgers with posted adjustments; overseas filings stop running late. |
#94Manual calculation of foreign currency translation adjustments on equity | Integration & Ingestion Layer | Equity assertion: the consolidated translation adjustment must equal the sum of per-entity adjustments computed from stored historical and closing rates, and consolidation cannot finalize while the equity section is out of balance. Component integrity: an equity component without a stored historical rate blocks the translation run for its entity. | Translation adjustments post per entity from stored rates; the equity section balances without a plug. |
Dependency order, not a calendar
Phases follow module dependencies: nothing downstream is built before the data it needs is flowing. Durations depend on your systems and are scoped in the diagnostic.
- 1Connect source systems2 of 7 hazards touched
Replace every manual export with an authenticated API or file feed and load it idempotently.
Integration & Ingestion Layer - 2Normalize and validate records7 of 7 hazards touched
Establish canonical entities and encode the control rules the workbook was enforcing by hand.
Entity Resolution & Master Data ServiceRules & Assertion Engine - 3Reconcile and schedule1 of 7 hazards touched
Run matching and period schedules from source data so variances surface as exceptions, not surprises.
Reconciliation & Matching Engine - 4Route exceptions and approvals2 of 7 hazards touched
Move every review and sign-off out of email and chat into owned queues with recorded decisions.
Exception Management QueueApproval Workflow - 5Automate posting7 of 7 hazards touched
Post balanced, validated entries to the ERP through its API with source lineage on every line.
Automated Ledger Posting - 6Publish governed reporting and the audit trail1 of 7 hazards touched
Release reports only from reconciled snapshots and hand auditors an append-only evidence log.
Governed Reporting LayerImmutable Audit Log
Human approval points the system preserves
Deterministic software removes re-keying and eyeballing. It does not remove judgment; these are the decisions that stay with your team.
- Integration & Ingestion Layer: Approving new source connections and field mappings.
- Entity Resolution & Master Data Service: Confirming proposed merges when two records match on some but not all identifiers.
- Reconciliation & Matching Engine: Clearing unmatched items that fall outside tolerance.
- Rules & Assertion Engine: Changing a rule or threshold requires a documented approval.
- Exception Management Queue: Every exception is dispositioned by a named owner; the system never auto-clears one.
- Approval Workflow: Approvers act on the request; the workflow only enforces who and how many.
- Automated Ledger Posting: Period lock and close sign-off remain manual approvals.
- Governed Reporting Layer: Report release still requires reviewer sign-off; the layer prevents unreconciled figures from being publishable.
- Immutable Audit Log: Auditors and controllers read the log; no one edits it.
Scope this blueprint
Leave a work email and we send you this exact blueprint (7 hazards, 9 modules) as a link you can reopen and print. The same link reaches our team, who reply with the two or three questions that turn Entity Resolution & Intercompany Consolidation Platform into a scope for your books.
- No estimate is invented. Effort and payback come after we see your volumes and source systems.
- One email, then a person. No drip sequence.
- Prefer to keep it internal? Print / Save PDF above needs no email.
