More than one company

Some operations are not one business with several enterprises inside it. They are genuinely separate legal entities.

A farm and the trucking company that hauls for it. A partnership between two of the family, with a sole trade beside it.

Most accounting software treats the second entity as a second subscription with a second login. Then consolidating them is a spreadsheet somebody does once a year, under duress.

Enterprises come first

Most operations do not need a second company. They need the one company they have to stop pretending it is a single business. That is what enterprises are for.

Read that page first. This one is about having more than one legal entity.

Multiple companies

Each legal entity gets its own books. You switch between them without logging out.

Users can be given access to some companies and not others. A bookkeeper who works on two of your four entities sees only those two.

Additional companies are a flat annual fee.

Consolidation

Consolidating means one set of statements for the whole group, as though the entities were a single business. Most operations do it once a year in a spreadsheet, badly, in a hurry.

Four things have to happen for the result to mean anything.

1. The charts of accounts have to line up

Your farm entity calls it "Repairs & Maintenance." The trucking entity calls it "Shop Expense." Same line in the group statement. Two accounts in two charts.

You map each entity's account to a consolidated name once. The mapping is reused every period.

Nothing is renamed in either entity's own books. Each keeps the chart its bookkeeper knows. The mapping only governs what the group statement calls it.

2. Intercompany balances have to be eliminated

Say the farm sells $60,000 of hay to the feedlot entity.

Both sets of books are correct. The farm has $60,000 of revenue. The feedlot has $60,000 of cost. There is a receivable on one side and a payable on the other.

But the group did not sell anything. It moved hay from one shed to another.

Consolidate without eliminating and you show $60,000 of revenue that never came from outside. Plus a receivable and a payable that net to nothing.

Moab Ledger finds activity whose counterparty is another entity in the same group. It backs that out in an elimination journal.

It can do that because intercompany transactions carry the counterparty on them. Nothing is guessed from account names or memo text. The ledger finds the eliminations, not somebody's memory.

3. Profit on inventory still in the group has to come out

This is the subtle one. Spreadsheets almost always miss it.

Say the farm sells that hay to the feedlot at a $12,000 margin. At year end the feedlot still has half of it in the yard.

The farm has booked $12,000 of profit. But the group has booked profit on $6,000 of hay it still owns. That is profit on a sale to itself, sitting inside an inventory balance.

That $6,000 is unrealized. It has to come out of the inventory value and out of the group's earnings. It stays out until the hay is sold to somebody outside.

Moab Ledger tracks it per selling entity, per buying entity, per period. Then it eliminates it.

If your consolidated numbers have never had this adjustment, they have overstated group profit every year you carried intercompany stock.

4. Partial ownership has to be weighted

Not every entity is wholly owned. If you hold 60% of the trucking company, the group does not get 100% of its results.

Each member of a group carries an ownership percentage. Its figures are weighted by it. A wholly owned entity is just the 100% case of the same arithmetic, not a separate code path.

Statements that actually foot

The consolidated balance sheet and the consolidated profit and loss both come from the derived ledger. That is the same source the single-entity statements read.

That sounds like an implementation detail. It is the difference between statements that reconcile and statements that roughly agree.

Here is the common failure in consolidation tools. One statement reads stored balances. The other reads transactions. Both foot internally, so nothing looks wrong. And they quietly disagree with each other.

Here they cannot. They are the same numbers read two ways.

A group containing one entity reproduces that entity's own statements exactly. That is the test. It is worth asking any vendor to show you it.

Consolidation is included

It is not a higher tier and not an add-on. If you have more than one company you have this. You pay for the extra company, not for the ability to add it up.

Intercompany transactions

This is the other half of the problem.

Eliminations only work if the software knows which transactions were internal. And it only knows that if they were recorded as internal when they happened.

Entering it once

When one entity pays or bills another, you enter it once. You enter it on the paying or billing side, and you name the counterparty entity.

The matching entry is created in the counterparty's books. Nobody types it a second time.

That prevents the ordinary failure. The farm records the payment in March. The trucking entity records the receipt in May. They differ by a transposed digit. Nobody notices until the intercompany accounts refuse to net to zero at year end.

Direct, or into an inbox

Two delivery modes, because operations differ in how much control each bookkeeper is meant to have.

Direct — the entry appears in the counterparty's books straight away. Right when the same person keeps both sets.
Inbox — the entry arrives as a proposal. The other entity's bookkeeper reviews it and accepts it. Right when they are different people, or when one entity has an outside accountant who will not accept entries appearing unannounced.

It feeds the eliminations

The counterparty is recorded on the transaction itself. It is not inferred from an account name or a memo.

So the elimination journal comes from the ledger, not from somebody's memory of which invoices were internal.

That is why the consolidation above can be trusted. Eliminations rebuilt by hand at year end are only as good as the list somebody kept. That list is never complete.

Both entities, or neither

Creating an intercompany entry needs access to both companies. That is enforced in the core of the software, not by hiding a button.

A user with rights to one entity cannot post into another through a side door. They cannot use an intercompany transaction to reach books they were not granted.

If you use the inbox mode, the receiving bookkeeper does not need access to the sending entity either. They see the proposal, not the other company's ledger.