There's a particular kind of dread that settles over a treasury team in the final days of every month. The close is coming. The intercompany numbers need to tie. And somewhere between SAP, three banking platforms, a shared drive full of spreadsheets, and an email thread that has forked into six sub-conversations, the reconciliation process begins again.
It looks roughly the same as it did five years ago. In some organizations, ten years ago. The tools around it have gotten better — the ERP is newer, the banks offer better portals, someone may have even built a macro that auto-highlights mismatches. But the fundamental workflow is unchanged: pull data from multiple systems, paste it into a workbook, manually match transactions row by row, investigate the ones that don't tie, document what happened, and pray that next month's close doesn't surface something that should have been caught this month.
This isn't a technology problem in the way most people mean it. There's no shortage of software that touches parts of the intercompany workflow. The problem is structural — and until you name the structural issues, no amount of software solves them.
The core structural problem: two unilateral records pretending to be one bilateral transaction
When Entity A in Brazil records an intercompany payable to Entity B in Argentina, it creates a record in its local ledger. When Entity B records the corresponding receivable, it creates a separate record in its own ledger. These two records are created independently, in different systems, often in different currencies, sometimes days apart.
The reconciliation process is the act of retrospectively proving that these two unilateral records actually represent the same underlying economic event. That's the whole game. And it's surprisingly hard because the two records were never structurally connected in the first place.
Think about what this means in practice. Entity A records a payment of BRL 12,450,000 on March 3rd. Entity B records a receipt of ARS 2,890,000,000 on March 5th. Are these the same transaction? At what exchange rate? Was the rate locked at trade date or settlement date? Did either entity adjust the amount post-booking? Is there a withholding tax differential that explains the gap? The answers to these questions live in different systems, owned by different people, in different time zones.
The analyst doing the reconciliation is essentially reverse-engineering a bilateral relationship from two unilateral breadcrumbs. Every month. For every entity pair. Across every corridor.
Why TMS platforms haven't fixed this
Treasury management systems were built to solve a different problem: giving a central treasury team visibility into cash positions across banks and entities. They're good at that. Bank connectivity, cash pooling, payment initiation, FX exposure reporting — these are well-served capabilities.
But intercompany reconciliation is a different beast. It requires understanding the relationship between two internal counterparties — not just the external banking activity. Most TMS platforms treat intercompany transactions the same way they treat any other cash movement: as a line item in a bank statement. They don't model the bilateral nature of the transaction. They don't track whether both legs have been recorded. They don't automatically detect that a BRL payable in São Paulo and an ARS receivable in Buenos Aires are two sides of the same coin.
The result is that even companies with sophisticated TMS deployments still reconcile intercompany flows manually. The TMS tells you what happened at the bank level. The spreadsheet is where someone figures out whether the intercompany books actually balance.
There's also a deployment reality that compounds the problem. The average TMS implementation takes 12 to 18 months and requires significant IT involvement for ERP integration, bank connectivity, and data mapping. For a middle-market multinational with 20 to 80 entities, the implementation cost and timeline often exceed the budget and patience of the treasury team that needs the tool. So they stick with the spreadsheet. Not because it works well, but because it works now.
The batch processing trap
Even where TMS platforms do handle intercompany matching, they almost universally operate in batch mode. Bank statements are ingested daily or weekly. Matching runs happen on a schedule — often aligned with the monthly close cycle. Discrepancies are identified after the fact, sometimes weeks after the underlying transactions settled.
This creates a compounding investigation problem. When a mismatch surfaces at month-end, the people who initiated the transaction may not remember the details. The FX rate that was quoted may have been superseded. The email that clarified the adjusted amount may be buried in someone's inbox. The cost of investigating a discrepancy increases with every day that passes between the transaction and its discovery.
Continuous matching — where transactions are paired as they arrive, not in a monthly batch — isn't a feature request. It's a fundamentally different operational model. It means discrepancies surface while context is still fresh, while the people involved still remember what happened, while the audit trail can be constructed in real time rather than reconstructed after the fact.
The audit trail problem nobody talks about
Here's something that doesn't get enough attention: the audit trail for intercompany reconciliation at most companies is functionally unreliable.
When a reconciliation is performed in a spreadsheet, the "audit trail" is the spreadsheet itself — plus whatever emails, Slack messages, and meeting notes document the investigation of individual discrepancies. When someone overwrites a formula, there's no record. When a correction is made to last month's reconciliation, the original state is gone. When an analyst leaves the company and takes their institutional knowledge of the matching logic with them, the next analyst starts from scratch.
This matters for more than just operational hygiene. Transfer pricing documentation, intercompany loan compliance, withholding tax substantiation — these all depend on being able to prove what happened, when, and why. Regulatory scrutiny of intercompany transactions is increasing, not decreasing. And the documentation burden falls on the same team that's already spending the first week of every month manually matching transactions.
A reconciliation system that cannot produce a tamper-proof, chronological record of every transaction, every match decision, every correction, and every state change is not solving the whole problem. It's solving the matching problem while leaving the compliance exposure wide open.
What a real solution would require
If you were designing intercompany reconciliation infrastructure from scratch — unconstrained by how TMS platforms evolved — you'd build something with a few specific properties.
First, you'd model the intercompany transaction as a natively bilateral object. Not two unilateral records that get matched later. A single object that expects two legs, tracks both, and flags when one is missing. This is the conceptual shift that matters most. Every downstream capability — matching, discrepancy detection, compliance documentation — gets simpler when the data model reflects how the transaction actually works.
Second, you'd match continuously, not in batch. As data arrives from ERPs and banks, the system would attempt to pair it immediately. When both legs are present and consistent, the transaction is matched. When something is off — amount mismatch, FX variance, missing counterparty — it surfaces instantly, not at month-end.
Third, you'd make the audit trail structural, not incidental. Every record, every match, every state change recorded in a sequence that can't be altered after the fact. Not a database log that an admin can edit. Not a spreadsheet that anyone can overwrite. A system that your auditors can trust because the architecture makes tampering structurally impossible.
Fourth, you'd deploy in weeks, not years. If the solution requires a 12-month implementation project with dedicated IT resources and external consultants, you've recreated the same adoption barrier that keeps companies on spreadsheets. The initial integration should be file-based — the same bank statements and ERP exports the team already produces — with deeper API integration as an upgrade path, not a prerequisite.
None of these properties are technically exotic. The challenge isn't inventing new technology. It's having the architectural discipline to build the right foundation instead of bolting new features onto the wrong one.
The window is open
The treasury technology market is shifting. Cloud-native deployments are overtaking on-premise installations. AI capabilities are moving from roadmap slides to production features. Corporate adoption of alternative settlement infrastructure is accelerating. And the operational burden on treasury teams — especially at mid-market multinationals that lack the headcount and banking leverage of the Fortune 100 — is only growing.
The companies that still reconcile intercompany transactions in spreadsheets aren't doing so because they're unsophisticated. They're doing so because no one has built a tool that solves their specific problem with a deployment model they can actually adopt.
That's starting to change.
Trezh is building AI-powered intercompany reconciliation infrastructure for multinational treasury teams.