Agentic Intercompany Netting and Settlement: One Wire Per Currency Instead of One Per Balance
written by Cooter:Labs
published on September 25, 2026
Introduction
A multi-entity company with active intercompany trading racks up dozens of payables and receivables between subsidiaries every month — a manufacturing entity billing a distribution entity for goods, a shared-services entity billing everyone for allocated overhead, a treasury center charging interest on intercompany loans. The naive settlement path has every entity wire its own gross balance to every counterparty it owes, in whatever currency that invoice was denominated in. That's a lot of separate wires, a lot of FX spread paid on amounts that would have partially cancelled out anyway, and a lot of bank fees for moving money that, netted, adds up to a fraction of the gross flow. Netting is not a new idea — treasury teams have run manual netting cycles for decades — but doing it well requires pulling a complete, current picture of every open intercompany balance across every entity and currency pair at the same moment, which is exactly the kind of continuous, multi-system aggregation an agentic workflow is suited to.
Netting only saves money and reduces risk if the number going into the settlement is trustworthy — every open intercompany balance accounted for, correctly matched to its counterparty and currency, with nothing double-counted and nothing missed. That's a data-aggregation and matching problem before it's a treasury decision, and it's where an agent earns its place ahead of the human sign-off.
Each subsidiary's ERP instance (or company code, in a shared single instance) carries its own view of what it owes and is owed — an AP entry for an intercompany invoice received, an AR entry for one issued, a loan schedule for intercompany financing, an allocation entry for shared-services charges. The agent pulls all of these into a single consolidated position by counterparty pair, rather than relying on each entity to self-report its net position, because self-reported positions are exactly where mismatches hide: entity A's AR for a transaction doesn't always equal entity B's AP for the same transaction, whether from timing differences, FX rate differences applied on each side, or a posting error. The agent flags any pair where the two sides don't agree before that pair goes into the netting run, since netting a number that's already wrong just launders the discrepancy into a wire transfer.
Netting works because obligations offset: if entity A owes entity B $200,000 and entity B separately owes entity A $150,000, the productive settlement is a single $50,000 payment from A to B, not two gross wires. The agent groups every open balance by the specific currency each obligation is denominated in and the specific pair of entities involved, since netting across currencies requires an FX conversion decision that changes the settled amount, while netting within a currency pair is pure arithmetic. Where a company runs a netting center — a single entity, often treasury, that becomes the counterparty for everyone instead of true multilateral entity-to-entity netting — the agent nets each subsidiary's position against the center rather than against every other subsidiary directly, since that's the structure the actual settlement will follow.
When a net position spans currencies — an entity owes in EUR and is owed in GBP — someone has to pick a conversion rate and a conversion point, and whichever entity's functional currency differs from the settlement currency absorbs some FX exposure in the conversion. The agent applies whatever rate source and timing the company's netting policy specifies (a daily central rate, a rate locked at cycle cutoff, whatever's documented) consistently across every entity in the same run, rather than letting each entity's own ERP apply its own default rate, which is one of the more common ways manual netting cycles silently create small unexplained variances that pile up over quarters. It also computes and surfaces what each entity gains or loses relative to settling gross at spot, since that's the number that actually justifies running netting in the first place.
The output of the netting run is a proposed set of payments — which entity pays which counterparty (or the netting center) how much, in which currency, by when — not an executed wire. The agent generates that instruction set and the supporting detail (which underlying invoices and balances rolled into each net figure), so treasury is reviewing a specific, traceable proposal rather than reconciling the netting math themselves before they can even evaluate it. Where the company's banking setup supports it, the agent stages the payment instructions in the treasury or payment system ready for release; where it doesn't, it hands treasury a instruction file formatted for whatever manual entry step remains.
Once a net settlement executes, every underlying gross intercompany balance that fed into it needs to clear in each entity's own ledger — not just the net amount that actually moved. The agent applies the settlement against the specific invoices and balances it aggregated in the first phase, entity by entity, so each subsidiary's books show its intercompany positions cleared correctly even though no cash actually moved in or out of most of them directly. Skipping this step is how netting cycles quietly diverge from the underlying subledgers over time, since the net wire clears in the bank statement but the gross entries just sit open in each entity's AP and AR.
Looking Ahead: Challenges and Innovations
It's only as good as the least reliable entity's data
A netting run is a single computation across every participating entity, so one subsidiary running behind on posting intercompany invoices, or reconciling its intercompany accounts infrequently, degrades the accuracy of the whole cycle rather than just its own position. The agent can flag stale or unreconciled data going into a run, but it can't manufacture posting discipline in an entity that doesn't have it — the practical fix is usually a cutoff policy (an entity's late-posted balances roll into the next cycle rather than holding up the current one), which is a business decision, not something the agent can decide on its own.
Regulatory and tax constraints on netting differ by jurisdiction
Some jurisdictions restrict or specifically regulate intercompany netting arrangements — foreign exchange controls, withholding tax treatment on netted versus gross payments, or transfer-pricing documentation requirements that expect to see the underlying gross transactions clearly, not just a net figure. The agent applies whatever netting participation rules and exclusions are configured per entity, but confirming that a given jurisdiction's arrangement is compliant in the first place is a legal and tax question that has to be settled before the entity is added to the program, not something the reconciliation logic can determine from transaction data.
A disputed underlying balance still needs a human conversation
When the AP and AR sides of an intercompany pair don't match going into a run, the agent can identify exactly which transaction and which side is inconsistent, but it can't decide which entity's number is correct — that depends on which one has the accurate underlying event (a delivery that happened, a service that was actually rendered, an allocation that was calculated correctly), which usually means someone on each side comparing records. The agent's contribution is making sure that conversation starts from a precise, dollar-and-transaction-level discrepancy instead of a vague sense that the numbers don't tie out.
The metaverse
Intercompany netting has traditionally run on a fixed cycle — monthly or quarterly — because assembling a clean cross-entity position by hand is expensive enough that nobody wants to do it more often. As more ERP instances and intercompany billing systems expose transaction-level data through APIs rather than end-of-period exports, the more useful direction is shortening that cycle: a continuously maintained net position that treasury can settle weekly or even more frequently when working capital or FX volatility makes it worthwhile, instead of carrying a month of gross intercompany exposure on the books by default because that's how often anyone could previously afford to compute the alternative.
Conclusion
Netting is a straightforward idea — pay the difference, not the gross amounts — that gets complicated by everything required to trust the number going into it: complete data from every entity, correctly matched pairs, a consistently applied FX conversion, and a clean write-back to every subsidiary's own books once cash actually moves. An agent that continuously aggregates and reconciles the intercompany position turns netting from a labor-intensive periodic exercise into something treasury can run as often as the FX and working-capital math justifies, with a specific, traceable settlement proposal instead of a spreadsheet someone has to trust. It still doesn't replace treasury's own judgment about timing, currency risk appetite, or which disputes are worth resolving before a given cycle closes — it means that judgment gets applied to a number that's already correct.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.