Cap Table Extraction and Normalization Prompt

This prompt is designed for legal operations, finance, and data engineering teams that need to convert unstructured capitalization tables from term sheets, funding documents, or corporate filings into a machine-readable, normalized JSON structure. The core job-to-be-done is transforming a visual or text-based ownership summary—often a mix of narrative text and embedded tables—into a single source of truth that captures shareholder names, share classes, ownership percentages, and dilution calculations. The ideal user is a developer or analyst building an ingestion pipeline for a cap table management system, a data room, or a compliance audit trail, where manual re-keying is too slow and error-prone.

Use this prompt when the input document contains a definitive capitalization table, even if it spans multiple pages or mixes prose with tabular data. It is appropriate for Series Seed through late-stage term sheets, stock ledgers, and pro forma cap tables included in board decks. The prompt expects a clear [DOCUMENT_TEXT] input and an optional [EXISTING_RECORDS] context for deduplication. It is not designed for extracting ownership information from narrative contracts like stock purchase agreements where the cap table is not explicitly summarized, nor for real-time cap table management platforms that already provide API access. Do not use this prompt for calculating complex waterfall liquidation preferences or option pool modeling; it normalizes stated values, not forward-looking financial simulations.

The prompt works best when paired with a pre-processing step that isolates the cap table section from the broader document and a post-processing validation harness that checks for the 'sum-of-parts' integrity (e.g., fully-diluted shares summing to 100%). Before deploying, ensure you have a human review step for any extraction where the confidence score falls below a defined threshold, particularly for handwritten or heavily redacted documents. If the source document is a scanned image, route it through an OCR pipeline first and include the OCR confidence metadata in the [DOCUMENT_TEXT] input to help the model flag uncertain regions.

The following prompt template is designed to be dropped into your application's prompt layer. It instructs the model to act as a financial data extraction specialist, processing capitalization table documents. The prompt uses square-bracket placeholders for all dynamic inputs, allowing you to inject the source document, define the exact output schema, and set operational constraints before each call. This separation ensures the core logic remains stable while the data and rules can be updated independently.

textCopy
You are an expert financial data extraction system. Your task is to process a capitalization table document and extract all shareholder, equity, and dilution information into a strictly normalized JSON structure.

**INPUT DOCUMENT:**

[DOCUMENT_TEXT]

codeCopy

**OUTPUT SCHEMA:**
You must output a single JSON object conforming to this exact structure. Do not include any text outside the JSON object.
{
  "company_name": "string",
  "as_of_date": "YYYY-MM-DD",
  "total_authorized_shares": "number | null",
  "total_outstanding_shares": "number | null",
  "fully_diluted_shares": "number | null",
  "share_classes": [
    {
      "class_name": "string (e.g., Common, Series A Preferred)",
      "authorized_shares": "number",
      "issued_shares": "number",
      "outstanding_shares": "number",
      "liquidation_preference": "number | null",
      "conversion_ratio": "number | null",
      "par_value": "number | null"
    }
  ],
  "shareholders": [
    {
      "name": "string",
      "share_class": "string",
      "shares_held": "number",
      "ownership_percentage": "number",
      "fully_diluted_percentage": "number | null",
      "investment_amount": "number | null",
      "acquisition_date": "YYYY-MM-DD | null"
    }
  ],
  "option_pool": {
    "total_shares_reserved": "number | null",
    "issued_shares": "number | null",
    "available_shares": "number | null"
  },
  "convertible_notes": [
    {
      "holder_name": "string",
      "principal_amount": "number",
      "interest_rate": "number | null",
      "maturity_date": "YYYY-MM-DD | null",
      "conversion_discount": "number | null",
      "valuation_cap": "number | null"
    }
  ],
  "extraction_notes": ["string"]
}

**CONSTRAINTS:**
[CONSTRAINTS]

**EXAMPLES:**
[EXAMPLES]

**RISK LEVEL:** [RISK_LEVEL]

**INSTRUCTIONS:**
1. Extract all available data, using `null` for any field where the information is not present or cannot be reliably determined from the document.
2. Calculate `ownership_percentage` as (shares_held / total_outstanding_shares) * 100.
3. Calculate `fully_diluted_percentage` using the `fully_diluted_shares` denominator if available.
4. Reconcile totals: the sum of `outstanding_shares` across all `share_classes` should equal `total_outstanding_shares`. If a discrepancy exists, flag it in `extraction_notes`.
5. For any value that is inferred, interpolated, or calculated rather than directly observed, add a detailed note to `extraction_notes` explaining the method and source cell.
6. If the document contains illegible or ambiguous text, do not guess. Use `null` and add a note describing the issue.

To adapt this template, replace the placeholders with your specific requirements. [DOCUMENT_TEXT] should contain the pre-processed text of the cap table document, ideally with layout hints preserved. [CONSTRAINTS] can be used to enforce rules like 'only extract Series A and later rounds' or 'all monetary values must be in USD'. [EXAMPLES] should be populated with a few-shot demonstration of a correctly parsed cap table to guide the model's output format and edge-case handling. [RISK_LEVEL] should be set to 'high' for production use, which should trigger downstream validation and human review steps in your harness. The next section details how to build that harness.

This prompt is designed to be the extraction step inside a larger ingestion pipeline, not a standalone chatbot interaction. The typical flow begins with a PDF parser that extracts text and table coordinates, followed by a pre-processing step that identifies candidate cap table pages using a lightweight classifier or keyword heuristic. The prompt receives the raw text of those pages along with any available spatial metadata. After the model returns the normalized JSON, a post-processing validator checks the output against business rules before the data is written to the cap table management system. This separation of concerns—parse, classify, extract, validate, load—keeps each component testable and replaceable.

Wire the prompt into your application using an async job queue. Submit extraction requests with a unique extraction_id, the document text, and any [CONTEXT] such as the company name or funding round label. On success, route the output to a schema validator that checks: (1) all required fields are present and non-null where expected, (2) ownership percentages sum to approximately 100% within a tolerance of 0.01, (3) share counts are positive and internally consistent, and (4) no duplicate shareholder entries exist. If validation fails, retry once with a repair prompt that includes the original output and the specific validation errors. If the retry also fails, flag the extraction for human review and log the full trace—input, output, errors, and model version—for later diagnosis.

Model choice matters here. Use a model with strong structured output capabilities and a large context window if cap tables span multiple pages. Enable JSON mode or structured output constraints to reduce parsing errors. For high-volume production, consider caching the system prompt prefix to reduce latency and cost. Implement idempotency keys on the extraction job to prevent duplicate processing. Most importantly, never auto-commit extracted cap table data to a system of record without either passing validation or receiving human approval. A single misread percentage or missing shareholder can cascade into incorrect dilution calculations, option pool sizing, and investor reporting errors that are expensive to unwind.