One business, several entities: the multi-company invoicing problem
Almost nobody sets out to run three companies. It happens gradually — a second brand, a property entity, a partnership that needed its own books. Then invoicing quietly becomes the hardest admin job in the business.
Ask most owners of a multi-entity business how their invoicing works and you'll get a slightly embarrassed answer. There's a spreadsheet per company. Or one accounting login per company, each with its own subscription. Or — very often — one system for the entity that does most of the trading, and "we just do the others manually."
None of that is carelessness. It's what happens when a structure that made sense legally gets handed to tools that assume you are one company.
Why one business becomes several
The reasons are boringly sensible, which is why this is so common:
- Risk separation — keeping a property or an asset-holding entity away from a trading entity that carries operational risk.
- Different partners. A venture with a co-owner needs its own books, because the profit split doesn't apply to the rest of the business.
- A distinct brand. The new line of business shouldn't invoice under a name customers don't recognise.
- Tax and VAT structure. One entity may be VAT-registered while another sits below the threshold — which changes what every invoice must show.
Perfectly rational, all of it. And each one adds a set of invoicing rules that must not leak into the others.
Where it actually breaks
Numbering collisions
Every entity needs its own unbroken invoice sequence. The moment two entities can both produce an "INV-001", reconciliation gets strange and your accountant gets unhappy — especially if a duplicate number lands on two genuinely different documents. Sequences also need to be gapless: unexplained gaps are exactly what an audit asks about.
The wrong banking details
This is the expensive one. An invoice issued from the right entity with the other entity's bank account on it doesn't bounce — it gets paid, into the wrong company. Now you have an inter-company loan you didn't plan, a reconciliation that doesn't balance, and a conversation with your accountant at year end. Copy-paste templates cause this, and they cause it quietly.
Branding that doesn't match the entity
Logo, registered name, company registration number, VAT number, address, footer terms — all of it is per-entity. A single "invoice template" with the wrong header is both a credibility problem and, where VAT is involved, a compliance one.
Inter-company invoices
Sooner or later entity A bills entity B — shared staff, shared rent, a management fee. These need to exist properly on both sides, and they need to be identifiable so that a consolidated view doesn't count the same rand twice as revenue.
No consolidated answer
The question you most want answered is the one this structure makes hardest: how much is owed to us, in total, right now? With a system per entity, the only way to answer it is to open three systems and add up three numbers — so in practice nobody does it weekly, and the group-level cash position becomes something you estimate.
Clients who deal with more than one of you
If a single customer buys from two of your entities, they should get two statements — because they legally owe two different companies. But you want to see the whole relationship in one place, including the fact that they're 60 days late with one entity while paying the other on time. That's a genuinely useful early warning, and it's invisible if the entities never talk.
The multi-entity smell test
- Could an invoice go out today with the wrong bank account on it?
- Can you state total outstanding across all entities without opening more than one system?
- Does each entity have its own gapless number sequence?
- If a client owes two of your entities, would you notice?
What good looks like
The principle is simple: the entity should be a first-class dimension of the system, not a separate copy of it. One login, one client list, one place to work — with the entity attached to every document and enforced everywhere it matters.
In practice that means:
- Entity chosen at creation. Which company is issuing this invoice is the first decision, not something corrected later. Everything downstream — numbering, branding, banking, VAT treatment — follows from it automatically.
- Per-entity everything. Separate number sequences, letterheads, registration and VAT numbers, banking details and default terms. Set once, applied without anyone remembering to.
- Server-side computation. VAT and totals calculated by the system, not by a formula in a template someone last edited. This is what stops an invoice and its statement disagreeing by a few cents.
- Both views of aging. Per entity, because that's who is legally owed — and consolidated, because that's your actual cash position. If you only have one of those, you have the wrong one half the time.
The spreadsheet failure mode, specifically
Spreadsheets don't fail here because people are sloppy. They fail because the second entity is created by duplicating the first workbook. From that moment the two drift: a formula fixed in one, a rate updated in the other, a template header changed in one and forgotten in the second. Six months later you have two systems that look identical and quietly disagree.
Everything in our earlier piece on invoice aging and getting paid faster applies here too — it just gets multiplied by the number of entities, and the follow-up discipline is harder to maintain across three sets of books than one.
If you're running more than one entity, the test isn't whether you can invoice from all of them. It's whether doing so requires anyone to remember anything. Every rule held in someone's head is a rule that eventually gets applied to the wrong company.