Effective, signing and completion dates

Why a single transaction carries more than one date, which one belongs to the movement, and why confusing them puts history in the wrong order.

Overview

A single share transfer can carry five different dates, and they are frequently all different:

The date the agreement was signed.
The date the transfer takes effect — which the agreement may set in the past or the future.
The date the payment cleared.
The date it was recorded on the platform.
The date filed with the registry.

They are not interchangeable. Treating them as one date is where problems start.

What you'll learn

Which of those dates belongs to the movement
Why the distinction changes what the cap table says
How an event's date range relates to its transactions
The discipline to apply when recording history

The one that belongs to the movement

The effective date — the date from which the ownership change is true. It is what a transaction carries, and it is what determines where a movement sits in a company's history.

The others are facts about the process, not about the ownership. The date you recorded something is administrative. The date a document was signed is evidence, not effect.

That is why Kapitable treats legal dates as domain values rather than timestamps: an effective date is a fact stated in a legal document, not a moment a system observed.

Why it matters

Ordering. A cap table is the sum of movements up to a point. Two movements a day apart in effect, but recorded in the reverse order, must still read in effect order — otherwise every position between them is wrong.

Retrospective recording. Most of what this course covers is recorded long after it happened, because an LBO's history predates the platform. A transaction recorded today with an effective date of three years ago belongs three years ago in the timeline, not today.

Documents. Generated documents carry a transaction date, and the generation flow will ask for one when it is missing (A8.6). That date should be the effective date the instrument states, not the day someone generated the document.

Disputes. When two parties disagree about when something happened, the effective date in the instrument is the answer. The record should reflect it rather than the day it was typed in.

The event date range follows its contents

An event shows a Detected Event Date Range — derived from what it contains rather than set directly. An event is a grouping of acts, so its span is whatever those acts span. That is the right way round.

Which gives you a useful check: if an event's date range looks wrong, a transaction's date inside it is wrong. Same rule as the cap table (A6.1) — fix the transaction, not the summary.

Practical guidance

Take the effective date from the instrument, not from the day you are working.
Where the instrument sets a retrospective effect, use it. Recording it as today puts the movement in the wrong place in history.
Do not use the signing date as the effective date unless the instrument says they are the same. Often they are not.
Check an event's range after recording. A wrong range points at a wrong transaction date.
Spot-check the dates after an analysis. They come from the documents, and a misread date puts a movement in the wrong year rather than merely being untidy.

Common problems

A movement appears in the wrong year. Its effective date is wrong. Correct the transaction (A5.6).

The cap table at a past date looks wrong. Ordering. Check the effective dates of the movements around that point.

An event's date range spans more than expected. One transaction inside it carries an outlying date. That is the one to look at.

A generated document shows the wrong date. The transaction date was wrong or missing when it was generated. Fix the transaction and regenerate (A8.6).