Entity Extraction Prompt for Financial Filings

This prompt is designed for financial analysts, compliance officers, and data pipeline engineers who need to convert dense SEC filings, annual reports, and earnings releases into structured, machine-readable records. The primary job-to-be-done is high-recall extraction of key financial entities—company names, monetary amounts, filing types, dates, and regulatory references—while preserving the complex relationships between them, such as parent-subsidiary hierarchies and restated versus originally reported figures. The ideal user is someone integrating this extraction into a downstream database, audit system, or analytics dashboard where schema consistency and source traceability are non-negotiable.

Use this prompt when you are processing 10-Ks, 10-Qs, 8-Ks, proxy statements, or annual reports where the document structure is semi-predictable but the entity density is high. It is particularly effective when you need to distinguish between a parent company and its subsidiaries, flag monetary amounts that have been restated from prior periods, and normalize filing dates to a standard format. The prompt expects a raw text input, typically extracted from a PDF or HTML filing, and requires you to specify an output schema, a set of normalization rules (e.g., ISO 8601 for dates, numeric-only for monetary values), and a confidence threshold below which entities should be routed for human review.

Do not use this prompt for real-time news feeds, informal earnings call transcripts, or marketing materials where the entity types and relationships are less formalized. It is not designed for extracting sentiment, forward-looking statements, or qualitative risk assessments—those require separate classification or summarization prompts. Additionally, this prompt is insufficient on its own for full audit-grade extraction; you must pair it with a validation layer that checks for schema compliance, a retry mechanism for malformed outputs, and a human review queue for entities flagged with low confidence or conflicting source evidence. If your use case involves cross-document entity resolution (linking the same company across multiple filings), you will need a separate resolution prompt that consumes the output of this extraction step.

This prompt template is designed to be the core instruction set for extracting financial entities from dense regulatory documents. It uses square-bracket placeholders for all dynamic components, allowing you to swap in the specific filing text, your desired output schema, and any operational constraints. The template is structured to enforce strict JSON output, handle complex relationships like subsidiaries, and flag restated or estimated figures, which are critical for compliance workflows. Before integrating, review the [OUTPUT_SCHEMA] and [CONSTRAINTS] placeholders to ensure they match your downstream database or analytics contract.

textCopy
You are an expert financial data extraction system. Your task is to analyze the provided financial filing text and extract structured entities according to the exact schema and constraints defined below.

---

## INPUT
### Filing Text
[INPUT]

### Context
Filing Type: [CONTEXT]

---

## EXTRACTION TASK
Extract the following entity types from the filing text. For each entity, you must provide the canonical form, the verbatim mention text, and a confidence score between 0.0 and 1.0.

1.  **Companies:** Extract all mentioned organizations. For each, identify its role (e.g., Registrant, Subsidiary, Counterparty) and its relationship to the primary filer.
2.  **Filing Metadata:** Extract the filing type (e.g., 10-K, 8-K), the reporting period end date, and the filing date.
3.  **Monetary Amounts:** Extract all monetary values. Normalize them to a consistent unit (e.g., 'millions of USD') and flag any that are marked as 'restated' or 'unaudited'.
4.  **Regulatory References:** Extract mentions of specific regulations, acts, or accounting standards (e.g., 'Regulation S-K', 'ASC 606').

---

## OUTPUT SCHEMA
You must output a single, valid JSON object with no additional text or markdown. The object must conform to this exact structure:
[OUTPUT_SCHEMA]

---

## CONSTRAINTS
- **Null Handling:** If an entity type is not found, return an empty array `[]` for that key. Do not omit the key.
- **Confidence:** A score of 1.0 means the entity is explicitly stated and unambiguous. A score below 0.7 means the entity is implied or ambiguous and should be flagged for human review.
- **Restated Figures:** For any monetary amount that is a restated figure, set the `"is_restated"` field to `true` and include the original value in the `"original_value"` field if available.
- **Subsidiaries:** For subsidiary companies, include the parent company's canonical name in the `"parent_company"` field.
- **Evidence:** For every extracted entity, you must include a `"source_quote"` field containing the exact, short text span from the filing that justifies the extraction.

---

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by defining your [OUTPUT_SCHEMA] as a strict JSON Schema object. This is the most critical step for downstream reliability. For example, a monetary_amounts item might require value, unit, is_restated, and original_value fields. The [CONTEXT] placeholder should be filled with known metadata, such as the filing type, to help the model disambiguate roles. The [RISK_LEVEL] field can be set to a value like "high" to instruct the model to be more conservative in its confidence scoring, automatically routing more items for human review. After copying, test the prompt with a golden dataset of filings where you know the exact expected output to calibrate the confidence thresholds and catch schema compliance errors early.

This prompt is designed to be called as a single step within a larger document processing pipeline, not as a standalone chat interface. The application layer is responsible for document chunking, context assembly, and output validation before the extracted entities ever reach a downstream system. For SEC filings and annual reports, you should split documents into manageable sections (e.g., by Item number or major heading) and assemble each request with the section text, the filing metadata, and a copy of the output schema. The prompt expects [INPUT] to contain the raw section text, [CONTEXT] to carry filing-level metadata (company name, filing type, period end date), and [OUTPUT_SCHEMA] to define the exact JSON structure for entities, amounts, dates, and regulatory references.

Validation must happen in the application layer immediately after the model responds. Parse the JSON output and check that every monetary amount includes a currency and scale (millions, thousands), every date resolves to ISO 8601, and every regulatory reference (e.g., 'Reg S-K Item 303') matches a known pattern. Reject records where subsidiary relationships are asserted without a parent entity reference. For high-stakes filings like 10-Ks and 20-Fs, implement a confidence threshold: if the model's self-reported confidence for any extracted entity falls below 0.85, route that entity to a human review queue. Log every extraction attempt with the prompt version, model ID, input hash, and validation result so you can trace errors back to specific document sections or prompt changes. Use a model with strong JSON mode support (GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to minimize variance across repeated extractions.

Do not use this prompt as the sole extraction step for filings that will be ingested into a general ledger, regulatory submission, or investor-facing data product. The prompt handles entity recognition and basic normalization, but it does not perform cross-document reconciliation, restated-figure tracking, or XBRL tag alignment. Those responsibilities belong to separate pipeline stages. Wire the validated output into a staging table where a second process resolves extracted entity names against a master company database (using the Entity Resolution Prompt for Financial Filings if needed) and flags discrepancies between extracted figures and previously reported values. For any filing where the model returns a null or empty array for a required entity category, trigger an alert rather than silently ingesting incomplete data.