Cap Table Spreadsheet Errors: What Actually Goes Wrong (and When to Stop Trusting Excel)

The most common cap table spreadsheet error is counting the option pool twice — once as reserved shares, once again as issued shares once grants go out — which overstates dilution by a few percentage points without anyone noticing. The second most common is simpler: multiple people keeping their own "latest" version, so nobody can say with confidence which file is actually true. Both errors are invisible until someone outside your company checks the math, which is exactly when they cost you the most.

If you're reading this because you searched for cap table spreadsheet errors, you probably already suspect one exists in yours. That instinct is usually right. Here's what the errors actually look like, why they're worse if you're building outside the US, and what the honest threshold is for when a spreadsheet stops being good enough.

The errors that actually recur

Generic listicles will give you ten. In practice, almost every broken cap table traces back to four.

Option pool double-counting. You create a 10% pool, list it as reserved shares in one line. Then you grant options to your first hire and add a second line for the issued shares — without removing them from the reserved line. Now the same equity is counted twice, total shares outstanding is inflated, and every ownership percentage in the file is quietly wrong. This is the single most cited spreadsheet error in cap table teardown, and it's easy to see why: it doesn't throw an error, it just silently overstates dilution by a few percentage points. Nobody catches a few percentage points until a term sheet is on the table and the numbers need to survive scrutiny.

Rounding and share-count drift. SAFEs convert at odd valuations. Investment amounts don't divide cleanly into whole shares. Excel rounds, and rounds again on the next formula that references the first rounded number. None of these are big individually. Compounded across a year of grants and two conversion events, they add up to a share count that doesn't reconcile with your incorporation documents — and reconciling it later means going back through every transaction to find where the drift started.

Version sprawl. Cap-Table-v3-FINAL.xlsx, Cap-Table-v3-FINAL-actually-final.xlsx, a copy your co-founder edited on a plane with no wifi and merged back in manually. Spreadsheets have no single source of truth by design — every save is a fork, not a commit. The moment more than one person needs write access, you've created the conditions for a discrepancy that surfaces at the worst possible time: mid-diligence, when an investor's associate builds their own version from your data room and it doesn't match yours.

Missing or late-recorded grants. An early hire's options get promised verbally, agreed in a Slack message, and never make it into the spreadsheet until someone remembers six months later — usually when that person asks about their vesting schedule, or leaves and needs a forfeiture calculated. Missing grants don't just distort the cap table; they create a legal gap, because there's no contemporaneous record of what was actually offered.

Why these get worse outside the US

Every cap table spreadsheet template you'll find by searching is built around the same assumption: one Delaware C-corp, one option pool under a standard US ESOP, one jurisdiction's rules for what a resolution needs to look like. That assumption doesn't hold if you're incorporated in Riyadh, Lagos, Nairobi, or Jakarta.

Two structural problems stack on top of the four errors above:

Dual-entity structures split the table in two. A lot of founders outside the US eventually flip to a Delaware C-corp or a Singapore holding company for a round, while the entity they actually operate stays local. Now there isn't one cap table drifting — there are two, in two currencies, under two sets of rules, and a generic template has no mechanism to keep them reconciled against each other. A spreadsheet error in the local entity's table doesn't just misstate local ownership; it misstates the pro-rata math the holdco round is actually priced on.

Jurisdiction-specific requirements have no cell for them. Saudi Arabia requires general-assembly resolutions and shareholding-weighted voting records tied to actual ownership at the time of the vote — a legal requirement most US-built cap table tools don't model at all, let alone a spreadsheet. If your ownership percentages are wrong because of a double-counted option pool, every resolution passed against those percentages inherits the error. It's not just a wrong number anymore; it's a governance record that won't hold up.

This is the gap a Carta alternative built for global founders is supposed to close — not just cheaper cap table math, but a structure that assumes your jurisdiction from the start instead of retrofitting it.

The real threshold for switching

Most advice says "switch when you're too big for a spreadsheet," which is vague enough to be useless — founders redefine "too big" every quarter to justify one more round of Excel formulas.

The threshold isn't size. It's one of three events, and any single one is enough:

1. Your first outside investor. The moment someone who isn't you is going to model your ownership independently, your spreadsheet needs to survive being rebuilt by a stranger. If it can't, that's not a future problem — it's a diligence problem, now.
2. Your first ESOP grant. The instant equity leaves the founders and goes to an employee, you need a system that tracks vesting, cliffs, and forfeiture without a human remembering to update a cell on the right date. Miss one vesting update and you've either over- or under-issued real ownership.
3. The moment two people need to edit the file. A cap table with one editor can be wrong and still consistent. A cap table with two editors and no locking mechanism will eventually have two truths.

If none of those three have happened yet, a clean spreadsheet is genuinely fine — this isn't a pitch to abandon Excel on day one. If any of them have happened, the spreadsheet is no longer a cost-saving choice. It's a liability with a delayed invoice.

What waiting actually costs

The honest version of "just migrate when you're ready" is that the cost of migrating rises every month you wait, and it doesn't rise gently.

A clean, reconciled spreadsheet migrates into proper cap table software in an afternoon — export the data, import it, verify it ties to your incorporation documents and grant letters. A spreadsheet that's drifted for a year or two, with grants scattered across email threads and formulas nobody remembers authoring, turns into a real reconciliation project: commonly cited estimates put that cleanup at 10 to 20 hours of cross-checking every line against a source document, and that's before you've resolved the discrepancies you find. The failure mode isn't the spreadsheet itself. It's the founder who stops maintaining it and tries to reconcile two years of drift the week before a data room needs to go out.

What actually fixes it

The fix isn't a better spreadsheet template. It's removing the thing that makes spreadsheets unreliable in the first place: every save silently overwrites the last state, with no record of what changed or why.

An audit-first cap table doesn't store a current state you edit in place. It stores every issuance, transfer, and correction as a discrete, timestamped event, and the "current" cap table is just the sum of everything that happened, replayed. Nothing gets silently overwritten. If a number is wrong, you correct it with a new event that voids the old one — the mistake stays in the record, visible, instead of vanishing into an overwritten cell. That's the difference between a spreadsheet and a ledger, and it's the difference that actually matters once an investor, a co-founder, or a court is going to ask "how do you know this is right."

It's also the same discipline your ESOP grants need once you stop using a lawyer for every one of them — a repeatable, jurisdiction-aware process that doesn't depend on someone remembering to update the right cell.

Fixing a cap table spreadsheet error after the fact is a cleanup project. Not having spreadsheet errors in the first place is a structural choice, made once, that just keeps paying off.

Govy runs cap tables on an event-sourced ledger built for founders outside the Delaware default — general-assembly governance, jurisdiction-aware ESOP contracts, and a cap table that can't be silently overwritten. See how it works at govy.tech.

FAQ

What's the most common mistake in a cap table spreadsheet? Double-counting the option pool — listing it once as reserved shares and again as issued shares once grants go out. It's a single formula error, but it overstates dilution by several percentage points, and nobody notices until an investor's associate rebuilds the table independently and the numbers don't match.

When should a startup move off a spreadsheet cap table? Not on a calendar — on an event. The trigger is your first outside investor, your first ESOP grant, or the moment two people need to edit the same file. Any of those three turns a spreadsheet from "fine" into "actively dangerous," regardless of how many months you've been running the company.

How long does it take to migrate a messy cap table to software? A clean, reconciled spreadsheet takes an afternoon. A cap table that's drifted for a year or two, with grants tracked in email and formulas nobody remembers writing, turns into a genuine reconciliation project — commonly cited estimates run 10 to 20 hours of cross-checking against source documents. The gap between those two numbers is entirely a function of how long you waited.

Does a cap table spreadsheet count as an audit trail? No. A spreadsheet stores a current state, not a history of how it got there — every edit overwrites the last one, and Excel's own version history is not admissible evidence of who changed what and why. An audit trail requires every change logged as a discrete, timestamped, attributable event, which is a different kind of system than a grid of cells.

Do jurisdictions outside the US make cap table errors worse? Yes, because most spreadsheet templates and even most cap table tools are built around a single Delaware C-corp with a US-standard option pool. A founder in Riyadh, Lagos, or Jakarta is often tracking a dual-entity structure, jurisdiction-specific ESOP instruments, or general-assembly resolutions that a generic template has no column for — so the same double-counting error compounds with a structural one the template never anticipated.