Intercompany Settlement Automation, Explained

If your entities do business with each other, someone in your organization keeps a schedule. It lists what Entity A owes Entity B, what B owes C, what the management company charged everyone, and which of those balances have actually been paid. That schedule is usually a spreadsheet, it is usually stale, and it is usually the reason month-end close takes three days longer than it should.

Intercompany settlement automation is the practice of retiring that spreadsheet. This guide covers what settlement actually involves, how netting works, why settlement and elimination are different jobs, and how the available approaches compare when you evaluate them honestly.

What Intercompany Settlement Automation Actually Means

“Settlement” in an intercompany context means clearing the balances that group entities carry against each other. Automating it means the system, not a person, handles four steps:

1. Capture both sides. Every intercompany invoice, fee, allocation, loan draw, or transfer creates a receivable in one entity and a payable in another. Both need to exist, with the same amount, date, and coding.
2. Keep the pair agreed. For a same-currency transaction with no later adjustments, the due-from balance in Entity A must equal the due-to balance in Entity B at every point in time, not just after someone reconciles them. Where the two entities have different functional currencies, the balances will legitimately differ once each side is remeasured, so those pairs need FX analysis rather than a simple match.
3. Calculate the net position. Rather than settling every invoice individually, reduce each entity pair (or the whole group) to a single net amount.
4. Record the clearing. When cash moves, or when balances are offset against each other, the settlement posts against the correct intercompany accounts on both sides.

Only step 4 involves money leaving a bank account. Steps 1 through 3 are pure bookkeeping discipline, and they are where nearly all intercompany pain originates. Groups that never settle in cash at all, common in holding-company structures where balances simply accumulate, still need steps 1 through 3 to close their books.

Settlement vs. Eliminations: The Distinction That Matters

These two terms get used interchangeably, and they should not be.

An entity can be fully settled and still require elimination, because settlement moves cash between two group members while the underlying revenue and expense still exist in both sets of books. Equally, a balance can be eliminated in consolidation and remain unsettled indefinitely at the entity level. If you only eliminate, the standalone books drift toward large unexplained intercompany balances. If you only settle, consolidated revenue and expense stay grossed up: paying the balance clears the reciprocal receivable and payable, but the internal sale still sits in one entity’s revenue and the other’s cost. Consolidated assets are a separate question. Settlement itself does not overstate them, but unrealized intercompany profit does, when goods sold between entities are still held in inventory, or profit has been capitalized into a fixed asset, and nothing has yet been sold outside the group.

Both jobs need the same input: two sides of every transaction that agree. For the mechanics of the elimination side, with journal entries for sales, loans, balances, and unrealized profit, read inter-company eliminations explained.

The Due-To / Due-From Ledger

Everything in settlement automation rests on the intercompany control accounts, usually named “Due from [Entity]” (an asset) and “Due to [Entity]” (a liability). A well-run group keeps one pair of these accounts per counterparty entity, not a single lumped “Intercompany” account.

Why per-counterparty matters: with one combined account, a group of six entities produces a balance that nets fifteen possible relationships into a single number. When it does not agree, you have no starting point. With per-counterparty accounts, a break is immediately attributable to one pair.

A healthy due-to/due-from ledger has three properties:

• Mirrored. Within a single currency, and absent later adjustments on one side, A’s due-from equals B’s due-to. A discrepancy report should make an exception visible the day it appears.
• Attributable. Every balance traces back to source documents: an invoice, an allocation, a loan agreement, a transfer.
• Aged. Intercompany balances have age just like external AR. A due-from that has sat untouched for two years is a signal, whether about a settlement that never happened or a transaction that should have been equity.

The cross-currency exception. If two entities have different functional currencies, the two sides of the same balance will not match in reported terms, and that difference is legitimate rather than an error. The side holding a balance denominated in a currency other than its own functional currency remeasures it at the reporting date, and that movement generally lands in transaction gain or loss on its income statement; the side whose functional currency matches the balance does not remeasure at all. One exception: an intercompany balance that is of a long-term-investment nature, with no settlement planned or anticipated, takes its FX effect to the cumulative translation adjustment in equity instead of income. Those pairs need a separate analysis that reconciles the balance in the transaction currency first, then explains the remainder as FX. Treat “mirrored” as the rule for same-currency pairs and “reconciled in transaction currency, with FX explained” as the rule for the rest.

Netting: Bilateral vs. Multilateral

Netting is the part of settlement that reduces how much cash actually moves. There are two forms.

Bilateral netting

Two entities offset what they owe each other and settle the difference.

Suppose over a quarter:

• Entity A invoiced Entity B $80,000 in management fees
• Entity B invoiced Entity A $52,000 for shared warehouse space

Gross, that is $132,000 of payments. Bilaterally netted, Entity B pays Entity A $28,000. One transfer instead of many, and the intercompany accounts on both sides clear to zero.

Multilateral netting

Every entity’s position against the whole group is reduced to a single net amount, typically settled through a central entity acting as the netting center (often the parent or a treasury entity).

Gross settlement would move $146,000 across many transfers. Multilateral netting moves $78,000 in three payments into the netting center, which then holds a zero net position across the group. The reduction in payment count matters more than the dollar reduction for most small groups: fewer transfers means fewer bank fees, fewer reconciliation items, and fewer chances to key an amount wrong.

Intercompany Loan Automation

Loans between group members are the balances most likely to be mismanaged, because they are long-lived and interest keeps accruing whether anyone is watching or not.

What an automated approach should cover:

• Linked principal. The lender’s loan receivable and the borrower’s loan payable originate from one record, so a draw or repayment updates both.
• Interest on both sides. Interest income in the lender and interest expense in the borrower, recognized in the same period at the same amount.
• A repayment schedule that keeps principal and interest separated rather than lumping payments into one intercompany account.
• Clean elimination. Both the loan balance and the interest disappear in consolidation, since a group cannot lend to or earn interest from itself.

The failure mode here is subtle. A loan booked years ago accrues interest on the lender’s books that nobody ever recorded on the borrower’s side. The balances diverge slowly, the consolidated balance sheet stops tying, and by the time an auditor asks, the original agreement is hard to locate. Automating the linkage is what prevents a small annual drift from compounding.

An Evaluation Checklist

When you assess any tool against the settlement and eliminations workflow, work through these in a live demo rather than from a feature matrix.

1. Record once, both sides post. Enter an intercompany invoice from either entity. Does the counterparty entry appear automatically, linked to the original? If you have to key the second side, nothing downstream is truly automated.
2. Per-counterparty due-to/due-from. Are intercompany control accounts maintained per entity pair, or lumped together?
3. A live intercompany balance report. Can you see every pair’s position across the group at any moment, with discrepancy detection that flags a mismatch?
4. Eliminations without journal entries. Run a consolidated P&L and balance sheet. Do intercompany revenue and expense, receivables and payables, and loan balances drop out with no manual adjustment posted?
5. Loans with interest. Book an intercompany loan with interest, then consolidate. Both the principal and the interest should vanish from the group numbers.
6. Standalone books stay intact. Confirm eliminations never touch the entities’ own ledgers. Each entity’s standalone statements must remain complete for lenders and tax.
7. Audit trail across entities. Every linked entry and every elimination should be timestamped and traceable in both directions.
8. Currency handling. If entities transact across currencies, ask specifically how FX gain and loss on intercompany balances is calculated and where it lands. This is a common gap; verify it rather than assuming it.
9. Pricing at your real entity count. Multiply per-entity pricing by the entities you have plus the ones you will add in three years.
10. Adding an entity. Ask what happens operationally when entity 11 arrives. If it means a new subscription, a new file, and remapped elimination rules, that cost recurs every time you grow.

How the Approaches Compare

Spreadsheets are honest about what they are: a schedule maintained by a person. They work at two or three entities with a handful of monthly transactions, and they fail predictably as volume grows, because every entry is an opportunity for the two sides to disagree.

QuickBooks and Xero are strong single-entity products. Neither links the two sides of an intercompany transaction across company files, and neither eliminates natively, so the settlement schedule and elimination workpaper both remain manual. See the intercompany accounting software buyer’s guide for the full cost comparison.

Enterprise ERPs genuinely solve this. NetSuite’s elimination-subsidiary model, Sage Intacct, and Dynamics 365 Finance all post counterparty entries automatically and apply eliminations by rule, and the larger platforms add treasury features like multilateral netting runs. The honest trade-off is cost and implementation: these are projects, not signups, and pricing generally scales with entities and users.

Purpose-built multi-entity platforms target the middle: groups with real intercompany activity that do not need an ERP implementation.

Where EmLedger Fits

EmLedger is multi-entity accounting software, so intercompany activity is a native concept rather than a workaround. Specifically:

• Record once, both sides post. Enter an intercompany invoice, fee, shared bill, or loan from either entity and EmLedger creates the linked entry on the other side. The receivable and payable come from the same record, so a same-currency pair cannot drift apart through a mis-keyed or missing second side. This is the foundation everything else depends on. See inter-company transactions.
• Balances you can see. An intercompany balance report shows every pair’s position across entities with discrepancy detection, which is what makes netting possible: you cannot net positions you cannot see.
• Automatic elimination. Running consolidated reports removes intercompany revenue and expense, receivables and payables, and loan balances with no manual adjustment entries.
• Loans handled on both sides. The lending entity records a receivable, the borrowing entity records a payable, interest accruals can be automated, and the whole position eliminates in consolidation.
• Standalone books stay standalone. Each entity keeps its own chart of accounts and its own statements through entity management, and you switch between entities in a click.
• Pricing by capacity, not per entity. One entity on Solo at $29/month, up to 3 on Starter at $49/month, up to 10 on Growth at $99/month, up to 25 on Scale at $199/month, and a custom Enterprise tier above that. There is no per-entity surcharge inside a tier: adding an entity never adds a subscription, and the price only changes if you cross into the next tier, in predictable steps rather than on a per-entity meter.

Being precise about scope: EmLedger’s strength is that both sides of an intercompany transaction are booked in one system without switching company files, and that eliminations follow from that automatically. It is not a treasury workstation. It gives you the net position for each entity pair and records the settlement when you make it; it does not run bank payment files or automate cross-currency settlement. If your group needs multilateral netting executed through a treasury platform, that is a separate system, and any vendor telling you otherwise deserves a demo question.

Putting It Into Practice

If you are cleaning up an existing intercompany mess, work in this order:

1. Inventory the relationships. List every pair of entities that transacts, and the transaction types between them: fees, shared costs, loans, transfers, inventory. This list is both your evaluation checklist and your chart-of-accounts plan.
2. Split the control accounts. Replace any lumped intercompany account with per-counterparty due-to/due-from accounts. Painful once, valuable forever.
3. Reconcile to a clean starting point. Agree every pair as of one date. Where balances cannot be substantiated, decide deliberately whether the difference is a correction, a write-off, or a capital contribution, and document the decision.
4. Set a settlement cadence. Monthly or quarterly, netted per pair, with a named owner. Unsettled balances that accumulate for years become their own problem.
5. Move the linkage to the system. From the cutover date forward, every intercompany transaction should post both sides from one entry. That is the change that stops the schedule from rebuilding itself.

The end state is a close where same-currency intercompany balances agree by construction, any remaining difference has a named cause such as FX remeasurement, settlement is a decision rather than an investigation, and consolidation is a report you run instead of a workpaper you rebuild.

Next: read inter-company eliminations explained for the journal-entry mechanics, the intercompany accounting software buyer’s guide for a full options comparison, or how to consolidate financial statements across subsidiaries for the whole close. You can estimate your own group’s cost with the multi-entity savings calculator.