Shareholder categories

What categories are for — organising how a cap table and a hierarchy read as the shareholder base grows — and, just as importantly, what they are not.

Overview

Categories help you organise the shareholders in a company's cap table, and they decide how the hierarchy diagram groups them. That is their whole job.

A category is a presentational grouping for reading ownership. It is not a permission, not a security class, and not a legal distinction. It changes how ownership reads, not what anyone owns.

Worth being clear about, because on a build-up the temptation is to make categories carry meaning they do not carry.

What you'll learn

What categories do, and what they explicitly do not do
Why they matter more as the LBO grows
How nesting works, and how much of it to use
How your top-level categories shape the hierarchy diagram
Two habits that keep the set useful

Why they matter as the LBO grows

At the initial closing a cap table might have a handful of lines and need no organisation at all.

Three waves later it holds the sponsor across several security classes, institutional co-investors, industrial partners, and thirty participants across three ManCos. Read as a flat list, that tells you very little.

Grouped — sponsor, co-investors, management — the same table answers the questions people actually ask: how much is management holding now, how has the sponsor's position moved, what proportion sits with third parties.

Categories are what turn a long list into an answer.

Categories and sub-categories

Categories nest one level: a category can contain sub-categories. That is enough for the shapes that actually occur — Management divided by wave or by ManCo, Investors divided into institutional and industrial.

Resist deeper structure than you need. A grouping nobody maintains is worse than no grouping, because it looks authoritative while being wrong.

They shape the hierarchy diagram

On the hierarchy (A3.7), a company's shareholders are not drawn one card each — a ManCo with two hundred holders would be unreadable. They are folded into one node per top-level category, labelled Shareholders (12), with one further node for everyone carrying no category at all.

Two consequences worth designing for:

Your top-level categories are the nodes. Five of them means five shareholder nodes under that company. This is the strongest practical reason to keep the set small.
Depth is free; breadth is not. Sub-categories roll up into their parent, so Management → Wave 1 / Wave 2 stays one node and still shows both labels on it. Splitting the same people into two top-level categories draws two.

A group is a cohort rather than a type: people and legal entities in the same category share one node, and each row of its list says which it is.

Practical guidance

Name for the reader, not the modeller. The label appears on cap tables and on hierarchy nodes, so it should mean something to whoever reads one. Short is better.
Create them before a bulk import where you can, so imported shareholders can be grouped as they arrive rather than sorted afterwards.
Keep the set small. Categories earn their place by making ownership readable; a dozen of them do the opposite — on the cap table and, node for node, on the hierarchy.
Do not encode security classes. The cap table already distinguishes ordinary from preferred. A category duplicating that will drift out of step with reality.

Common problems

The cap table is hard to read despite categories. Probably too many of them. A grouping only helps if each group is worth distinguishing.

The hierarchy has too many shareholder nodes under one company. One per top-level category is the rule, so the answer is fewer top-level categories — nest the ones that belong together rather than deleting them.

A category seems to imply access or economics. It does not. If you need those distinctions they live elsewhere — access in project roles, economics in security classes.

Imported shareholders arrived uncategorised. Categories need to exist before the import references them.