Designing Intercompany Accounts So They Can Be Tied Out

Every intercompany reconciliation that cannot be finished was made impossible months earlier, by somebody setting up a second company file in an afternoon and creating one account called “Due to and from related parties”. That account is where trade balances, loans, recharges and the owner’s transfers all land together, netted, in a single number. Nothing in the monthly process can recover from it, because the information needed to agree the two ledgers was never captured.

So this piece sits before the process. The intercompany checklist covers who may post, the tests an entry passes, the monthly reconciliation and what to do when the two sides disagree. All of that assumes the accounts were built so that agreement is mechanically possible. Building them that way is a one-hour decision, and it is almost always made by whoever happened to be in the software.

What netting actually costs you

Three specific things, and the third is the one that ends up in a lawyer’s hands.

A netted account cannot be agreed against anything, because the counterparty’s ledger has a different mix of the same four things and the totals only match by coincidence. You are matching a sum to a sum, and when they differ the only way forward is reading transactions.

A netted account hides direction. A trade payable of one amount and a loan receivable of the same amount net to nil, and the account reports nil, and the reader concludes there is nothing there. Two live obligations in opposite directions is not nothing.

A netted account destroys the loan record. Advances between related corporations need to be identifiable, with their movements and their history intact, because the question of what they actually are gets asked during a financing, a sale, or a year end where somebody outside the company is reading. If loans have spent four years mixed with management fees in one account, reconstructing them is archaeology, and the reconstruction is what somebody will be relying on.

The unit of design

One account, per entity, per counterparty, per bucket. That is the whole rule, and everything below is an application of it.

The three buckets are trade, loan and recharge, and the intercompany checklist explains why blending them is the error that matters. What is worth adding here is the arithmetic, because people get it wrong when a third entity arrives.

Relationships grow faster than entities. Two entities have one relationship. Three entities have three. Four have six. The formula is the number of unordered pairs, and it is the reason a group that added a property company “just to hold the building” suddenly has three reconciliations a month instead of one, and did not plan for two of them.

The design matrix

Each row is a decision made once, at setup. The right-hand column is what you are buying by making it, which is the only column anybody remembers.

Decision	The choice	What it breaks if you choose otherwise
Granularity	One account per counterparty per bucket, in each entity’s own chart	Netting. Nothing downstream recovers from it.
Counterparty identification	Encoded in the account code by a fixed offset, and spelled out in the account name	A group where “Intercompany” means a different thing in each ledger, and every export has to be interpreted before it can be matched
Code position	A reserved range per bucket, at the same offsets in every entity	A tie-out that is a hand-picked list of account codes, maintained by memory, wrong the month after somebody adds an account
Sign convention	One account per relationship and bucket, permitted to go either sign, parked on the side it normally sits	A receivable account and a payable account for the same relationship, both carrying balances, neither correct, and a settlement that splits across the two
Dimensions	Intercompany accounts carry the dimensions of the underlying cost, and dimension lists are made identical across entities before the first recharge	A recharge that arrives in the receiving entity as a single undimensioned line, so the receiving entity cannot report by department without a spreadsheet
Creation rights	Nobody creates an intercompany account outside the design. New relationship, new pair, both sides at once, recorded in the register	A second receivable account with a slightly different name, created because the first “was for something else”. This is the reliable early sign that a file is drifting.
Elimination flag	Every intercompany account sits inside the reserved range, so eliminations are a range filter	A consolidation worksheet whose elimination list is maintained separately from the chart and quietly falls behind it

The offset convention, spelled out

Give every entity in the group a two-digit number, once, in a register. Nothing in the ledger uses the entity’s own number in its own chart, because an entity never trades with itself.

Then reserve ranges by bucket. The numbers below are illustrative and fit the block scheme in the chart of accounts rebuild; what matters is that they are contiguous, reserved, and identical in every entity’s chart, not which decade they land in.

Range	Contents
1900 to 1949	Intercompany trade receivable, one per counterparty
1950 to 1999	Intercompany loan receivable, one per counterparty
2900 to 2949	Intercompany trade payable
2950 to 2999	Intercompany loan payable
4900 to 4949	Intercompany recharge and management fee revenue
4950 to 4999	Intercompany interest revenue
6900 to 6949	Intercompany recharge and management fee expense
6950 to 6999	Intercompany interest expense

Both the asset and the liability ranges exist in every entity’s chart, because different relationships sit on different sides. A given entity uses only one of the two for any one relationship and bucket, chosen at setup and recorded, which is the sign convention below.

Within a range, the last two digits are the counterparty’s number. So in any ledger in the group, 1902 means “trade receivable from entity 02”, and it means that in every ledger. A reader who has seen the register once can read any intercompany code in any of the entities without asking.

Worked across a three entity group, with 01 Holdco, 02 OpCo, 03 PropCo:

Transaction	Entity	Account	Name as it appears in that chart
Holdco charges OpCo a management fee	Holdco	4902	Intercompany recharge revenue, OpCo
The same charge, other side	OpCo	6901	Intercompany recharge expense, Holdco
The unpaid balance on that charge	Holdco	1902	Intercompany trade receivable, OpCo
The same balance, other side	OpCo	2901	Intercompany trade payable, Holdco
Holdco advances funds to PropCo	Holdco	1953	Intercompany loan receivable, PropCo
The same advance, other side	PropCo	2951	Intercompany loan payable, Holdco
OpCo pays PropCo rent, unsettled at month end	OpCo	2903	Intercompany trade payable, PropCo
The same rent, other side	PropCo	1902	Intercompany trade receivable, OpCo

Note the last two rows against the first two. The offsets differ between the two sides of a pair, and they should, because each entity names the other. Once that clicks, the whole convention becomes readable at a glance, and the reconciliation becomes a filter on a range rather than a list somebody maintains by hand.

The sign convention, which is the decision people get wrong

Here is the choice. For a given relationship and bucket, an entity can carry either one account that is allowed to swing between debit and credit, or two accounts, one receivable and one payable, with entries directed to whichever fits.

Carry one. Always one.

The two-account version is intuitive and it fails for a specific reason: a settlement or a correction has to be split between the two accounts by whoever is posting, and the split is a judgment. Two people make that judgment differently on the same facts. Within a year both accounts carry balances, the pair no longer nets against the counterparty’s single figure, and the reconciliation now has a step in it that requires reading history. Meanwhile the counterparty entity, which did the sensible thing and used one account, is looking at a number that should match and does not.

So: one account, per relationship, per bucket, in each ledger, parked in the range where the balance normally sits. If it swings the other way for a month, it swings. It gets presented on the correct side at reporting, which is a presentation step and belongs there, and it does not get a second account opened for it.

There is one honest cost to this and it is worth stating. A balance sheet drawn straight from the trial balance will occasionally show a negative in an asset range. Anyone reading management accounts should know that; anyone reading statements will see the reclassified presentation. That is a smaller problem than the one the second account creates.

Dimensions, and the thing they must not be used for

Two rules, and they point in opposite directions.

Use dimensions for the underlying cost. A recharge is a real cost in one entity being pushed to another. If the original cost carried a department, a location or a project, the recharge should carry the equivalent, and the entity receiving it should be able to reproduce the split. That only works if both entities use the same dimension list, which is a setup decision that has to happen before the first recharge is posted rather than after somebody notices the reports do not line up. Making two dimension lists identical after twelve months of divergence is a mapping exercise with a cutover, and it is not a small one.

Never use a dimension in place of the account pair. The tempting design is one intercompany account with a counterparty tag. It looks tidy, it collapses the chart, and it fails in every small-company ledger for one reason: dimensions are not enforced on manual journal entries. A journal posted with a missing tag lands in the account and disappears from the counterparty view, and nothing anywhere reports it as an exception. A missing account code cannot happen, because the system will not accept the entry.

That is the entire argument, and it is worth being blunt about it: the counterparty identity belongs in the field the system will not let you leave blank.

The pair register

One page, one row per live pair, kept with the intercompany agreements rather than in the accounting system.

Field	What goes in it
Relationship	Which two entities
Bucket	Trade, loan or recharge
Account in the first entity	Code and name
Account in the second entity	Code and name
Agreement on file	The written basis for the charge, or “none, and this is the reason”
Owner	The person who prepares the monthly agreement of this pair
Opened	When the pair was created, and by whose decision

The register is what makes the design survive turnover. A chart of accounts explains what an account is called. The register explains what it is for, which side it pairs with, and what document it rests on, and those are the three things that get lost first.

What changes when the third entity arrives

More than people expect, and the work is front-loaded.

Open the new entity’s full set of pairs against every existing entity at setup, not just against the parent. The pairs that will never be used cost nothing and can be made inactive. The pair that was not opened costs a mid-year account creation, a reconciliation with a partial-year history, and usually a few transactions that went somewhere else in the meantime.

Then decide the settlement topology before any money moves, because it is a structural choice and not an operational one. Route everything through the parent, so the operating companies settle with the parent rather than with each other, and the number of live relationships stays small as the group grows. The alternative, bilateral settlement, is defensible in a group where two operating entities genuinely trade with each other at volume, and it means every new entity adds a relationship with every existing one.

The hub only works if the parent is willing to be a party to transactions it has no operational involvement in, and that has consequences beyond bookkeeping. Which is the right point to say what this design does not decide.

Two questions this design does not answer, and must not

Whether a given movement is a loan, a recharge or a contribution of capital. The design gives you three buckets and requires you to pick one. It does not tell you which. That determination changes both sets of statements and the equity position, and it belongs to the owner with whoever reports on your statements in the room. Get it decided once and write it into the agreement file, so the next one is not re-argued.

Whether a charge between the entities attracts sales tax. Separate corporations are separate parties, the treatment depends on facts about your specific entities, and there are elections that may or may not apply to your group. This is a question for your accountant, settled once, applied identically every month afterwards. The account structure is neutral on it and cannot be made to imply an answer.

Retrofitting a group that already has one netted account

You can fix the structure going forward cleanly. You can fix the history partially, and you should be honest with yourself about which is which.

Treat it as a chart of accounts migration, with a mapping table written and proved before anything is changed. The method and the two proofs are in the rebuild walkthrough, and the intercompany version has one additional constraint: the split has to be made identically in both entities, at the same date, or you have replaced one unreconcilable account with two unreconcilable ones.

What you can usually recover is the loan balance, because transfers between bank accounts are identifiable from the bank side even when the coding was wrong. What you usually cannot recover is the trade and recharge split from years where no invoice was raised between the entities. Where the split is genuinely unrecoverable, map the whole historical balance to the loan account, state that you have done so, and start the three-way split from the migration date forward. That leaves a comparative that is coarser than the current year and true, which is the right trade. The alternative is an allocation somebody estimated, presented as though it were a record.

Then run the first consolidation on the new structure with the pair register open. If the eliminations can be selected by range and every pair nets, the design is done and the monthly process has something to stand on.