On this page
The reframe
Every cap table platform sells to the founder. The pitch is the same across the category: a clean dashboard, a stakeholder portal, fundraise modeling tools, employee equity visibility, all rendered for the person whose name is on the company. Carta. Pulley. Mantle. Cake. The user the product imagines is the founder, and the value the product promises is that the founder can finally see, understand, and control the cap table without having to wait on their counsel.
The framing is wrong, and we have spent enough time inside the closings where cap tables get audited to feel confident saying so. The cap table is not a founder problem. It is a closing problem. The people who can prevent a cap table from failing under diligence are not the founders running it in a spreadsheet or a platform. They are the counsel and accountants who maintain the underlying records the cap table is supposed to reflect. The cap table is downstream of those records. Treating it as the source, and the founder as the owner, is what makes cap tables fail at the only moments they have to hold up.
This is a thesis piece, not a guide. The argument is short, and it changes what kind of system you should be running.
Why founders own it today
There is a reasonable reason founders end up owning the cap table in early-stage companies. At organization, the founder is the only operator. Counsel did the incorporation and handed over a clean record. The cap table starts as a spreadsheet because there is nothing complicated to track. The first SAFE goes in. The first advisor share grant. The first employee option. The founder updates the spreadsheet each time, because the founder is the only one paying attention.
Then the company raises. The cap table moves to a platform, because the founder has heard from another founder that they should. The platform inherits the founder's spreadsheet, and the founder remains the operator. Counsel papers each transaction but does not maintain the cap table; the cap table is the founder's job. By the time the company is twelve people, the cap table is being kept by the same person who is also negotiating customer contracts and writing the offsite agenda, which is not a structure that survives a financing.
The platforms reinforce the pattern because the founder is the easiest user to sell to. Founders are decisive. They have a budget. They feel the pain of not knowing what they own. Counsel and accountants are slower buyers, harder to convince, and historically priced into the deal as billable hours rather than software. The category grew around the founder because the founder buys.
What actually makes a cap table fail
The cap table is rarely wrong in the way a founder fears it is wrong. Founders worry about decimal points, about whether the dilution math is right, about whether the option pool is sized correctly. Those are operational concerns, and they are also the easiest concerns to solve. A spreadsheet can do most of it.
The cap table fails at the closing table for an entirely different set of reasons. It fails because the share issuance that is on the cap table does not have a board resolution behind it. It fails because the transfer recorded as a clean line on the cap table never had a transfer instrument signed by both parties. It fails because the option grant priced at fair market value cannot point to a contemporaneous 409A and a board approval on the same date. It fails because the cap table shows a class of shares the articles do not authorize. We catalogued the specific patterns in the records findings that delay closings, and the authorization gap specifically in who authorized this issuance.
None of these failures are visible inside a cap table tool. The cap table can be arithmetically perfect and still fail every one of them, because the cap table is a derived view. What gets reviewed at closing is what the cap table is derived from: the resolutions, the register entries, the certificates, the supporting agreements. If those do not exist, the cap table is a list of numbers nobody can verify, and the closing slows until somebody verifies them.
The structural problem with founder ownership
A founder operating a cap table tool is updating a view. The view reflects what the founder believes to be true, based on the documents counsel produced or the actions the company took. The view is not connected to the documents. There is no automatic mechanism that prevents the founder from recording an issuance the board has not approved, or a transfer the transferor has not signed, or an option grant the plan has not yet been amended to allow. The platform takes whatever the founder enters and renders it cleanly.
This is the structural problem. The cap table the founder maintains is internally consistent with itself, and externally inconsistent with the records. The records sit with counsel, on a different schedule, in a different system, with a different update cadence. Drift is the default state.
A founder who knows this can compensate by manually reconciling against counsel every quarter, but few do, and the ones who do find that the reconciliation is exactly the work the platform was supposed to remove. The other option is to let counsel maintain the cap table directly, but counsel typically does not have access to the founder's platform, and is not paid to keep a spreadsheet up to date. Both sides end up with their own version, and the version that holds up at closing is the one counsel kept, often by hand, from the resolutions and the register.
The founder, in other words, is the wrong owner not because they are careless, but because they are running a downstream system from upstream documents they do not control. Even a careful founder cannot keep the cap table accurate against records they do not maintain. We covered the founder-side symptom in why most founders don't know who actually owns their company and the records-side mechanism in how share transfers quietly corrupt ownership records.
What records-grade cap table maintenance looks like
A cap table that holds up at closing is not maintained as a cap table. It is maintained as the records system, and the cap table is a derived view of the records, rendered automatically and never directly edited. Every line on the cap table traces, by construction, to a resolution in the minute book, a register entry, and a certificate or instrument. The view exists because the records exist, not the other way around. We covered the role of the underlying ledger in what goes in a stock ledger and the broader founder-side framing in cap table basics for founders.
In that model, the founder still has access to the cap table. They can see it whenever they want, share it with investors, and use it for fundraise modeling. The difference is that they cannot edit it. The only way for a number to change is for the underlying records to change, which requires the same authorization the records themselves require: a board resolution, a signed transfer, an executed grant under an active plan. The view is read-only by construction, because the records are the source.
This is also why the cap table is a closing problem with a counsel-and-accountant solution. The people who execute the resolutions, sign the transfers, and update the register are the people who can make the cap table accurate. If their workflow drives the view, the view is correct. If their workflow lives in a different system from the view, the view is drift waiting to happen. We walked through the order a diligence reviewer reads these records in what a diligence lawyer actually reads in your minute book.
The bottom line
The cap table is not a founder workflow. It is a closing artifact, generated from a records workflow that founders are structurally outside of. The category got built around the founder because the founder is the easiest sale, not because the founder is the right owner of the artifact. The result is a market full of cap tables that look beautiful in the platform and fail in diligence.
The fix is not better cap table software for founders. It is treating the cap table as a view of the records, owned by the people who maintain the records, with the founder as a reader rather than an editor. That changes the procurement question from "which cap table tool should I buy" to "whose system are my records living in, and is the cap table coming out of it." Most companies have never asked the second question.
Our solution for digital corporate records treats the cap table as exactly what it is: a derived view of the share register, generated automatically from the resolutions and instruments that authorize every entry. The founder gets the dashboard. Counsel and accountants get the source. The closing gets a cap table that traces, line by line, to the documents that support it. That is what diligence reads.
