The Hardest Problem in Financial Close That Nobody Talks About

• Massive operational scale: Intercompany transactions account for up to one-third of global trade, making them a hidden but dominant category in enterprise finance.

• Built-in structural mismatches: Divergent timing, complex foreign exchange, and strict transfer pricing rules create persistent transactional discrepancies across entities.

• Inherent ERP limitations: Standard ERP systems are built for single-entity accounting, leaving critical visibility and integration gaps across a corporate group.

• Continuous automation opportunity: Viewing intercompany as a distributed data reconciliation challenge enables AI and automated workflows to continuously resolve balances.

Ask most people outside of finance what makes the monthly close hard, and they'll point to the obvious suspects: revenue recognition, accruals, and the scramble to reconcile bank statements before the deadline. Almost no one says "intercompany." It sounds like plumbing, a back-office detail about how one part of a company bills another part of the same company. How hard could moving money from your left pocket to your right pocket really be?

Intercompany is genuinely difficult, and its difficulty is interrelated rather than isolated. It stays invisible because it isn't a single problem: it spans timing, currency, data, coordination, and tax, and those pieces compound one another, becoming visible only at scale.

Start with how much of the economy this represents. By most estimates, roughly one-third of global trade takes place within multinational groups rather than between unrelated companies, according to global value chain research by The World Bank; goods, services, financing, royalties, and shared-service charges flow among entities that all roll up to the same parent. For a large enterprise, intercompany isn't a rounding error in the financial statements; it is often among the largest categories of transactions the finance team has to process, validate, and ultimately eliminate before consolidating the books. And every transaction must be correct.

The examples you'll read about throughout this piece come from conversations with finance leaders and practitioners at large enterprises, kept anonymous at their request. To get a sense of what that means in practice: the enterprises we work with typically manage intercompany across 50 to 120 legal entities, running 2 to 6 or more ERP systems simultaneously, with 80 or more active trading partner relationships—many of them coordinated almost entirely through email and spreadsheets. These aren't edge cases; they represent how large enterprises operate.

The trouble starts the moment you realize there is no single source of truth. A normal customer invoice has one author. An intercompany transaction has two, and they rarely agree. This discrepancy sets it apart from ordinary transaction matching: rather than checking your books against an outside party's, you are reconciling two of your own records, booked in different systems, currencies, and calendars, that are meant to describe the same event.

When Entity A in Germany sells components to Entity B in Singapore, both sides book the transaction independently, often in different ERP systems, different currencies, different local accounting standards, and on different calendars. A records a receivable, and B records a payable. In theory, these are mirror images. In practice, one side booked it in the period it shipped, and the other booked it when it arrived. One applied for a rebate, and the other didn't know about it. One rounded the currency conversion a fraction of a cent differently. Multiply that across hundreds of entities and millions of transactions, and you have a reconciliation problem that grows combinatorially, not linearly.

Two entities in two time zones, closing on two schedules, will book the same transaction in different periods more often than you'd think. The amounts can match perfectly and still be "out of balance" simply because they landed on opposite sides of a period cutoff. Any system that tries to match intercompany activity must reason about when as carefully as it does about how much. What makes this particularly painful at close is that these issues don't surface until it's almost too late to fix them. Finance teams describe discovering variances on Day Two or Day Three of close, when the calendar has already started, and every hour counts.

Cross-border entities settle intercompany transactions across currencies, and the exchange rate used depends on the date, the source, and local policy. The "same" transaction recorded by two entities can legitimately differ due to the FX gain or loss between the booking dates. Distinguishing a real discrepancy from an expected currency difference is non-trivial, and getting it wrong means either chasing phantom mismatches or missing real ones. One finance leader we spoke with put it plainly: for their company, FX was the primary driver of intercompany breaks every single month, and the team could rarely tell with certainty whether a balance difference was a true transactional error or simply the result of remeasurement. That uncertainty persists until someone conducts a significant amount of manual investigation work that, in most organizations, falls in the last few days of the close, when no one has time for it.

The prices entities charge each other aren't arbitrary; transfer pricing rules and international tax frameworks design them to ensure entities report and tax profit in the right jurisdiction. That means intercompany isn't only about making the numbers tie out. It's about defending those numbers to tax authorities in every country where you operate, with documentation to back them up. A mismatch isn't just an inconvenience; it can be an audit exposure. And the practical challenge is that transfer pricing policy typically lives with the Tax team, while execution responsibility falls on Finance—teams that often aren't well connected and don't share systems or visibility.

ERP systems are the powerful, foundational engines of modern finance, managing single-entity books with incredible precision. However, because intercompany transactions inherently span multiple distinct legal entities, they introduce a layer of cross-boundary coordination that naturally sits above any single ledger.

In large, growing enterprises, this complexity naturally multiplies. Mergers and acquisitions introduce diverse ERP systems, distinct charts of accounts, and varying counterparty identifiers. Rather than replacing or competing with these core transactional systems, modern finance teams need a collaborative layer to orchestrate data between them.

This is where solutions from BlackLine complement your existing technology. Our unified Intercompany solution acts as a central orchestrator, sitting alongside your ERPs to seamlessly match, reconcile, and balance transaction data at the group level—regardless of how many disparate systems feed into it. By bridging these systems, we help you unlock the full value of your foundational ERP investments.

Beyond the technical fragmentation, intercompany has a human coordination problem that's just as acute. One finance team described their monthly process: they send balance confirmation requests to 80 trading partners, hear back from roughly one-third of them within two days, and spend the rest of the close cycle chasing the remaining 50-odd entities through email. By the time the confirmations are in and the team identifies the variances, their team has burned two-plus collective days just on the confirmation loop, before any actual reconciliation work begins. That pattern repeats across the industry. Intercompany has many participants—accounting, tax, treasury, FP&A, supply chain, and legal—but no single owner, and no enforced process. The result is coordination by inbox, which doesn't scale.

The final twist is that at consolidation, the finance team must eliminate intercompany activity entirely. From the group's perspective, selling something to yourself doesn't generate revenue or profit, so the team must identify and remove every intercompany sale, balance, and margin before consolidating the statements. You spend enormous effort recording, matching, and settling these transactions, and the reward for getting it all right is that they cleanly disappear. Miss one, and you've overstated revenue or profit at the group level, exactly the kind of error that draws an auditor's attention.

It would be easy to read all of that as an accounting headache. We see it as a genuinely interesting systems problem in enterprise finance, and that's the part worth saying out loud.

Strip away the accounting vocabulary, and intercompany is fundamentally a distributed data reconciliation problem under misaligned constraints. You have independent actors (entities) recording events into independent systems of record, with no shared clock, no shared currency, and no shared schema, and you have to reconstruct a single consistent global truth from those disagreeing local truths fast enough to close the books on time, accurately enough to satisfy regulators, and at a scale of millions of transactions.

That framing should sound familiar to anyone who has built distributed systems. It's matching and entity resolution at scale. It's reasoning about eventual consistency and reconciliation across sources. It's modeling timing, rounding, and tolerance so the system can distinguish meaningful discrepancies from expected noise, including currency remeasurement differences that appear to be breaks but aren't. It's designing workflows for cases where two parties genuinely disagree, and a human must adjudicate with a clean audit trail of who decided what and why. It's building the right interfaces for a world where agents can handle the routine matches automatically, but humans need to see the reasoning and stay in control when a variance is genuinely ambiguous. And it's doing all of that on top of master data that is messy, incomplete, and inconsistent across the very systems you're trying to reconcile.

Those are hard, satisfying engineering problems. They just happen to be wearing an accounting costume.

The companies wrestling hardest with intercompany are the largest, most complex organizations in the world, the ones with the most entities, the most ERPs, the most jurisdictions, and the most at stake when the close runs long or the numbers don't tie out. One finance leader said it as well as we've heard it said: "If we're able to get to a spot where intercompany is no longer a thought process during month-end because it's already reconciled and we're good to go, that is massive for us. It's our biggest pain point."

Solving intercompany well doesn't just save a few late nights at month-end. It shortens the close, reduces audit risk, frees finance teams from chasing reconciliations, and, when the matching and coordination happen continuously rather than only at period-end, turns a scramble into a process. It is also a natural fit for AI: agents can carry the routine matching, confirmation-chasing, and reconciliation continuously in the background, surfacing only genuinely ambiguous variances for a person to judge—the direction our own product vision is heading. That's the kind of problem our teams find worth solving: invisible until it breaks, deceptively deep once you look closely, and genuinely hard in ways that reward good engineering.

Solving intercompany is one of the highest-leverage things finance can do in the Office of the CFO, and it's a core part of what our teams at BlackLine are building toward as finance automation advances.