How Story.law builds a cap table from your source documents
See how Story.law turns uploaded legal documents into a cap table using lawyer logic, legal-effectiveness checks, and diligence-ready outputs.
Introduction
Story.law builds a cap table from the source documents you already have, not from some fantasy version of your records that a founder has to retype by hand. That is the whole point of Aegis: upload the mess of legal documents, let lawyer-defined rules do the heavy lifting, and get an automated cap table without separate manual data entry.
This guide explains how that document-first process works, why the lawyer-in-the-loop logic matters, and how Story.law turns raw paperwork into outputs that are actually useful for fundraising and diligence. We’ll cover the validation layer too, because a cap table that looks tidy but ignores legal effectiveness checks is how people walk into avoidable mistakes. Story.law’s pitch is blunt for a reason: built from your documents’ reality, not your best guess or your sweat.
What is a cap table built from source documents?
A cap table built from source documents is exactly what it sounds like: the ownership record gets built from the company’s actual legal paperwork, not from a founder retyping numbers into yet another damn system. With Story.law, founders upload their formation docs, stock issuances, SAFEs, notes, consents, and other records, and Aegis uses lawyer-defined rules to turn that mess into an automated cap table. The point is simple: build from what legally exists, not from memory, guesswork, or sweat.
That matters because cap tables go sideways when the legal record and the spreadsheet drift apart. Story.law describes Aegis as extracting content and key data points with proprietary lawyer logic into a graph of the company’s legal reality, then organizing that into a usable ownership record. So this is not a generic form-fill exercise. It is a lawyer-in-the-loop process designed to reflect what the documents actually say, even when the documents are messy.
Just as important, Story.law is not pitching Aegis as generic legal tech. Story LLP is an AI-native law firm, and Aegis was built by Story’s lawyers to deliver standardized legal services at scale. That distinction is the whole game here. The software is not asking founders to play amateur paralegal and manually reconstruct history. The lawyer’s logic is baked into the system so the cap table is built from your documents’ reality, not your best guess.
Spend less. Get better legal. If your records are chaos, start with the documents you already have instead of pretending a clean spreadsheet will magically appear. Try it free for 7 days at story.law, or design your perfect package at story.law.
Why building a cap table from documents matters in 2026
If your cap table starts with fuzzy memory, stale spreadsheets, or founder data entry, you can end up preserving the mistake in a prettier format. That is the whole problem. Story.law treats legally effective documents as the source of truth, not founder inputs founders may not fully understand. Built from your documents' reality, not your best guess or your sweat, the cap table has a better shot at reflecting what actually happened.
That matters because cleanup risk is real. Systems built on manual entry can carry forward bad assumptions, while Story.law says its cap table is based only on actual, effective documents and the references those documents make. In plain English: the software follows the paper trail instead of asking founders to recreate legal history from memory. That is a much safer foundation for ownership records, especially when the record is messy.
It also matters when money is on the line. Story.law says its startup legal services include cap tables built automatically from legally valid documents users upload, plus an always-on data room ready to share with investors. Story.law also says its data room organization is designed to reduce diligence surprises, speed investor review, and lower legal fees during fundraising. So this is not just about neat records. It is about being ready for legal review without getting blindsided by your own documents.
Common challenges in cap table building and how Story.law solves them
Cap table cleanup is usually a garbage fire, not a tidy admin task. Ownership data is scattered across signed PDFs, random folders, inboxes, and half-labeled files that nobody touched after the round closed. Story LLP built Aegis for that exact mess: you can upload a zip file, a Drive folder, an inbox full of signed PDFs, or even email materials to gc@story.law, and the system organizes what you dumped into it. That matters because the problem is rarely “missing a spreadsheet.” The problem is that the legal record is fragmented.
Common challenges encountered
1. The ownership record is spread everywhere. Founders rarely have one clean source of truth. The real record lives in executed documents, email threads, board paperwork, and whatever survived prior counsel handoffs. Story’s document-first approach starts with those source materials instead of asking founders to manually rebuild history from memory.
2. Founders are often asked to input legal facts they may not fully understand. This is where a lot of cap tables go sideways. Traditional systems can depend on founder inputs, even when founders are not sure which documents control or what actually counts. Story says its cap table is built from legally effective documents rather than founder inputs that founders may not fully understand. Bluntly: your best guess is not a legal record.
3. Unsigned or unapproved documents can create fake entries. A draft option grant, unsigned consent, or half-finished financing doc should not magically become ownership data. Story says it considers only legally effective documents, valid files signed by the right parties and approved in the right way, before anything counts in the cap table. If something is not signed or approved by the legally required people, it does not get added. That check matters because bad assumptions do not become less bad just because software stores them neatly.
4. Data-entry systems can preserve mistakes instead of fixing them. Carta- and Pulley-style data entry assumes the inputs are correct. If the assumptions are wrong, the software just helps you scale the wrongness faster. Story explicitly contrasts its approach with those systems by saying they work on data entry, while Story’s cap table is based only on actual, effective documents and the references those documents make. That is the whole point of baking lawyer logic into the software: organize the mess, test what is legally effective, and build from the documents that actually count.
The short version: Story does not ask founders to cosplay as cap table lawyers. Story organizes uploaded materials and builds from legally effective documents, with lawyer logic baked in from the start. Try it free for 7 days, story.law. Or, if you want less chaos and fewer bad assumptions, design your perfect package, story.law.
What to look for in software that builds a cap table from source documents
Most cap table software falls apart when your records are a real startup mess instead of a tidy demo account. If you’re evaluating this category, don’t get distracted by a pretty dashboard. The question is whether the software can turn actual legal documents into a cap table grounded in legal reality. Story.law built Aegis for exactly that job, which means the criteria below are not fluff-they’re the difference between a usable record and a dangerous fairy tale.
Must-have features
1. It should accept messy source materials, not demand cleanup first. If a tool only works when everything is already organized, congrats, it’s useless at the exact moment you need it. Story.law says founders can upload a zip file, a Drive folder, an inbox full of signed PDFs, or even email materials to gc@story.law, and Aegis takes it from there. That matters because cap table reconstruction usually starts with scattered records, not pristine folders.
2. It should extract legal content into a structured record. A glorified file cabinet is not enough. You need software that pulls content and key data points out of the documents and turns them into something coherent. Story.law states that Aegis uses proprietary lawyer logic to extract that information into a graph of the company’s legal reality. That matters because a cap table is only as good as the underlying legal record holding it together.
3. It should check legal effectiveness, not just parse text. Here’s where a lot of tools quietly become sketchy. Reading a document is not the same as knowing whether it counts. Story.law says Aegis considers only legally effective documents-valid files signed by the right parties and approved in the right way-before those items count in the cap table. That matters because unsigned, improperly approved, or otherwise invalid paperwork should not drive ownership math. Pretty obvious, yet plenty of software punts on it.
4. It should produce outputs that reflect actual ownership history. A cap table is not just a share count slapped into rows. The software should organize ownership breakdown, equity classes, and investment history from the uploaded documents. Story.law says Aegis does exactly that. This matters because founders, counsel, and investors need to understand not just who owns what, but how the company got there.
5. It should connect to diligence and fundraising, not live as a standalone table. A cap table by itself is nice. A cap table tied to an always-on data room is actually useful. Story.law says its startup legal services include cap tables built automatically from legally valid uploaded documents, plus a data room ready to share with investors. Its Raise package also includes a pro-forma-ready cap table, SAFE conversion modeling, diligence management, and a smart data room with granular permissions. That matters because the point is not admiring the table-it’s being ready for financing, diligence, and whatever chaos shows up next.
If you want the blunt version, look for software that starts with your documents, checks what legally counts, and produces a cap table tied to the rest of the company’s legal record. That’s the bar. Story.law built Aegis around that logic instead of making founders babysit another fake-self-serve system. Try it free for 7 days, story.law. Or skip the nonsense and design your perfect package, story.law.
How founders use Story.law to turn messy records into a usable cap table
Here’s the actual flow, minus the fake magic. Story.law starts by having founders upload the source materials they already have, the messy stack of formation docs, financing paperwork, SAFEs, consents, and whatever else is sitting in folders and inboxes. From there, we do not ask you to rebuild the company from memory or your “best guess.” The process starts with the documents because that’s where the legal reality lives.
Next, Aegis extracts the content and key data points using proprietary lawyer logic and maps them into a graph of the company’s legal reality. That matters because a cap table is not just a spreadsheet with names and numbers slapped on it. It depends on what the documents actually say, how they connect, and whether later actions changed earlier ones. Story.law’s whole point is to build from the paper trail instead of making founders do legal archaeology by hand.
After extraction, Story.law assesses legal effectiveness. This is the part most software likes to gloss over because it’s hard and annoying. We don’t. If the records are messy, the right move is to surface the mess, not hide it behind a clean-looking dashboard. The workflow is built to evaluate what the documents support before treating the cap table as usable.
Once that legal assessment is in place, Story.law visualizes the cap table and the related data room. That gives founders something they can actually use instead of a pile of PDFs and creeping dread. On related startup packages, Story.law also supports outputs like a pro-forma-ready cap table, SAFE conversion modeling, and growth cap table features including pro formas, preferred stock handling, and waterfall analysis.
Last, founders can share the outputs with lawyers and investors. Story.law describes its smart data room as having granular permissions, and its data room organization is designed to reduce diligence surprises, speed investor review, and lower legal fees during fundraising. In plain English: less chaos, faster review, fewer expensive fire drills. If you want to see how we turn document soup into something usable, try it free for 7 days, story.law. Or skip the hand-wringing and design your perfect package, story.law.
Best practices for building a cap table from legal documents
A trustworthy cap table starts with documents, not vibes, not memory, and definitely not that one spreadsheet everyone is scared to touch. Story.law treats only legally effective documents as countable inputs: valid files, signed by the right parties, and approved the right way before they belong in the cap table. That matters because a cap table is supposed to reflect what legally exists, not what someone meant to finish later.
The first best practice is brutally simple: start from signed and approved records. Story.law’s educational content says equity can be issued only when required compliance steps are satisfied, including board approval, share availability, and signed agreements where applicable. If those gating items are missing, the issuance is not ready for prime time, and your cap table should not pretend otherwise.
The second best practice is to treat legal status as a filter, not a footnote. Story.law explains that grant date equals board consent date, and that unsigned, unpaid, or unapproved equity does not legally exist. That is the kind of rule people skip when they are rushing, and it is exactly how messy records turn into diligence headaches. If the paperwork is incomplete, the cap table should reflect that reality instead of papering over it.
The third best practice is boring but critical: keep records organized enough for fundraising, investor review, and diligence. Story.law says its data room organization is designed to reduce diligence surprises, speed investor review, and lower legal fees during fundraising. Translation: clean records now save you from expensive chaos later.
This is also why Story.law built Aegis the way it did. Story LLP is a law firm, and Aegis was built by Story’s lawyers to deliver standardized legal services at scale. So the practice is not just “upload docs and hope.” The lawyer logic is baked into the software, which helps us sort what is legally effective from what is half-finished, missing approval, or just plain not real yet.
If your cap table is being built from source documents, that is the standard. Start with complete records. Check approvals. Confirm signature status. Keep everything organized for the day someone asks hard questions, because they will. Try it free for 7 days, story.law. Or design your perfect package at story.law if you want a system that does not treat legal reality like an optional detail.
Advantages of Story.law’s document-first cap table approach
Story.law skips the dumbest part of cap table cleanup: retyping everything into a separate spreadsheet or software tool. Its cap table is built from the actual legal documents founders upload, so there is no separate manual cap table data entry step bolted on after the fact. That matters because duplicate entry is where messy records turn into even messier records.
Aegis also organizes the ownership picture into something usable: ownership breakdown, equity classes, and investment history pulled from those uploaded documents. In plain English, your records stop living as a pile of PDFs and start behaving like structured legal data. That gives founders a clearer view of who owns what, what class they hold, and how the company got there.
There’s also the fundraising benefit. Story.law says its startup legal services include an always-on data room ready to share with investors. That means the cap table work is not trapped in a private legal cleanup project nobody can use until the night before diligence. The materials are organized for sharing when you actually need them.
And yes, this is about reducing chaos, not pretending fundraising is magically easy. Story.law says its data room organization is designed to reduce diligence surprises, speed investor review, and lower legal fees during fundraising. That is the real win: fewer ugly surprises, less back-and-forth, and less paying lawyers to reconstruct your company history from scraps.
The bigger advantage is who built the system. Story LLP is a law firm, and Aegis was built by Story’s lawyers to deliver standardized legal services at scale. So this is not generic software guessing at legal meaning. It is lawyer-in-the-loop logic baked into the system, which is exactly what you want when the source material is legal paperwork and the stakes are your ownership records.
Try it free for 7 days, story.law. Or design your perfect package at story.law if you want a cap table built from your documents instead of your best guess.
How Story.law simplifies cap table building with lawyer logic baked into the software
Most cap table software starts with data entry. That is the first red flag. Story LLP does not sell a generic legal tech tool or a marketplace. We are an AI-native law firm, and Aegis is our lawyer-in-the-loop, hallucination-proof system for turning source documents into legal operations that actually track reality. The point is not to make founders type faster. The point is to stop making them reconstruct legal history from memory, spreadsheets, and vibes.
Aegis is built by lawyers and used inside a law firm practice, so the logic in the software is legal logic, not just database logic. Story’s own positioning is blunt: upload your mess of legal documents and get an automated cap table, a diligence-ready data room, a pro forma, and a health check score. Lawyer-defined rules do the heavy lifting, which means the system is built from your documents’ reality, not your best guess or your sweat.
That is also where Story splits from Carta and Pulley. Those systems work on data entry. Story’s cap table is based only on actual, effective documents and the references those documents make. In plain English: if the paper does not support it, it does not belong in the cap table. That sounds obvious, but plenty of companies end up paying lawyers to clean up software records that were wrong from the start. Dumb system, expensive consequences.
Because this runs as part of Story LLP’s legal service model, confidentiality is not an afterthought bolted onto a SaaS dashboard. Story says client data is confidential, operated entirely on private law firm servers for privilege protection, and shared only with lawyers who clear conflicts and are providing legal representation. Its privacy policy also says the software elements are operated on behalf of and for the exclusive use of the Story LLP law firm, with conflict checks before exposing matter information in legal-assistance outreach. That is the difference between a law-firm system and a tool that just happens to touch legal documents.
So the simplification is real, but let’s not sugarcoat it: cap table reconstruction is hard because legal records are messy, inconsistent, and sometimes flat-out broken. Story makes it simpler by keeping the lawyers in the loop and baking their judgment into Aegis instead of dumping the mess back on the founder. Spend less. Get better legal. Try it free for 7 days, story.law. Or design your perfect package at story.law.
Final thoughts and next steps
This is the whole point: a cap table should come from the legal documents that actually govern ownership, not from somebody’s spreadsheet guesswork or a founder spending their weekend reconstructing history. Story.law is an AI-native law firm, and its Aegis platform is lawyer-in-the-loop, hallucination-proof. You upload the mess of source documents, and the system applies lawyer-defined rules to produce an automated cap table built from your documents’ reality, not your best guess.
That matters because fundraising readiness lives or dies on whether your ownership story holds up under diligence. Story.law says its startup legal services include cap tables built automatically from legally valid uploaded documents, plus an always-on data room ready to share with investors. In other words: not just a cleaner table, but outputs that are actually useful when investors start asking annoying but very real questions.
If you want to see how Story.law turns messy records into a diligence-ready cap table, learn more at Story.law or contact the team to get started.
FAQs about building a cap table from source documents with Story.law
What is a cap table built from source documents?
A cap table built from source documents is exactly what it sounds like: Story.law builds the ownership record from the actual legal paperwork, not from somebody retyping numbers into a spreadsheet and hoping they did not screw it up. Story.law says founders upload their real documents, and the cap table is built from those materials rather than separate manual data entry. That matters because the record is tied back to the underlying legal files instead of a secondhand summary that can drift from reality.
How does Story.law build a cap table from source documents instead of manual data entry?
Story.law describes a five-step process. First, founders upload source materials. Then Aegis extracts content and key data points using proprietary lawyer logic into what Story.law calls a graph of the company’s legal reality. After that, Story.law assesses legal effectiveness, visualizes the cap table and data room, and lets users share outputs with lawyers and investors. The point is blunt: Story.law is not asking founders to manually rebuild the company’s history in a separate system from scratch.
How does Story.law decide whether a document is legally effective enough to count in the cap table?
Story.law says it counts only legally effective documents. In plain English, that means valid files signed by the right parties and approved in the right way. Story.law also states that if something is not signed or not approved by the legally required people, it does not get added to the cap table. That is the whole lawyer-logic part: not every document floating around a folder deserves equal weight, and Story.law filters for what is legally effective before it affects ownership.
Why do board approvals and signatures matter for cap table accuracy?
Because equity is not magic. Story.law’s educational materials say equity can be issued only if required compliance steps are satisfied, including board approval, share availability, and signed agreements where applicable. Story.law also explains that grant date equals board consent date and that unsigned, unpaid, or unapproved equity does not legally exist. So if a cap table includes grants that were never properly approved or signed, it is not “close enough.” It is wrong, and wrong ownership records become expensive fast.
How is Story.law different from Carta or Pulley when building a cap table?
Story.law draws the line pretty clearly. It says Carta and Pulley work on data entry, while Story.law builds the cap table based only on actual, effective documents and the references those documents make. That means Story.law starts from signed and approved legal records instead of relying on someone to manually key in the company’s history. Different input, different result. The whole pitch is that Story.law is built from your documents’ reality, not your best guess after digging through old folders.
Can Story.law turn old signed PDFs, email attachments, or a messy Drive folder into a usable cap table?
Yes. Story.law says founders can upload a zip file, a Drive folder, an inbox full of signed PDFs, or even email materials to gc@story.law, and Aegis takes it from there. That matters because most companies do not have pristine records sitting in one neat folder like a legal fantasy novel. Story.law is built for the mess founders actually have, then uses those source materials to build a usable cap table instead of demanding perfect inputs before anything can happen.
What does Story.law mean by a graph of your legal reality?
Story.law says Aegis extracts content and key data points with proprietary lawyer logic into a graph of the company’s legal reality. Less buzzword version: Story.law maps how the documents relate to each other so the cap table reflects what the legal record actually supports. On its cap table page, Story.law says this graph is created after upload and before visualization, which means the system is not just storing files. It is organizing the legal facts those files establish and connecting them into a usable ownership record.
How does Story.law connect cap table building with diligence readiness and investor sharing?
Story.law does not stop at showing who owns what. Its published process says the platform visualizes the cap table and data room, then supports sharing outputs with lawyers and investors. Story.law also says its data room organization is designed to reduce diligence surprises, speed investor review, and lower legal fees during fundraising. So the cap table is tied to the underlying documents and to a diligence-ready structure, which is a lot more useful than a lonely spreadsheet that falls apart the moment an investor asks for backup.
Does Story.law include SAFE conversion modeling and pro forma cap table views?
Yes. Story.law says its Aegis Raise package includes a pro-forma-ready cap table and SAFE conversion modeling, along with diligence management and a smart data room with granular permissions. So Story.law is not limited to a static historical ownership snapshot. It also supports forward-looking views that matter during a financing process. That is useful when founders need to understand how SAFEs may convert and what the post-transaction cap table could look like, without splitting those tasks across a pile of disconnected tools.
How does Story.law protect confidentiality and privilege when founders upload sensitive legal documents?
Story.law says client data is confidential and operated entirely on private law firm servers for privilege protection. It also says information is shared only with lawyers who clear conflicts and are providing legal representation. Story.law’s privacy policy adds that the software elements are operated on behalf of and for the exclusive use of the Story LLP law firm, with conflict checks before matter information is exposed in legal-assistance outreach. Short version: Story.law frames confidentiality and privilege as hard operational rules, not marketing garnish.
We're lawyers, remember? Please read this important note:
Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.
As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.
Build Your Cap Table From Your Documents
7 days free on any plan. No charge until you’re ready.
Get Automated Legal with Aegis
Subscribe to Aegis to build your cap table automatically — see your ownership breakdown, equity classes, and investment history organized from your documents.