Cap table history and audit,
built into every close

The diligence story: what changed, when, and why

Every financing, acquisition, and audit eventually asks the same question in different words: what did the cap table look like before this event, and what exactly changed? On a spreadsheet, the honest answer is a folder of files named captable_FINAL_v3.xlsx and an afternoon of manual reconciliation, with no reliable way to show that the version you dug up was the version that was true at the time.

Snapshots turn that question into a two-click answer. Because every round close records a pre-close snapshot automatically, the "before" state of every financing exists by construction, not by discipline. Add manual captures around the events between rounds (a board pack, a transfer, an ESOP top-up) and your cap table history and audit narrative becomes continuous: a chain of dated states, each one diffable against any other.

That is the whole pitch. Diligence does not reward the company with the prettiest deck. It rewards the company whose numbers reconcile on the first pass. If you want to see what a reviewer will actually walk through, the closing-a-round checklist in the Academy maps each request to the record that answers it.

One history, three layers

Snapshots are one layer of a deliberately redundant system, and it helps to know which layer answers which question:

• Snapshots answer state questions: what did the whole table look like on a given date, and how does it differ from another date?
• The transaction ledger answers flow questions: which issuances, transfers, and repurchases got the table from A to B?
• The audit trail answers actor questions: who changed what, and can it be reversed? That layer, admin-gated logging with a trigger-enforced reversibility chain, lives on the compliance side of the product.

Together they mean a cap table history and audit story you can demonstrate rather than assert. A reviewer can pick any two dates, watch the diff reconcile, then trace any single line back through the ledger. Most cap-table disasters are not fraud. They are drift that nobody caught because nothing was comparing states. The most common failure modes are catalogued in our cap-table mistakes post; nearly all of them are visible in a diff long before they are visible in a crisis.

Restore preview: see the old state before you act

History is occasionally for repair, not just for reading. When something looks wrong (a bad import, a batch edit applied to the wrong class), open the restore preview on any snapshot. It is a strictly read-only view of the complete cap table as it stood at that moment: every holder with shares and percentages, every round, every grant. Nothing is modified. From there you reconcile against the live table and correct the specific records that drifted, with the true historical state on screen instead of in your memory.

Where snapshots sit in your diligence stack

Snapshots pair naturally with the Data Room: the diff PDF that reconciles a round belongs in the same folder as the signed documents that authorized it, and the data room's readiness score will tell you which of the twelve standard diligence items you are still missing. Upstream of a raise, use the dilution calculator to model what the next round will do to founder ownership, then, after close, check the automatic pre-close diff against the model. When the modeled dilution and the diffed dilution agree, your cap table is telling one story.

The fastest way to feel this is to load the seeded sample company in the app, take a snapshot, change something, take another, and diff the two. It takes about three minutes, and it is the demo that convinces finance people.