--- title: "Intercompany settlement automation: from matching to netting" description: "Reconciling intercompany balances is only half the job. Settlement, where entities actually pay each other, is where timing, currency and ownership problems surface." author: "Maren Calloway" category: "Enterprise Solutions" date: 2026-10-27T06:05:48.955Z canonical: "https://tasksheriff.com/blog/intercompany-settlement-automation" --- # Intercompany settlement automation: from matching to netting ![Photo of a desk with a laptop, financial documents and a calculator in an office setting.](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/39b6f926-5a52-4bf1-99e0-a3cf4d8c6ff8/d99af9bb-3fab-433f-b66e-a730a239eb4f/7a98c09d-0c47-4b5c-8472-7e79347e0226.jpg) > Reconciling intercompany balances is only half the job. Settlement, where entities actually pay each other, is where timing, currency and ownership problems surface. Say two subsidiaries book the same management fee. One records it in euros on the fifth. The other records the dollar equivalent on the tenth. At close, the balances differ, nobody knows which is right, and the settlement payment waits. That small difference is typical of intercompany work. The arithmetic is easy. The coordination is not. ## Reconciliation is not settlement Reconciliation asks whether two entities agree on what is owed. Settlement asks how the debt is paid: in which currency, by which payment, on which date, and net or gross. Teams often automate the first and leave the second to email. The result is a clean match report followed by days of manual follow-up. Closing the loop means treating both as one cycle. ## Where intercompany breaks ### Ownership Who initiates a charge? If both sides can create it, you get duplicates. If neither does, you get gaps. A single initiating entity per transaction type solves the largest share of problems before any software is involved. ### Timing Entities book on different days, with different cut-offs. A charge raised on the last day may land in the next period on the other side. Match through the month, not at the end, so timing differences appear while they can be fixed. ### Currency Each side may translate at a different rate or on a different date. Agree on one rate source and one rate date per transaction type, and record both on the entry. Differences left over after that are real exchange effects, which belong in a separate account. ### Coding Counterparty accounts are easy to mis-select when entities share a chart. Wrong counterparty coding creates balances that cannot match no matter how good the matching logic is. ## What an agentic approach adds Matching intercompany is a good job for an agent that works continuously. It reads both sides, proposes pairs, and classifies breaks: timing, currency, one-sided booking, amount difference. It sends each break to the entity that owns the fix, with both entries attached. A person still decides what to do about a disputed amount and approves any adjustment. The agent shortens the path to that decision, so the discussion starts from evidence. ## Netting When entities trade both ways, paying every invoice gross creates many small payments, bank fees and currency conversions. Netting offsets the balances and settles the difference. The basic idea is described under [netting](https://en.wikipedia.org/wiki/Netting) in general references, and treasury teams often run it as a scheduled cycle. The cycle can be simple: - Freeze the balances at a cut-off date, matched and agreed. - Compute the net position for each pair of entities, or for the group. - Generate the settlement instruction for each net payer. - Post the settlement entries on both sides on the value date. - Carry forward any disputed items to the next cycle, and record why. Automation fits steps two to four well. Step one depends on clean matching, and step five depends on people who own disputes. Local rules may restrict netting or require specific documentation in some jurisdictions. Confirm with your tax and legal advisers before you design a cycle, since we do not give that advice. ## Controls to keep - A limit on settlement amount per cycle, with named approvers above it. - Separation between the person who agrees balances and the person who releases payment. - A locked cut-off, so entries cannot slip into a frozen balance. - A log of each step with the identity that acted, human or software. ## How to start Do not start with the technology. List your intercompany transaction types and, for each, write the initiating entity, the booking date rule, the currency rule and the settlement method. Most groups discover that two or three types account for most of the pain. Fix the rules for those types, then automate matching on them. Add the netting cycle once matching holds for two consecutive closes. Sequence matters here: a netting run built on unreliable balances automates the wrong payments. Settlement only works as well as the matching beneath it, and this walkthrough of intercompany matching and reconciliation in SAP S/4HANA covers that groundwork clearly. It's a useful reference if your entities run on SAP or you're weighing how a modern ERP handles the reconciliation step before payments are triggered. Treat it as the first half of the story, then return here for what happens once the balances agree and money has to move. --- Source: https://tasksheriff.com/blog/intercompany-settlement-automation