Skip to main content

Intercompany — Transactions Between Group Entities in ERP

Intercompany (IC) refers to business transactions between legal entities that belong to the same corporate group — a manufacturing subsidiary selling to a distribution subsidiary, a parent charging management fees, an entity lending cash to a sister company. Each entity keeps its own books, so every IC transaction must be recorded twice, priced defensibly for tax purposes, reconciled between both sides, and eliminated when the group prepares consolidated financial statements. In multi-entity ERP systems, intercompany capability is one of the features that separates genuine multi-company platforms from single-company systems run in parallel.

Typical intercompany transactions

US mid-market groups usually see five recurring categories: goods (one entity manufactures, another sells — the largest volume driver), services (shared services such as IT, HR, or accounting billed across entities), cost allocations (insurance, software licenses, corporate overhead distributed by keys), financing (intercompany loans, interest, cash pooling), and royalties or IP charges for brands and technology owned centrally. Each category has its own pricing logic and its own reconciliation profile, which is why blanket IC processes rarely work.

The mirrored document flow: IC orders and invoices

The core mechanism in a multi-entity ERP is document mirroring. An intercompany sales order in the selling entity automatically generates the matching purchase order in the buying entity; the goods issue on one side creates the goods receipt on the other; the IC accounts-receivable invoice posts simultaneously as the accounts-payable invoice at the counterparty. Done well, one business event produces consistent, referenced documents in both sets of books. Done poorly — with manual re-keying or spreadsheet handoffs — the two sides drift apart in amounts, dates, and currencies, and the month-end close inherits the cleanup. Most intercompany pain traced back in audits is not an accounting problem but a process problem: two entries that were never structurally linked.

Transfer pricing

Prices between group entities must satisfy the arm's-length standard: the price unrelated parties would have agreed. For US federal tax, Section 482 of the Internal Revenue Code gives the IRS authority to reallocate income between related entities when pricing does not hold up, and contemporaneous documentation is the standard defense. Cross-border groups additionally face OECD-aligned rules in the counterparty jurisdictions. In the ERP, transfer pricing translates into entity-pair price lists, cost-plus markup rules, and periodic true-up postings when actual costs deviate from plan. What matters for buyers is less the tax engine itself than traceability: every IC price should be derivable from a maintained rule, not from an analyst's spreadsheet (see audit trail).

Reconciliation and elimination

Before consolidation, both sides must agree: entity A's IC receivable against entity B must equal entity B's IC payable against entity A, per counterparty and ideally per transaction. Timing differences (invoice posted in one entity, not yet received in the other), currency translation, and in-transit inventory are the classic mismatch sources. Modern ERP and close-management tools provide IC matching engines that pair open items automatically within tolerance rules and route exceptions to owners. What survives matching is netted and settled — many groups pay IC balances monthly through a netting run instead of individual transfers. At group level, IC revenue, cost, balances, and unrealized profit in inventory are then removed through elimination entries — the mechanical core of consolidation.

Automation levels

In practice, three maturity stages describe most US mid-market groups. Stage one: IC transactions are posted manually in each entity and reconciled in spreadsheets at close — workable up to perhaps three entities, painful beyond. Stage two: the ERP mirrors documents automatically within one multi-entity database; reconciliation shrinks to exceptions. Stage three: touchless IC — rules generate, price, post, match, and settle recurring transactions with human review only for exceptions. Groups running different ERP systems in subsidiaries and headquarters (see two-tier ERP) can still reach stage two and three, but only with disciplined integration and shared master data for entities, accounts, and counterparties (see master data management).

Selection criteria for US buyers

  • Native multi-entity architecture: confirm the system manages multiple legal entities in one environment with cross-entity document flows — not separate instances stitched together by imports.
  • Automatic document mirroring: IC sales order to purchase order, shipment to receipt, AR invoice to AP invoice, each with hard references. Ask for a live demonstration across two entities, including a cancellation.
  • IC matching with tolerance rules: line-level matching, aging of unmatched items, and exception workflows. Month-end IC reconciliation effort is one of the most honest reference-call questions you can ask.
  • Transfer-price rule support: entity-pair price lists, cost-plus rules, and a change history that stands up in a tax audit.
  • Multi-currency handling: IC transactions in different functional currencies, with consistent rates on both sides of each document.
  • Consolidation hand-off: either built-in elimination logic or clean, counterparty-tagged exports to a dedicated consolidation tool.

Comparable terms

Intercompany processing is the transactional layer beneath consolidation, which aggregates and eliminates at group level. Two-tier ERP describes the architecture question of which system each entity runs — a decision that directly shapes how much IC automation is achievable. Framework differences between group and local books are covered under US GAAP vs. IFRS.

Related Topics