When I look at intercompany settlement, the first thing I want to know is not how many invoices the group has generated. I want to know what actually needs to move after the group has offset what it owes itself.
That distinction sounds obvious, but many organisations still operate the process at the level of individual obligations. Every entity prepares its positions, payments are coordinated entity by entity, FX is handled around those flows and treasury spends time explaining why so much internal cash is moving around.
Intercompany netting gives us a different starting point: calculate the group’s residual positions first, then settle what remains.
Netting becomes valuable when the workflow is connected
A spreadsheet can calculate a net amount. That is not the hard part.
The harder part is running the cycle. Which entities are participating? What is the cut-off? Has everyone submitted? Which FX rate applies? Does a subsidiary agree with the statement? Which line item is disputed? Has the calculation been rerun? Is the result approved for settlement?
If those questions live across spreadsheets, email and ERP extracts, treasury becomes the project manager of every cycle. I think the product opportunity is to turn that coordination into a structured workflow.
The cycle should expose problems before the settlement date
One of the things I like most about a controlled netting process is that it brings exceptions forward.
Treasury should be able to see a missing submission before cut-off. An entity should be able to dispute a specific item instead of rejecting the entire result. The team should be able to preview positions before finalisation and see which entities will be the largest payers or receivers.
That makes the settlement date less of a surprise. The work moves earlier in the cycle, where there is still time to resolve it.
FX should be managed on the position that remains
The same logic applies to foreign exchange.
If two or more internal flows offset each other economically, I do not want treasury to manage the FX as if every gross leg were independent. I want the process to show the residual exposure after netting so the team can decide what actually needs to be converted or hedged.
This is where netting starts to connect directly with risk management. The settlement process is changing the exposure treasury needs to act on.
The payment workflow should start from a confirmed net result
I also do not want the netting process to end with somebody copying settlement amounts into a payment file.
Once the entities have confirmed the positions and the cycle has been finalised, the settlement instructions should be able to move into the payment module or in-house bank. When netting and in-house banking run on the same platform, settlement can be handled as an internal booking rather than an external payment where the operating model allows it. The normal payment controls still apply. Netting should not weaken the approval model; it should give that model a cleaner settlement instruction to work with.
Internal payments still affect the group liquidity picture
There is a reason I think intercompany netting belongs in the liquidity conversation.
Even though the obligation is internal, the settlement changes where cash sits. A large cycle can create significant payer and receiver positions across entities. Treasury needs that effect in the cash position and in the forecast, particularly when local liquidity or funding capacity is tight.
If the netting result remains in its own workbook until someone manually updates the liquidity view, we have solved only part of the process.
The CFO should be able to see what the group avoided
A good netting process should also make its own effect visible.
Gross versus net payment volume is a useful measure. So is the change in FX activity. Over time, these measures help treasury show why the process matters beyond administrative convenience.
The question for the CFO is not whether treasury ran the monthly netting cycle successfully. It is whether internal cash is being deployed with less friction and whether the organisation has control over the process that moves it.
The role of treasury is coordination with financial intent
Intercompany netting sits between accounting data, liquidity, FX and payments. That is exactly why it belongs in treasury.
ERP provides the obligations. Entities validate what they owe and receive. Treasury controls the cycle, calculates the net positions, manages the financial treatment and decides how residual FX should be handled. Payments executes the confirmed settlement under the right approvals.
When those pieces are connected, treasury is no longer just chasing submissions. It is managing the group’s internal settlement with a clear financial objective.
Start with the cycle that creates the most noise
For organisations considering netting, I would not start by trying to redesign every intercompany process at once.
Start with the cycle that creates the most payment volume, the most FX conversions or the most manual coordination. Define the participants and cut-off. Make submissions visible. Put confirmation and disputes into the process. Connect the final result to payments.
Then measure the difference between gross activity and what actually had to move. That is usually where the value becomes very tangible.
Marc Vietor
Chief Product Officer, Nomentia
