Most multilateral netting examples you will find online are exam answers. Three subsidiaries called A, B and C, amounts in dollars, one flat percentage for "transaction costs", and a saving that quietly assumes the netting centre moves money for free. That is fine for passing a paper. It is not much help when you are the controller of a UK group with a German, a French and a Polish subsidiary and want to know what netting would actually change next month.
So this is one multilateral netting example worked end to end on a realistic group: the payment matrix, the net positions, the check, the bilateral comparison on the same data, and then the part the textbooks skip, which is what the settlement costs once you price every leg, including the ones that run through the netting centre itself. Every number in the example is illustrative. The method and the rules around it are sourced.
If you want the concept before the arithmetic, start with our guide to multilateral netting. If you want the wider picture of money moving between your own companies, read intercompany payments first.
The example group and its month of invoices
Four entities, three currencies:
- •UK Ltd, GBP, the parent and the netting centre
- •DE GmbH, EUR
- •FR SAS, EUR
- •PL sp. z o.o., PLN
Over the month they invoice each other for management services, shared engineering and licensed software. Netting needs one currency, so every amount is converted at a single agreed rate into the centre's currency first, which is the standard approach in the ACCA method for netting questions. Here is the matrix in GBP thousands. Read each row as "this entity pays that column".
| Payer \ Receiver | UK Ltd | DE GmbH | FR SAS | PL | Total paid |
|---|---|---|---|---|---|
| UK Ltd | 0 | 120 | 40 | 30 | 190 |
| DE GmbH | 90 | 0 | 60 | 50 | 200 |
| FR SAS | 70 | 30 | 0 | 20 | 120 |
| PL | 25 | 85 | 15 | 0 | 125 |
| Total received | 185 | 235 | 115 | 100 | 635 |
Without netting, that is 12 separate payments moving 635,000 GBP equivalent. With four entities, 12 is the maximum: every entity can owe every other one, so the pairs grow as n(n-1), which is why the problem gets worse much faster than the group grows.
Step by step: from 12 payments to 3
The process itself has four stages: data collection, reconciliation of each payable against the matching receivable, calculation of a single net amount per entity, and settlement on a fixed date. Assume reconciliation is done and every invoice is agreed. The calculation is three moves.
Total each row and column
Each row total is what the entity pays. Each column total is what it receives. Those are already in the table: UK Ltd pays 190 and receives 185, DE GmbH pays 200 and receives 235, and so on.
Net positions and the zero-sum check
Net position is receipts minus payments. Positive means net receiver, negative means net payer.
| Entity | Receives | Pays | Net position | Role |
|---|---|---|---|---|
| UK Ltd | 185 | 190 | -5 | Net payer |
| DE GmbH | 235 | 200 | +35 | Net receiver |
| FR SAS | 115 | 120 | -5 | Net payer |
| PL | 100 | 125 | -25 | Net payer |
Now check. The net positions must add up to zero, because every pound owed by one entity is owed to another entity in the same group, so a non-zero sum means a data entry error. Here: -5 + 35 - 5 - 25 = 0. Net payments (5 + 5 + 25 = 35) equal net receipts (35). The total that has to settle is 35, which is the same as the sum of the absolute net positions divided by two.
Who pays whom
- •FR SAS pays 5 to the netting centre
- •PL pays 25 to the netting centre
- •UK Ltd, as the centre, adds its own 5 and pays DE GmbH 35
Twelve invoices, 635,000 GBP of gross flows, settled with three payments and 35,000 GBP of net value. That is the headline every example gives you: gross flows of 635 reduced to 35, a 94 percent reduction in value settled.
Bilateral netting on the same data
It helps to see why the multilateral version wins. Bilateral netting only offsets each pair against itself. The ACT's own illustration shows the principle: a sterling company due to pay 800,000 EUR and owed 785,000 EUR by the same counterparty settles just 15,000 EUR, halving the transaction count.
Apply it pair by pair to our group:
| Pair | Gross both ways | Net settlement |
|---|---|---|
| UK and DE | 120 / 90 | UK pays DE 30 |
| UK and FR | 40 / 70 | FR pays UK 30 |
| UK and PL | 30 / 25 | UK pays PL 5 |
| DE and FR | 60 / 30 | DE pays FR 30 |
| DE and PL | 50 / 85 | PL pays DE 35 |
| FR and PL | 20 / 15 | FR pays PL 5 |
Six payments and 135 of value. Better than 635, but almost four times the multilateral 35, because bilateral netting cannot see that DE's surplus with PL and its deficit with FR are part of one position. The full trade-off between the two approaches is covered in bilateral vs multilateral netting.
What the netting actually saves, priced
The exam answer multiplies the reduction by one cost rate and stops. Real settlement has two costs that behave differently: a fixed fee per payment, and an FX margin on every amount that changes currency. To make the example concrete we use our own published rates as the inputs: SEPA and UK Faster Payments at 0.99 GBP, international SWIFT at 26.40 GBP, internal transfers free, and FX at 0.70 percent on major pairs and 0.90 percent on minors. Your bank's rates will differ; swap them in and the method holds. We treat GBP and EUR legs as majors, PLN legs as minors, every cross-currency payment as a SWIFT payment, and the two EUR to EUR flows as SEPA.
Gross settlement cost
| Cost line | Volume | Cost |
|---|---|---|
| FX on GBP and EUR legs (0.70%) | 320,000 | 2,240.00 GBP |
| FX on PLN legs (0.90%) | 225,000 | 2,025.00 GBP |
| 10 SWIFT payments | 264.00 GBP | |
| 2 SEPA payments | 1.98 GBP | |
| Total per month | 4,530.98 GBP |
Bilateral netting on the same rates comes to roughly 958 GBP a month: 825 GBP of FX across 105,000 of converted value, plus five SWIFT payments and one SEPA payment.
The hub's own legs, which textbooks skip
Here is where most worked examples go wrong. A common exam treatment says that settling through a central unit moves the same total as netting without one. It does not, once you count the wires. With a centre, money moves in and then out again. In our example FR sends 5 in, PL sends 25 in, and the centre sends 35 out. That is 65 of value over the rails, not 35, and every leg converts currency if the centre only holds sterling:
- •FR to centre, 5 EUR to GBP at 0.70%: 35 GBP
- •PL to centre, 25 PLN to GBP at 0.90%: 225 GBP
- •Centre to DE, 35 GBP to EUR at 0.70%: 245 GBP
- •Three SWIFT payments: 79.20 GBP
Total: 584.20 GBP a month. Still a large drop from 4,530.98 GBP, but the netting centre converted money into sterling only to convert most of it straight back out.
Matching through currency accounts
The fix is the other half of the textbook toolkit, matching, which offsets receipts and payments in the same currency so only the net amount needs converting or hedging. If the centre holds a EUR account and a PLN account alongside sterling, FR's 5 EUR arrives in euros and leaves again in euros to DE. Only the PLN 25 and UK Ltd's own 5 need converting into EUR.
- •FR to centre EUR account, SEPA: 0.99 GBP
- •PL to centre PLN account: 26.40 GBP, conservatively priced as a SWIFT payment
- •Centre converts 25 PLN to EUR at 0.90%: 225 GBP
- •Centre converts its own 5 GBP to EUR at 0.70%: 35 GBP
- •Centre pays DE 35 EUR, SEPA: 0.99 GBP
Total: 288.38 GBP a month, against 4,530.98 GBP with no netting at all. Illustrative, monthly, on one set of rates, and it ignores the people and software that run the cycle. But it shows where the money actually goes: the FX margin, not the wire fee, is most of the cost, and the currency structure of the netting centre decides how much of it you keep paying. That is also why the ACT lists reduced FX commissions and less money lost in transit ("float") as benefits on top of the lower payment count.
What changes when you run it for real
The arithmetic is the easy part. Four practical issues decide whether the cycle survives contact with a real group.
Germany: netting is still reported gross
This is the one that surprises UK-led groups. Under the German Foreign Trade and Payments Ordinance, offsetting and settlement by account (Aufrechnung and Verrechnung) count as payments, and payments not exceeding 50,000 EUR are exempt from reporting. The Bundesbank is explicit that in a netting procedure the gross amounts behind the netting are reported as incoming and outgoing payments, and the balances being netted generally are not. Payments for goods are exempt under the same rule, but our invoices are services.
In our example DE GmbH receives one payment of 35. Its reporting does not shrink to match: the 120 it was owed by UK Ltd and the 90 it owed back are each reportable gross where they exceed the threshold. Netting saves wire and FX cost. It does not save German statistical reporting, so build the gross data into the cycle from day one.
Indemnities, third-party receipts and timing
Groups are tempted to route customer receipts through the netting system too ("collections on behalf of"). The ACT explains why that is usually a mistake: in the UK a bank may be liable for funds diverted to an account other than the intended beneficiary's, so it will ask the group for an indemnity; and if too long passes before the money reaches the right subsidiary, the delay can be treated as an interest-free intercompany loan, creating interest allocation and withholding tax problems. Its conclusion is that external receivables are usually left out in practice. Supplier payments made by the centre on a subsidiary's behalf are easier and more common.
The same logic is why the ACCA method closes every netting answer with a comment on exchange control limits, timing of settlement and tax. Some jurisdictions restrict netting outright. This is general information, not tax or legal advice, and your group's position depends on where each entity sits.
Disputes and cut-offs
Netting only works if every payable matches a receivable by the cut-off. In practice two entities disagree about a price, or one books in March and the other in April. Mature setups give the netting centre an invoice matching process with a dispute workflow in which the centre acts as referee applying the group's rules. Small groups do the same thing with a spreadsheet and a firm date. What matters is that a disputed invoice drops out of this cycle rather than holding the whole cycle up.
Where an account layer fits
The cheapest leg in the example is the one that never leaves the group's own account structure. If every entity holds its balances on one platform with its own currency accounts, a transfer between them is an internal book entry rather than a rail payment, and the netting centre can match currencies without paying to convert them in and out. That is how we built it: dedicated IBANs across 16 or more currencies, reaching SWIFT, SEPA, FPS, BACS and CHAPS, with internal transfers free. It is the same reasoning behind a multi-currency business account for any group with more than one operating currency.
Be clear about the boundary. An account layer does not calculate your net positions, reconcile disputed invoices or file your Bundesbank reports. It makes the settlement step cheaper and faster once those are done.
The compliance position, stated exactly. Regulated payment services are provided by Gemba Finance Limited, FCA FRN 804853, UK customers only. EXFI is a trading name of EX Financial Solutions Ltd, which is not itself authorised or regulated by the FCA and acts as a distributor of those services. These are payment accounts, not bank accounts; funds are not covered by the FSCS but are safeguarded in segregated accounts in accordance with the Payment Services Regulations 2017.
Run the example on your own numbers: build the matrix from last month's intercompany invoices, net it, then price every leg, including the centre's. The gap between the exam answer and your real cost is usually the FX on legs that did not need converting.
FAQ
How many payments does multilateral netting leave? At most one per entity, each paying or receiving a single net amount. With n entities the gross position can need up to n(n-1) payments, so four entities go from as many as 12 to no more than 4, and in our example to 3, because the centre's own net position settles internally.
Which exchange rate should a netting cycle use? One agreed rate per cycle for every amount, normally into the netting centre's currency, fixed at the netting date. Using different rates for different entities breaks the zero-sum check, which is the fastest way to catch a conversion error.
Should customer receipts go through the netting system? Usually not. Banks may require an indemnity for redirected receipts, delays can turn into interest-free intercompany loans with withholding tax consequences, and reconciliation gets harder. Most groups net intercompany invoices and supplier payments only.
Is multilateral netting allowed in every country? No. Some jurisdictions impose exchange controls that restrict or require approval for netting, and others, like Germany, allow it but require gross reporting. Check each entity's jurisdiction with an adviser before including it in the cycle.
