Intercompany Discipline: Keeping Two Ledgers in Agreement

Intercompany balances do not break at consolidation. They break on a Tuesday, when somebody pays a supplier from the operating company’s card because that is the card in their wallet, codes the expense where it looks like it belongs, and moves on. A handful of those over a few months, and the two ledgers disagree by an amount nobody can explain without reading months of bank statements. The disagreement itself is cheap. The archaeology is what costs.

So the whole of intercompany control is preventative, it takes a few minutes a week, and it is genuinely boring. That is worth saying plainly rather than dressing it up, because the work is easy and it still does not get done. Nothing bad happens on the day you skip it. The consequence arrives a quarter later, attached to somebody else’s deadline, usually a lender’s.

What follows is the rule set that goes into a two-entity or three-entity file. The arithmetic at the other end, the eliminations and the worksheet, is a separate exercise covered in the consolidation walkthrough. This piece is the eleven months before it.

How intercompany balances actually break

Not evenly. One of these accounts for most of the damage in most files, and it is the least interesting one.

Origin	What it looks like in the ledger	When you find out
The wrong card, the wrong bank account	An ordinary expense in the ordinary expense account of the entity that paid, with nothing anywhere marking it as belonging to the other entity	Never, on its own. It surfaces as an unexplainable margin difference between the two entities.
A recharge nobody documented	A management fee, a rent allocation or a shared salary charge posted because someone said it should be, with no agreement, no stated basis and no rate	At a review engagement, or when a lender asks why one entity’s overhead moved
A loan one side never booked	A transfer out of one entity’s bank sitting in that entity’s intercompany loan account, and nothing at all in the other’s	At consolidation, as an exact one-sided balance
The one-sided correction	Somebody fixed an intercompany entry in one ledger and did not fix the other. The correction is right. It is right in one place.	Next reconciliation, if there is one
A settlement posted net	The two entities cleared a mixture of trade and loan balances with one transfer, and both sides posted the net figure to whichever account was closest	At year end, when the loan balance is wrong and the trade balance is wrong and the total is right

The first row is the majority of the problem and it is the one that gets the least attention, because it does not look like an intercompany transaction. It looks like an expense. Nothing in the entry is wrong on its face, which is exactly why nobody catches it. The last row is the one that fools experienced people, because the total agrees, and a total that agrees stops most reviews.

Who may create one

Short list, and shorter than instinct suggests.

One person posts both sides. In a company this size that person is normally the bookkeeper, and it is deliberate. Everywhere else in a finance function you separate the person who prepares from the person who blesses. Intercompany is the exception, and the reason is that the failure mode here is not theft, it is divergence. Two competent people posting one side each, from the same conversation, will describe it differently, date it differently and eventually round it differently. A single author writing both sides from one source document produces two entries that match because they were typed in the same minute.

The control that replaces segregation is review, not preparation. Somebody other than the preparer reads the intercompany transaction listing at close, in full, every month. It is a short listing in a company this size. If it is not short, that is itself the finding.

Everybody else raises a request. Nobody outside that role posts to an intercompany account directly, including the owner, and including for something obviously correct. The system permission should enforce it rather than the policy, because a policy that depends on people remembering which accounts are special is a policy that lasts about one busy month.

Nobody creates a new intercompany account. The account structure is fixed when the second entity is set up, in matched pairs across the two ledgers, and it changes by decision rather than by convenience. The most reliable early warning that a file is drifting is a second receivable account with a slightly different name, created because the first one “was for something else”.

The tests an entry has to pass before it goes in

Run these in order. Most entries clear all of them in under a minute. The ones that do not are the ones worth the time.

1. Which entity carries the obligation? Not which entity paid, and not which entity has cash. The entity named on the contract, the invoice or the lease owes the money. If the answer is genuinely unclear, the transaction is not ready to post and it goes to the request queue, not to a guess.

2. What is the document? An invoice between the entities, a signed agreement, a lease, a loan agreement, or a written allocation schedule with a stated basis. A verbal instruction is not a document. A spreadsheet with no date and no author is not a document either, and it is the most common thing offered when someone is asked for one.

3. Which of the three buckets? Trade, loan, or recharge. Every intercompany transaction is exactly one of these and it goes to the account pair for that bucket. Never a bucket it resembles, never the bucket with the convenient balance. This test does more work than it looks like, because the three behave completely differently: trade settles, loans accrue interest and carry terms, and recharges hit both income statements. Blending them is how a company ends up unable to say whether the parent is owed money or has invested money, which is a question with consequences well beyond the reporting.

4. Is the counterparty named in the entry? The description says which entity, which document and which period. “IC” is not a description. Six months later the description is the only evidence of what the entry was for, and a reconciliation is a matching exercise, so the two sides need a shared reference string that a filter can find.

5. Is the other side going in today? Same date, same reference, same amount, before the file is closed. Not this week. An intercompany entry that exists on one side overnight is a difference that will be discovered by somebody else, in a state where it looks like an error rather than a queue.

6. Does this charge attract sales tax? Two separate corporations charging each other are two separate parties, and the treatment depends on facts about the entities and on elections that may or may not apply to your group. Settle it once with whoever reports on your statements, write the answer into the intercompany agreement file, and apply the same answer every month. What you are avoiding is not a wrong answer. It is twelve inconsistent answers, which is far more expensive to unpick than one wrong one applied consistently.

The monthly reconciliation, step by step

This runs on the reconciliation day of the close, before any judgment entries are posted, because every accrual made on top of an unreconciled intercompany balance has to be redone if the balance moves. It is one page and it takes about twenty minutes once the habit exists.

Step	What you look at	What a wrong answer looks like
1. Export both trial balances	Two exports, same date, same basis, saved to the close binder	Two screens open side by side. Screens cannot be filed, and half the differences found this way are transcription.
2. Net each pair	Each matched pair of accounts, summed across the two ledgers	Anything other than nil. Note the sign: a receivable and a receivable is two entities each thinking they are owed, which is a classification error, not a difference.
3. Match the detail anyway	The transaction listing on both sides, matched by reference, and the entry count on each side	Equal balances with unequal entry counts. Two offsetting errors net to nil, and a reconciliation that stops at the total will pass that file every month until year end.
4. Age what did not match	Every unmatched item, with a date and an owner	An item older than one close. A one-period timing difference is normal. The same item present three months running is an unresolved transaction that has been renamed.
5. Check the income statement pairs	Recharge revenue in one entity against recharge expense in the other, for the period and year to date	A balance sheet that agrees while the income statements do not. This usually means one side recognised a recharge and the other capitalised it or coded it to a different expense line.
6. Sign and file	One page: the two balances, the netting, the unmatched list, the name of who prepared it and who reviewed it	An unsigned reconciliation. It is the same document with none of the value, because the point of a reconciliation is that a specific person asserted it.

Two things this deliberately does not allow.

No plug. A difference is never cleared to an expense account because it is small. That entry destroys the only evidence of what went wrong while leaving the error in place, and it teaches the file that differences are absorbable, which guarantees a larger one next quarter. If a residual genuinely cannot be identified after the work is done, it is written off with the amount and the reason stated in the file, and it is reported, not buried.

No rolling. An unmatched item does not carry to next month with the words “same as last month” beside it. It carries with a name, a date and what has been done about it since.

When the two sides genuinely disagree

Most differences are not disagreements. They are one side missing. Real disagreements come in four kinds and they escalate in seriousness fast.

The disagreement	Who decides	How it ends
Timing. Both sides agree the charge exists, they booked it in different periods.	Nobody. It is arithmetic.	The later side posts it in the correct period, and the reconciliation notes it as a timing item for one close only.
Amount. The charge is real, the allocation basis is being argued.	The written agreement, not the argument.	Apply the agreement as written for the period being closed. If the basis in it is genuinely wrong, amend the agreement prospectively and say so. Retroactively restating a recharge because a new basis is more flattering is a decision somebody outside the company will eventually read.
Existence. One side says a charge was made, the other has no record and no document.	The document.	No document, no charge. Reverse it. This is the ruling that generates the most friction and it is the one to hold, because the alternative is a ledger where a charge exists because somebody remembers it.
Classification. Both sides agree money moved, they disagree on whether it was a loan, a recharge or a contribution of capital.	Not the bookkeeper, and not by default.	Escalate. This one changes both sets of statements, it changes the equity position, and it has consequences outside financial reporting. Get it decided by the owner with the practitioner in the room, then write it into the intercompany agreement file so the next one is not re-argued.

Name the tie-breaker before you need it. One ledger is the reference copy for intercompany, normally the parent’s, and when a difference cannot be resolved on the day, the reference copy stands and the other side moves. The reference copy is not chosen for being more accurate. It is chosen so that a close can finish, and the rule works only because the unresolved item stays on the list with an owner until it is properly settled.

The classification row is the one to watch over years rather than months. Advances between related corporations, left undocumented and unrepaid, gradually stop resembling loans, and the question of what they actually are is not one you want asked for the first time during a transaction or a financing. If your group has balances like that sitting there from before anyone was paying attention, that is a conversation to have deliberately, once, rather than a line to keep rolling forward.

The transactions nobody codes as intercompany

These are the ones that never enter the intercompany accounts at all, which is why the reconciliation above cannot catch them. Sweep for them at least quarterly.

• One card, two entities. A single corporate card used for both. Either issue a card per entity, which is the real fix, or accept a monthly split with a documented basis and post it as a recharge. There is no third option that survives a year.
• Payroll for a person who works for both. One employment relationship, one payroll, and a recharge for the other entity’s share on a basis that is written down. The basis is usually time, and usually nobody wrote it down.
• Insurance, software and professional fees bought once for the group. Almost always sitting entirely in whichever entity happened to sign. Whether they should be split is a decision. Not making the decision is also a decision, and it is the one that gets questioned.
• A lease in one entity’s name, occupied by both. Same treatment, higher amounts, and the one most likely to be raised by an outside reader.
• A customer who paid the wrong entity. The receipt is in the wrong bank account and the receivable is in the other ledger. This is an intercompany balance whether or not anyone recorded it as one.
• The owner moving money between accounts. Frequently, informally, and often without telling anyone. Every one of these is either a loan movement or a distribution, and until somebody decides which, it is neither, in both ledgers at once. The decision reaches past the ledger, because a balance owed by a shareholder carries its own repayment clock.

What this costs to run

A few minutes when an entry is created, twenty minutes at close, and a quarterly sweep. Against that, the version without it: a year end where somebody bills for the archaeology, a set of statements that took an extra month, and a lender who now knows the finance function cannot answer a straightforward question about its own group.

What we do not do is build an elaborate intercompany process for a group that has one loan and one management fee. Two account pairs, a one-page monthly reconciliation and a signed agreement is the entire control set at that size, and adding to it produces a procedure that gets abandoned rather than a file that gets better. The rules above scale up. They are not meant to be applied at full weight to a group that does not need them.