Assigning categories

Overview

The mechanics of categories: building the structure, assigning shareholders to it, and moving people between categories afterwards.

Because a category is presentational rather than economic, reorganising is a normal operation rather than repair work — nothing about anyone's holding changes.

What you'll learn

• How to add, rename and nest categories — which has to come first

• How to assign shareholders, individually and in batches

• What an assignment changes on the cap table and on the hierarchy

• The sequence that avoids sorting people twice

Before you start

The categories you want to use need to exist. Creating them first also lets imported shareholders arrive already grouped.

Steps

Managing the structure — do this first, since there is nothing to assign to until the categories exist.

1. In the project navigation, open Shareholders.

2. Scroll past the shareholders table to Shareholder Categories, beneath it. The category controls live there rather than on the table itself, which is where people go looking for them.

3. Then:

• Add Category creates a top-level category.

• Add Category from within an existing category creates a sub-category beneath it.

• Modify Category renames one. Renaming changes only the label — assignments are unaffected.

• Delete Category removes one, with a confirmation. It is detached from everyone who held it, and they move into the hierarchy's no category node — the holdings themselves are untouched.

Assigning a shareholder

1. On the shareholders table, select the shareholder, or several.

2. Assign them to a category.

3. The grouping appears when you next read an affected company's cap table.

The hierarchy regroups itself too, a moment later — a category assignment queues a rebuild of the diagram, so the shareholder moves into the node for their new category without anyone asking for it. Assign to a sub-category and they appear in the parent's node, since sub-categories roll up.

Work in batches

On a large shareholder base, select the group and assign once rather than working through people individually.

This is the same argument as bulk import: a build-up produces shareholders in waves, and treating them one at a time is what makes the work grow with the deal.

The sequence that avoids doing it twice:

1. Create the categories you know you need

2. Import or add the shareholders

3. Assign in batches

4. Reorganise later, as the structure clarifies

Reassigning is normal

Moving a shareholder between categories is routine rather than corrective. A participant who was grouped by wave is later grouped by ManCo; an investor moves from prospective to institutional when their position completes.

Because a category is only a grouping, reassignment changes nothing about the holding. Reorganise freely as the structure becomes clearer.

Common problems

A shareholder appears uncategorised on a cap table. They have not been assigned. Uncategorised is a valid state rather than an error — though on a table where everyone else is grouped, one loose line reads as an oversight. On the hierarchy they sit in the node that gathers everyone with no category.

The hierarchy still shows the old grouping. The rebuild is queued rather than instant, so give it a moment and reload. If it persists, the assignment did not save — check the shareholder's own record.

You want to rename rather than re-categorise. Use Modify Category. Renaming keeps every assignment; deleting and recreating does not.

The structure has grown unwieldy. Consolidate. Categories exist to make ownership readable, and too many achieve the opposite — on the hierarchy each top-level category is a node of its own, so breadth shows up there first. Nesting is the fix, not deleting.

You are unsure whether deleting is safe. Renaming definitely is. Prefer renaming or consolidating over deleting where either will do.

Related

• A4.3 — Shareholder categories · what they are for, and what they are not

• A4.5 — Shareholder bulk import: preparing your file · grouping people as they arrive

• A5.1 — Reading the cap table · where the grouping shows up

• A3.7 — Reading the hierarchy · where the grouping becomes nodes