Reconciling and correcting the record

Overview

The platform's record is a reconstruction. A company's legal register is the authority. Reconciling means comparing the two and correcting the platform where they differ.

To do that you need to know where transactions actually live — because the cap table and the registry are places you read, and neither is where you fix anything.

What you'll learn

• The three levels: event, decision, transaction

• Where a transaction can be edited, and why only there

• Why the cap table needs no correcting

• How to reconcile against a legal register, and which way to correct

The structure: event → decision → transaction

An event groups related legal content — decisions and their supporting documents — in one place.

A decision sits inside an event and groups transactions of one type:

A transaction sits inside a decision. And this is the operative fact:

A transaction can only be updated in the decision it came from.

The cap table rebuilds itself

Whenever a transaction is updated, added or deleted, the cap table is rebuilt automatically.

That is why there is nothing to correct on the cap table. It is derived from these transactions, so correcting the transaction is correcting the position.

Why editing is allowed at all

Being able to delete a transaction sounds alarming until you know what it is for.

Decisions and their transactions are created two ways: when a subscription process closes, and by importing an existing LBO from its legal files. Both are bulk operations, and both can be wrong — an import can misread a document, a subscription process can carry an error that originated upstream.

So editing at the decision level is the correction mechanism for recorded history, not a loophole in the audit trail. It exists precisely because the platform's record is reconstructed from documents and imports, and reconstructions need correcting.

Reconciling, step by step

1. Export the registry for the company — the movement-level record.

2. Compare against the legal register, movement by movement: parties, quantity, security type, date.

3. For each difference, find the decision the transaction belongs to. The timeline and the registry both lead you there.

4. Correct it in the decision — update the transaction, add a missing one, or remove one that should not be there.

5. Let the cap table rebuild. It happens automatically.

6. Re-read the cap table and confirm it matches.

Which way to correct

The source legal document is authoritative. If the platform and the register disagree, the register and the underlying instrument win.

Do not correct the register to match the platform, and do not adjust a transaction to make a cap table look right. Fix the transaction to match the document, and let the position follow.

Common problems

You cannot edit a transaction from the registry or the cap table. Correct — you edit it in its decision. Those two views are read-only representations.

The cap table still looks wrong after a correction. The rebuild is automatic, but give it a moment and re-read. If it persists, another transaction is also wrong.

A whole imported decision is wrong. Correct the transactions within it rather than deleting the decision, unless the decision itself should not exist.

A transaction has no matching entry in the legal register. That is the finding, not an error to tidy away. Either the movement was never legally effected, or the register is incomplete — and which of those it is matters.

Related

• A5.1 — Reading the cap table · why the position is derived

• A5.7 — The registry: tracing a transaction to its signed document · finding the decision from a movement

• A6.1 — Events and decisions: the model · the same structure, from the recording side