Importing an existing LBO from its legal files

Overview

Most LBOs have years of history before they reach Kapitable. This is how that history gets in.

A project-level import takes an existing LBO's legal files and derives its history from them: the transactions, the legal content, and the events they belong to.

It is the same document-analysis mechanism as a single decision (A6.3), applied across a whole structure at once. Where a decision reads one act's documents, this reads a deal's.

What you'll learn

• How the import derives a deal's history from its files

• Where the dates come from

• Why detection and filing are separate steps

• The three things Move All does, one of which is easy to miss

• What to review before committing, and what to expect afterwards

Before you start

You need the deal's legal files. Use the demo dataset when practising — never a real deal's legal files.

Steps

1. Open the project's Import.

2. Provide the legal files.

3. Analyse. The platform reads them and detects transactions.

4. Review the Import Results — the detected transactions, before they are committed anywhere.

5. Move All to file them into events per company, or Delete All to discard and start again.

The structural point: detection and filing are separate steps. The analysis produces a set of detected transactions that sit in the import until you decide what to do with them. Nothing reaches a company's history until you move it.

What Move All actually does

Read the confirmation, because it does more than it sounds. Three things in one action:

• An event is created per affected company, with a name you supply.

• Transactions and their legal content are filed into those events.

• Companies that do not yet exist are created automatically.

That last one is worth pausing on. The import can bring companies into being. On a structure you are importing wholesale that is exactly what you want — but it means the import can populate your project with companies nobody has reviewed, named and detailed from whatever the documents said.

Where the dates come from

Each document's own date becomes its transaction's date. The analysis takes the date from the instrument rather than from when the file was uploaded or the import was run — which is the only defensible reading, since you are recording history that happened years ago.

An event then takes its date range from the transactions inside it (A6.1). Import a set of files spanning an incorporation and two later closings and the event dates follow the documents, not the import.

Two consequences worth planning for:

• A wrong date on screen usually means a wrong date read from a document — check the instrument before correcting the record.

• Where no document exists, no transaction is detected. Anything evidenced only by a resolution nobody kept, or agreed without paper, has to be added manually afterwards. The import gets you the documented history; the gaps are yours to fill.

Review before you move

Because moving commits, the Import Results stage is the review, and it is the only one.

• Are the detected transactions the right ones? The analysis read documents; check what it made of them.

• Are the parties right? Same direction check as any transfer (A6.4).

• Which companies will be created? Anything not already in the project will appear as a new company.

• Are the dates plausible? They come from the documents, so an implausible one usually means a misread instrument rather than a platform fault.

• Is the event name right? One name is used for the event created in each company. Choose something that still reads correctly in a company's history in three years — "Historical import" is honest; "Wave 1" would be misleading if the files span several waves.

Delete All discards everything detected. Use it when the analysis read the wrong files or made a poor job of them, and start again rather than fixing dozens of rows.

After moving, expect to correct

You now have events, decisions and transactions across several companies, all derived from documents. So the correction work from A5.6 applies at scale:

• Read each company's cap table (A5.1) and compare it against what you know.

• Trace anything doubtful to its document via the registry (A5.7).

• Correct transactions in their decisions — including dates the analysis read wrongly.

• Add any transaction the files did not evidence, by hand.

• The cap tables rebuild automatically.

Expect to do this. An import of a deal's whole history will not be perfect, and correcting it is the intended workflow rather than a sign something went wrong.

Common problems

Nothing was detected. The files were not readable as legal instruments, or were the wrong files.

A transaction is dated wrongly. The date came from its document. Check the instrument, then correct the transaction — the event's range follows from its contents.

A transaction you know happened is missing. The analysis found no document evidencing it. Add it manually; an undocumented act cannot be detected.

Companies you did not expect appear after moving. The import created them because the documents referenced them. Review their details (A3.5) — they came from an automated reading.

The event name is wrong in every company. One name was used for all of them. Event labels can be renamed afterwards, but choosing well first is cheaper.

A cap table is wrong after import. Expected on a first pass. Correct the transactions in their decisions (A5.6).

You want to import only part of a structure. The action is Move All. Consider providing fewer files rather than filing everything and unpicking it.

Related

• A6.1 — Events and decisions: the model · what the import produces

• A6.3 — Share issuance · the same analysis mechanism, one act at a time

• A5.6 — Reconciling and correcting the record · the correction work that follows

• A5.7 — The registry: tracing a transaction to its signed document · checking what was imported