# Bookkeeping for Multi Entity Clients Without Mix-Ups

- Author: AutoBankConvert (https://www.autobankconvert.com)
- Published: 2025-12-23
- Updated: 2025-12-23
- Category: Client work
- Canonical: https://www.autobankconvert.com/blog/bookkeeping-for-multi-entity-clients

> Bookkeeping for multi entity clients: separate books per entity, intercompany transfers, shared expenses and a close order that keeps each entity correct.
Bookkeeping for multi entity clients starts with one set of books per entity and a clear owner for every bank account. Money moving between entities is booked as an intercompany balance on both sides, shared expenses are split by a written method, and the entity that pays shared bills closes first, so each entity's books stay correct.

## Separate books for each entity of a multi entity client

Each entity of a multi entity client needs its own set of books, bank accounts and reconciliations. An entity here means a separate legal business, such as an LLC or a corporation, even when one owner runs several. Combining them in one file, with classes or tags to tell them apart, makes every later step harder.

The reason is practical. Each entity may have its own lender, landlord, investor or tax filing that asks for its own statements. If the books are mixed, every report has to be untangled first. Separate books keep each entity's balance sheet honest, which tags inside a shared file cannot fully do.

### Mapping accounts to entities

Before any transaction is booked, write down which bank and card accounts belong to which entity. The legal owner of the account, as printed on the statement header, decides it, not which business the owner thinks of it as.

| Account (example) | Name on statement | Entity |
| --- | --- | --- |
| Checking ending 2210 | Pine Street Holdings LLC | Holdings |
| Checking ending 5581 | Pine Street Cafe LLC | Cafe |
| Card ending 0934 | Pine Street Cafe LLC | Cafe |
| Checking ending 7702 | Pine Street Catering LLC | Catering |

Keep this map in the client's notes and check it whenever a new statement arrives with an account number you have not seen. A new account is the most common way a mix-up starts.

## Recording intercompany transfers between a client's entities

An intercompany transfer is money that moves from one of the client's entities to another. It is not income for the receiver or an expense for the sender. Book it as a balance owed between the two: a "due from" asset on the sending entity's books and a matching "due to" liability on the receiving entity's books.

### A worked transfer

Here is an example with three fictional entities owned by one person. The figures are illustrative.

On March 5, Holdings sends 10,000.00 to Cafe to cover a slow month.

| Books | Account | Debit | Credit |
| --- | --- | --- | --- |
| Holdings | Due from Cafe | 10,000.00 | |
| Holdings | Checking 2210 | | 10,000.00 |
| Cafe | Checking 5581 | 10,000.00 | |
| Cafe | Due to Holdings | | 10,000.00 |

Both entities record the same date and the same amount. The statements show it too: a withdrawal on the Holdings statement and a deposit on the Cafe statement. If one side is booked and the other is not, the intercompany accounts stop matching, which is the check in a later section.

Whether a transfer should be a loan, a capital contribution or something else is a question for the client's CPA. The bookkeeper's job is to book it consistently on both sides and to ask when the client's intent is not clear.

## How should shared expenses be split across entities?

Shared expenses should be split by a written method the client and their CPA agree to, such as floor space for rent or headcount for software seats. The entity that pays the bill records the whole cost, then charges the other entities their share through intercompany accounts. Apply the same method every month.

### A worked shared rent bill

Continuing the example: Holdings pays the building's rent of 6,000.00 each month. The agreed split is by floor space: 50% Cafe, 30% Catering and 20% Holdings.

| Entity | Share | Amount |
| --- | --- | --- |
| Cafe | 50% | 3,000.00 |
| Catering | 30% | 1,800.00 |
| Holdings | 20% | 1,200.00 |

Holdings books its own 1,200.00 as rent expense and the other 4,800.00 as due from Cafe (3,000.00) and due from Catering (1,800.00). Cafe and Catering each book their share as rent expense with a matching due to Holdings.

Write the method down with the date it started, and keep the calculation in the workpapers each month. If the floor space changes, change the split from that date forward. Without the written method, every review turns into a debate about why one month looks different.

## A close order for multi entity bookkeeping

Close the entity that pays the shared bills and sends the transfers first, then the entities that receive them. In the example, Holdings closes first, because its books decide the intercompany charges the others must book. Closing in the opposite order means reopening the receivers once the payer's charges are final.

An example close order:

1. **Holdings.** Reconcile its accounts, book all transfers out and the shared cost allocations.
2. **Cafe and Catering.** Reconcile each, then book the matching sides of every transfer and allocation from Holdings.
3. **Intercompany check.** Compare the due-to and due-from balances across all three.
4. **Review and sign-off** for each entity separately.

Process each entity's statements in its own place. AutoBankConvert gives every client workspace its own accounts, rules and history, and setting up each entity as its own workspace keeps one entity's coding rules from touching another's books. The balance check on each statement then confirms every entity's lines are complete before the intercompany step.

A multi entity client counts as several clients when you plan capacity. Each entity has its own close, review and questions, so pricing and scheduling should reflect that. The guide to [scaling a bookkeeping practice](/blog/how-to-scale-a-bookkeeping-practice) discusses how work like this changes what your practice can take on.

## Do intercompany balances need to match every month?

Intercompany balances should match every month: each entity's "due from" another entity must equal that entity's "due to" in return. If Holdings shows 13,000.00 due from Cafe, Cafe must show 13,000.00 due to Holdings. A mismatch means a transfer or allocation was booked on one side only.

Build a small matching table into the monthly workpapers:

| Pair (example) | Holdings shows | Other entity shows | Difference |
| --- | --- | --- | --- |
| Holdings and Cafe | 13,000.00 due from | 13,000.00 due to | 0.00 |
| Holdings and Catering | 1,800.00 due from | 1,800.00 due to | 0.00 |

The March figures come from the worked example: 10,000.00 transfer plus 3,000.00 rent share for Cafe, and 1,800.00 rent share for Catering. When a difference appears, look first for a transfer dated at month end, which can post on one entity's statement a day after the other's. Then look for an allocation booked on the payer's side but not the receiver's.

Clear differences before sign-off, not at year end. A year of small mismatches is slow to untangle, and it is often what turns into a cleanup project. The [bookkeeping cleanup checklist](/blog/bookkeeping-cleanup-checklist) helps if you inherit a client whose intercompany accounts were never matched. Add the matching table to your firm's review steps so it is checked by a second person, as part of a [bookkeeping quality control process](/blog/bookkeeping-quality-control-process).

## Owners who pay one entity's bills from another entity's account

The most common multi entity mix-up is an owner paying one entity's bill from another entity's account, such as a catering supplier paid from the cafe's card. The fix is to book the expense in the entity it belongs to, and record the payment as an intercompany balance between the two.

In the example, if Cafe's card pays a 420.00 Catering supplier invoice:

- Cafe books 420.00 as due from Catering, not as an expense.
- Catering books 420.00 as supplier expense and 420.00 as due to Cafe.

Flag these payments to the client each month. Occasional ones are normal. A steady pattern usually means the owner is using whichever card is in their wallet, and a short conversation about which card belongs to which business saves you hours. If the client keeps doing it, write a vendor rule for that supplier on Cafe's books that sends every line to the intercompany account, so it does not land in Cafe's expenses by default.

## When a multi entity client adds or closes an entity

When a multi entity client adds an entity, set up its books, accounts map and intercompany accounts before the first transaction, and add it to the close order. When an entity closes, settle or move its intercompany balances, close its accounts, and keep its records until the CPA confirms the final return.

Changes in structure are also when allocation methods change. A new entity that shares the building needs a share of rent, which changes everyone else's share from that month. Update the written method and date it.

### Setting up a new entity, step by step

1. Confirm the new entity's legal name and the accounts opened in that name.
2. Create its books with a chart of accounts that matches the sister entities where the activity is the same.
3. Add a due-to and due-from account for each entity it will trade with, on both sides.
4. Add its accounts to the client's account map, with the date each one opened.
5. Place it in the close order, after any entity that pays its bills.

Opening balances matter too. If the owner funded the new entity from another entity's account, that first deposit touches two sets of books. Book it on both sides the same way, and ask the CPA how it should be classified, or the pair is out of step from day one.

Structure changes sometimes come with a sale. If one of the client's entities is sold, the buyer will want clean, separate books for it, with every intercompany balance explained. The same discipline applies when a bookkeeper sells their own practice, as [selling a bookkeeping practice](/blog/selling-a-bookkeeping-practice) explains: separate, documented records make the handover simpler. When you want to see how a separate workspace per entity would look for your own clients, [request early access to AutoBankConvert](/get-started).