Intercompany: The Close-Cycle Bottleneck Mid-Market Finance Teams Don't Own

Updated for 2026. Close-cycle tools now ship agent-assisted matching for intercompany; the discipline still belongs to a named owner, and the control narrative needs the language in our one-page AI governance policy before any agent-cleared elimination is acceptable to the external auditor. The close runs late and nobody can name the reason The pattern across the mid-market multi-entity finance organizations we have worked with is striking in its consistency. The CFO has set a 10-day close target. The controller publishes a calendar to support the target. The subsidiary controllers run their respective books. The corporate consolidation team builds the consolidated financials. The close lands on day 13, day 14, sometimes day 16, and the post-mortem identifies "intercompany issues" as the cause without further specification. The cause is rarely investigated further because the team intuits the cause and accepts it as a steady-state condition. Subsidiary A's controller posted an IC payable to Subsidiary B for $487,239.42. Subsidiary B's controller posted an IC receivable from Subsidiary A for $487,194.18. The variance is $45.24, which traces to a foreign exchange rounding difference, an in-transit transaction, or a coding inconsistency that surfaces in dispute resolution conversations between the two controllers. The conversations happen on day 9, day 10, day 11. The elimination cannot post until the variance resolves. The elimination must post before the consolidated financials can be produced. The close runs late. We covered the broader 10-day close discipline in our close calendar field guide; intercompany is the workstream that, in most engagements we run, prevents the calendar from landing on the published date. The diagnosis is not subtle. The cycle is well understood. The tools are mature. The deficiency is organizational: nobody owns intercompany at the global level, and the absence of the owner is the absence of the discipline. This guide walks the intercompany cycle as we observe it in mid-market multi-entity organizations, the tooling landscape across the major reconciliation and ERP platforms, the FX and elimination evidence the auditor expects, the recurring failure patterns we cite in close-cycle reviews, and the governance structure that turns intercompany from a perpetual bottleneck into a controlled workstream. The audience is the corporate controller, the consolidation lead, the CFO running multi-entity reporting, and the SOX or internal audit lead with intercompany in scope. The reconciliation discipline that underpins this guide is covered in our reconciliation hygiene field guide; the financial systems posture is in our finance transformation guide. The six-step cycle and the steps where time disappears The intercompany cycle has six steps. They run in sequence each period, they are observable in any multi-entity finance operation regardless of scale, and they are the units against which the discipline is calibrated. Step one: transaction capture. A transaction occurs between two related entities. Subsidiary A provides a service to Subsidiary B; Subsidiary A pays an invoice on behalf of Subsidiary B; Subsidiary A loans cash to Subsidiary B; Subsidiary A allocates a shared cost to Subsidiary B. The transaction is captured at both entities, Subsidiary A as a receivable or revenue, Subsidiary B as a payable or expense. The capture should be coordinated; in practice it often is not. Step two: mismatch identification. At month-end, the IC receivables on one side are matched against the IC payables on the other. Mismatches are identified, variances in amount, timing, account coding, currency, or entity assignment. The mismatch identification is the first place where the manual work begins to dominate the cycle. Step three: dispute resolution. Mismatches are routed to the responsible controllers for resolution. Conversations occur. Source documents are exchanged. Adjusting entries are agreed upon and posted. Dispute resolution is the step that consumes the most calendar time in most organizations. Step four: elimination posting. The matched intercompany balances are eliminated through the consolidation process. Eliminations are posted at the consolidation entity (NetSuite OneWorld's consolidation entity, Sage Intacct's consolidation construct, the SAP central consolidation, the Hyperion or OneStream consolidation layer). The elimination posting depends on a clean match, which depends on resolved disputes, which depends on identified mismatches. Step five: settlement netting. Periodically, monthly, quarterly, or annually depending on cash management policy, the net intercompany balances are settled through cash movement between entities. Settlement netting is operationally distinct from elimination but governed by the same data; settlement that runs on stale or contested IC balances generates the same disputes the close already resolved, repeated. Step six: FX revaluation. For multi-currency operations, the IC balances are revalued at period-end exchange rates, the unrealized FX gains and losses are posted, and the elimination must align across the FX adjustment. FX revaluation introduces complexity at every prior step and is the source of much of the residual variance in the close. The cycle is not optional. Every multi-entity organization runs all six steps, whether they are formally defined or not. The question is whether the organization runs the cycle as a controlled workstream with named ownership, instrumented timing, and documented evidence, or as an emergent property of subsidiary controllers' parallel work that resolves through ad-hoc conversation. The latter is the configuration we encounter in most mid-market engagements, and it is the configuration that produces the close-cycle bottleneck. Why nobody owns it: the structural gap The structural cause of the intercompany problem is the absence of a designated global owner. Subsidiary A's controller is responsible for Subsidiary A's books. Subsidiary B's controller is responsible for Subsidiary B's books. The intercompany transactions live in both books. Neither controller is responsible for the intercompany relationship as a function distinct from the two underlying books. The corporate consolidation team is the closest analog to a global owner in most mid-market organizations, but their role is consolidation rather than intercompany governance. The consolidation team identifies the mismatches at month-end, raises them with the subsidiary controllers, and waits for resolution. They are recipients of intercompany rather than owners of it. The framing, "we close as fast as the slowest subsidiary resolves their IC variances", is structurally accurate. The corporate team does not have authority over the subsidiary controllers' work, does not set the IC accounting policies the subsidiaries follow, and does not have a budget or a reporting line that would support a governance role. The result is that intercompany is everyone's responsibility and no one's. Each subsidiary controller treats IC as a side workstream that detracts from their primary close obligation. Each is incentivized to resolve their own books cleanly first and to address IC mismatches as a secondary priority. The IC variance that requires conversation between two controllers gets the time both controllers can spare from their primary work, which is typically not enough time, which is why the resolution happens on day 10 instead of day 4. The discipline that resolves the gap is the designation of a global IC owner. In larger organizations the role is a dedicated intercompany manager reporting to the corporate controller, with policy authority over IC accounting standards, operational authority over the matching cycle, and visibility across all subsidiary IC activity. In mid-market organizations the role is often a portion of a senior consolidation accountant's responsibility, but it is named, it has documented authority, and the subsidiary controllers know who to escalate to and who has the authority to push back on subsidiary-level IC practices that compromise the global cycle. The named owner does the work that nobody currently does: defines the IC accounting policies (transfer pricing methodology, shared service cost allocation rules, IC interest rate policy, FX revaluation timing), maintains the IC counterparty matrix (which entities transact with which, on what categories of activity), runs the matching cycle on a defined cadence, escalates aged variances, owns the elimination evidence pack, and reports IC cycle metrics to the corporate controller and the CFO. Without the role, the work distributes across subsidiary controllers who have other priorities; with the role, the work has a home. The tooling: BlackLine Intercompany Hub, Trintech, and the native ERP modules The intercompany tooling landscape has matured along two paths: dedicated IC platforms and native ERP IC modules. The choice between them turns on the existing ERP, the multi-entity complexity, and the budget for incremental tooling. BlackLine Intercompany Hub is the dedicated platform with the most mid-market and upper-mid-market adoption. It supports IC transaction capture, automated matching with configurable tolerance, dispute workflow, settlement netting, and reporting. The integration to underlying ERPs is well-developed for NetSuite, SAP, Oracle, Microsoft Dynamics, and the major mid-market platforms. BlackLine's strength is the workflow layer; its weakness is that it sits on top of the ERPs rather than replacing their native IC capabilities, which means the configuration discipline must run in both places. Trintech Cadency offers a comparable IC module with strong adoption in financial services and large multi-entity operations. The functional overlap with BlackLine is substantial; the choice between them is often driven by which platform is already deployed for reconciliation and broader close governance. Native ERP IC modules are increasingly capable. NetSuite OneWorld has a mature IC module with subsidiary-to-subsidiary transactions, automatic elimination at consolidation, and IC reconciliation reporting. The native capability is strong enough that many NetSuite customers operate without a dedicated IC platform. Sage Intacct supports IC transactions through its multi-entity construct with intercompany invoicing and elimination at the top entity; the capability is less rich than NetSuite's but adequate for many mid-market use cases. Microsoft Dynamics 365 Finance offers IC functionality across legal entities, with intercompany journals, intercompany invoicing, and elimination at the consolidation level. SAP S/4HANA has the deepest native IC capability of the major ERPs and is the standard in larger institutional operators. The recurring observation across our engagements is that mid-market organizations underutilize whatever IC tooling they have. NetSuite OneWorld customers often run IC transactions through journal entries rather than the IC module's structured workflow, losing the matching automation that the module provides. Sage Intacct customers often run IC through manual invoicing without leveraging the automatic offset capability. Customers with BlackLine deployed for reconciliation often have not added the Intercompany Hub module despite carrying it in the contract scope. The discipline is not a tooling gap; it is a utilization gap, and utilization improves materially when the global IC owner is named and trains the subsidiary controllers in the structured workflow. The matching tolerance and the dispute workflow The matching cycle's effectiveness depends on tolerance configuration and dispute workflow. The tolerance is the variance threshold below which the system auto-matches IC pairs without human intervention. Set the tolerance too tight and the team drowns in trivial variances (typically FX rounding differences and small timing differences). Set the tolerance too loose and material mismatches escape detection and propagate into the elimination. The configuration we recommend across our engagements is a two-tier tolerance: an automatic-match tolerance set tight (typically $50 to $500 absolute, less than 1% relative), with auto-matched items posted to a documented FX/timing variance account and reviewed monthly by the IC owner; and an exception-routing threshold above which the variance is routed for human resolution. Items between the two tolerances may auto-match but appear on a sampled review report; items above the exception threshold trigger workflow. The dispute workflow is the operational machinery that resolves variances within the close window. The workflow has named roles: the originator (the controller whose entity's number disagrees with the counterparty's), the counterparty (the other entity's controller), the IC owner (who arbitrates if the controllers do not agree), and the consolidation team (who consumes the resolution). The workflow has timing: variance identified by day X, originator response by day Y, resolution agreed by day Z, posting completed by day W. The workflow has artifacts: each variance has a dispute record with the source data, the proposed resolution, and the agreed outcome. The recurring failure pattern is the workflow that exists procedurally but runs informally, variances raised by email, resolved by phone, posted without a documented dispute record. The variance resolves; the close lands; the audit later asks for the supporting evidence and the controller produces an email thread. The auditor's question is whether the IC control includes documented dispute resolution; the email thread does not satisfy the question. The control appears, in audit terms, to be ineffective even though the close itself worked. The workflow tooling, BlackLine, Trintech, the native ERP modules, supports structured dispute records. Using the structured workflow rather than email is a discipline rather than a tooling decision; the discipline that holds is mandatory dispute creation in the structured workflow for any variance above the exception threshold, with the email and phone conversations summarized into the dispute record rather than substituting for it. FX revaluation and the elimination evidence the auditor expects For multi-currency operations, the FX layer adds complexity at every step of the IC cycle and is, in our audit experience, the layer most often producing residual findings. The cycle: The IC transaction is initiated in the originating entity's functional currency (Subsidiary A in EUR provides services to Subsidiary B in USD; the invoice is denominated in EUR). The transaction is recorded at Subsidiary A in EUR; at Subsidiary B in USD using a defined translation rate (transaction date, month-end, average, depending on policy). The mismatch identification at month-end translates both balances to the reporting currency at the period-end rate. The translated balances should match within tolerance; if the policies and rates are applied consistently, they typically do; if they are not, they do not. The elimination posts at the consolidation level in the reporting currency. The FX revaluation gain or loss arising from the period-end translation of the IC balance is recognized in the consolidated financials, with the offset typically running to a CTA (cumulative translation adjustment) or FX gain/loss account depending on the underlying transaction's classification under ASC 830. The audit evidence the auditor expects at the FX layer: 1. The IC counterparty matrix showing the reporting and functional currencies for each entity pair. 2. The FX rate source and the rate used at each translation point (transaction date, month-end, average), with documented policy. 3. The IC balances by counterparty pair before elimination, in functional currency and reporting currency, with the translation rate shown. 4. The elimination entry with the FX gain/loss component identified. 5. The reconciliation of the FX revaluation to the period's rate movement, demonstrating that the revaluation is mathematically consistent with the rates and the balances. The recurring finding is the IC balance whose FX translation cannot be reproduced from the documented rate and the underlying transaction. The variance arises because the rate applied at the originating entity differs from the rate the consolidation team applied at translation, or because the underlying balance was modified after the original translation, or because the rate source itself changed mid-period and the change was not documented. The audit's question is reproducibility: given the documented rate and the documented transaction, can the controller reproduce the translated balance to the cent? When the answer is no, the finding follows. The discipline that holds is documented FX policy (rate source, timing of rate application, treatment of in-transit transactions), reproducible translation worksheets retained as evidence, and quarterly FX policy review by the IC owner with the corporate controller's sign-off. The elimination evidence pack The elimination evidence pack is the consolidated artifact the audit examines for IC controls. The pack should be assembled per period, retained in the close documentation, and produced on audit request without follow-up. The pack we recommend has seven elements: 1. The IC counterparty matrix for the period, showing every entity-pair relationship and the categories of transactions between them. 2. The pre-elimination IC balances by counterparty pair, in functional currency and reporting currency, with the FX rate applied. 3. The matching report showing matched pairs, auto-matched-with-variance pairs, and exception-routed pairs. 4. The dispute log for the period, showing every variance above the exception threshold, the dispute record, the resolution, and the resolution date. 5. The elimination entries posted at consolidation, with the IC source identified, the counterparty pair, and the FX gain/loss component if applicable. 6. The aging report showing IC variances unresolved at period-end, with the variance amount, age, and assigned owner. 7. The IC owner's sign-off with the cycle metrics for the period (variance count, variance dollar value, average resolution time, items aged past policy threshold). The pack is the documentary evidence that the IC control is operating substantively. The audit's review of the pack typically tests selected pairs from the matching report (does the match documentation support the auto-match), selected disputes from the log (does the resolution have substance), and the FX layer (is the revaluation reproducible). The pack assembled proactively closes the audit on first review; the pack assembled under audit pressure exposes the gaps the proactive process would have surfaced. What we recommend Begin with the named owner. The single most-impactful change in any mid-market intercompany engagement is naming a global IC owner with documented authority, a defined role description, and visibility into every subsidiary's IC activity. The role does not have to be full-time; it does have to be named. Without it, every other recommendation in this guide is operable only in fragments. Second, document the IC accounting policy. Transfer pricing methodology, shared service cost allocation, IC interest, FX revaluation timing, settlement netting cadence, each requires a written policy that the subsidiary controllers operate to. The policy is the IC owner's first deliverable and is the artifact the audit will reference when challenging individual subsidiary practices. Third, establish the matching cycle on a defined cadence, typically twice per period, with a hard cut at day 5 of close, and configure the tolerance and exception thresholds in the IC tooling (or in spreadsheets if no tooling is yet deployed). Run the matching reports as a standard close deliverable rather than an ad-hoc inquiry. Fourth, formalize the dispute workflow with structured dispute records, named timing, and required artifacts. Every variance above the exception threshold creates a dispute record; the record carries through to resolution; the record is retained as audit evidence. Fifth, build the elimination evidence pack as the standard deliverable for every period close. Assemble it during the close rather than after; produce it on audit request without rework; refresh the pack format quarterly based on close metrics and audit feedback. Sixth, evaluate the IC tooling utilization against the discipline. Most mid-market organizations have IC capabilities in their existing platforms (NetSuite OneWorld, Sage Intacct, BlackLine if deployed for reconciliation) that they are not fully using. The IC owner's review of the existing tooling capability against the documented cycle frequently surfaces capacity that does not require new licensing. Intercompany is not the close's hardest problem. It is the close's longest-running problem, perpetuated by the absence of an owner and the absence of a discipline. Both gaps are organizational rather than technical. Name the owner, define the cycle, instrument the matching, produce the evidence pack, and the workstream that prevented the 10-day close from landing becomes the workstream that lands on day 6 alongside the rest of the close. We covered the calendar discipline that supports the result in our 10-day close field guide; the IC cycle is the lever that makes the calendar achievable.