Regulatory Filing Table Extraction Prompt Template

This prompt is for data engineering teams that need to extract structured, schema-conforming data from complex tables inside regulatory filings—SEC EDGAR submissions, FDA approval documents, Basel III reports, SOX audit evidence, and similar compliance artifacts. The job is not general table extraction. It is extraction that must survive merged cells, multi-page table continuations, footnoted values, and numeric fields that will be ingested into downstream compliance databases, dashboards, or audit systems. The ideal user is an engineer or technical product manager who already has a document ingestion pipeline and needs a prompt that produces cell-level provenance, footnote association, and cross-table reconciliation flags, not just a CSV dump.

Use this prompt when your tables contain merged header rows, sub-totals that must be excluded from data rows, footnotes attached to individual cells, or values that span multiple pages with repeated headers. Use it when the output must conform to a strict schema that downstream systems will validate—think numeric type enforcement, unit normalization, and null handling for empty cells. Use it when you need to reconcile totals across multiple tables in the same filing and flag inconsistencies before the data reaches a compliance report. The prompt expects you to supply the raw text of the regulatory filing, a target output schema, and any domain-specific validation rules such as expected column totals or cross-table referential checks.

Do not use this prompt for simple single-table CSV exports, for tables that are already machine-readable in XBRL or inline tagged formats, or for documents where table structure is decorative rather than data-bearing. Do not use it when the regulatory filing contains only narrative text without tabular data. Do not use it as a substitute for a deterministic parser when the input is a well-formed HTML table with no merged cells or footnotes—the prompt adds latency and cost without benefit in that case. Do not use it without human review when the extracted values will be submitted to a regulator, filed in an official report, or used as evidence in an audit finding. The prompt reduces extraction toil but does not eliminate the need for verification.

Before you wire this into production, define your eval criteria: numeric consistency checks, footnote-to-cell association accuracy, merged-cell expansion correctness, and cross-table reconciliation pass rates. Build a golden dataset of at least 20 regulatory filings with known table structures and expected outputs. Run the prompt against that dataset and measure failure modes—silent null returns, misassociated footnotes, merged cells split incorrectly, and totals that don't sum to their components. If your failure rate on numeric fields exceeds 2%, add a validation repair loop or escalate to human review. The prompt is a component in a pipeline, not a standalone solution.

This prompt template is designed for data engineering teams who need to extract structured data from tables embedded in regulatory filings. These tables often contain merged cells, multi-page continuations, and footnoted values that generic extraction prompts mishandle. The template uses square-bracket placeholders that you replace with your specific document, schema, and validation requirements before wiring it into an extraction pipeline. The output is designed to be machine-readable JSON that includes cell-level provenance (source page, paragraph, line) and explicit footnote association, enabling downstream audit trails and cross-table reconciliation.

textCopy
You are an expert regulatory filing data extraction system. Your task is to extract all tabular data from the provided [DOCUMENT] into a strict JSON schema. The document is a regulatory filing that may contain complex tables with merged cells, multi-page continuations, and footnoted values.

## INPUT
[DOCUMENT]: The full text of the regulatory filing, including all table captions, headers, body rows, and footnotes. Preserve page numbers and paragraph markers if present.
[TABLE_IDENTIFIER]: A specific table caption, number, or description to target. If empty, extract all tables.
[OUTPUT_SCHEMA]: The target JSON schema for the extracted table data.
[CONSTRAINTS]: Additional extraction rules, such as unit normalization, date format requirements, or domain-specific validation rules.
[EXAMPLES]: Few-shot examples of correctly extracted tables from similar filings, showing the expected output format and handling of edge cases.
[RISK_LEVEL]: The risk classification for this extraction (LOW, MEDIUM, HIGH, CRITICAL). This determines the strictness of validation and whether human review is required.

## EXTRACTION RULES
1. Identify all tables matching [TABLE_IDENTIFIER]. For each table, capture the caption, column headers, and all data rows.
2. For merged cells, repeat the value in all spanned cells and add a "merged_spans" property indicating the original cell range.
3. For multi-page tables, reconcile continued rows and add a "continuation_of" property linking table fragments.
4. For any cell with a footnote marker, extract the footnote text and associate it with the cell via a "footnotes" array. Each footnote object must include the marker, text, and source location.
5. For every extracted cell value, include provenance: {"page": <number>, "paragraph": <number>, "line": <number>} based on the source document.
6. Normalize numeric values according to [CONSTRAINTS]. If a unit is specified, include it in the "unit" field. If a value is a range, use "value_low" and "value_high".
7. If a cell is empty, explicitly output null with a "null_reason" field (e.g., "empty_cell", "redacted", "illegible").
8. If a table cannot be fully extracted due to document quality, output what you can and add an "extraction_issues" array describing the problems.

## OUTPUT FORMAT
Return a single JSON object conforming to [OUTPUT_SCHEMA]. The top-level object must include:
- "tables": array of extracted table objects
- "extraction_metadata": object with "tables_found", "tables_extracted", "issues_summary", and "confidence_overall"
- "validation_warnings": array of any consistency issues detected (e.g., numeric totals that don't sum, cross-table mismatches)

## VALIDATION
Before returning, perform these checks:
- Verify that all numeric columns sum correctly where a total row is present. Flag discrepancies in "validation_warnings".
- Check that all referenced footnotes exist in the document.
- Confirm that multi-page tables have consistent column counts across pages.
- If [RISK_LEVEL] is HIGH or CRITICAL, mark any uncertain extractions for human review with "review_required": true.

## RESPONSE
Return ONLY the JSON object. No markdown fences, no commentary.

To adapt this template for your pipeline, replace each placeholder with concrete values. The [OUTPUT_SCHEMA] should be a complete JSON Schema definition that matches your downstream ingestion contract—include required fields, enum constraints, and type definitions. The [CONSTRAINTS] placeholder should specify domain rules like 'all currency values in USD millions' or 'dates in ISO 8601 format.' The [EXAMPLES] placeholder is critical for complex tables: provide at least two few-shot examples showing how merged cells, footnotes, and multi-page continuations should appear in the output. For high-risk filings, set [RISK_LEVEL] to HIGH or CRITICAL to enable the human-review flagging behavior. After extraction, always run the output through a schema validator and a numeric consistency checker before allowing it into downstream systems. If the validation step fails, use a repair prompt or escalate for human review rather than silently accepting malformed data.

This prompt is designed to be a single step within a larger document intelligence pipeline, not a standalone solution. The implementation harness must handle pre-processing (page splitting, OCR cleanup), prompt execution, post-processing (schema validation, numeric reconciliation), and routing decisions (retry, human review, or ingestion). The core integration pattern is: split the filing into manageable chunks, run extraction on each chunk, merge and reconcile the outputs, validate against business rules, and route low-confidence or inconsistent records for human review before they enter downstream systems.

For model choice, use a model with strong structured output support and a large context window—GPT-4o or Claude 3.5 Sonnet are appropriate starting points. The prompt expects a JSON schema as part of [OUTPUT_SCHEMA], and you should enforce this using the model's native structured output or function-calling mode rather than relying on text parsing. Implement a validation layer immediately after extraction that checks: (1) all required fields are present and non-null unless explicitly flagged as missing, (2) numeric columns sum correctly against stated totals in the filing, (3) footnote references resolve to actual footnote text, and (4) cell provenance citations point to real page and row locations. Any record failing validation should trigger a single retry with the validation error message appended to the prompt context. If the retry also fails, route the record to a human review queue with the original page image, the failed extraction, and the specific validation errors.

Logging and observability are critical for regulatory workflows. At minimum, log the prompt version, model version, input chunk identifier, raw output, validation results, retry count, and final disposition (passed, repaired, or escalated). Store these logs immutably for audit purposes. For multi-table filings, implement a cross-table reconciliation step after all individual tables are extracted: compare shared dimension values, verify that subtotals roll up correctly, and flag any inconsistencies as reconciliation errors. These errors should always route to human review, as they often indicate extraction mistakes or genuine filing discrepancies that require judgment. Avoid the temptation to auto-repair reconciliation failures—silent corrections in regulatory data pipelines create audit risk that outweighs any automation gain.