Bank Statement Text to Transaction Records Prompt Template

This prompt is designed for fintech platform engineers who receive unstructured or semi-structured transaction data from upstream systems—OCR pipelines, PDF parsers, or other models—that failed to produce valid, typed JSON. Its job is to convert that narrative text into a clean, predictable array of transaction records. The output contract includes normalized dates, a consistent debit-credit sign convention, a category classification, and a verified running balance. The primary goal is to repair malformed data before it enters a ledger, reconciliation engine, or compliance database, preventing downstream processing failures.

Use this prompt when you have a batch of bank statement text that needs to be ingested into a structured system but cannot be parsed by a deterministic script. It is ideal for scenarios where the source text has a consistent narrative pattern but lacks a machine-readable schema. The prompt's strict output schema and built-in verification logic (like running balance checks) make it a powerful post-extraction repair tool. However, you should not use this prompt for real-time payment processing, fraud detection, or any workflow where a hallucinated transaction could trigger an irreversible financial action without a human in the loop. It is a repair and normalization tool, not a real-time decision engine.

Before integrating this prompt, ensure you have a clear understanding of the expected input format and the downstream system's schema requirements. The prompt template uses placeholders like [INPUT] and [OUTPUT_SCHEMA] that you must populate with your specific data and contract. The next section provides the copy-ready template. After adapting it, you must build a robust implementation harness—including output validation, retry logic, and human review for high-value or high-risk transactions—as described in the 'Implementation Harness' section. Never deploy this prompt directly to production without automated checks that verify the mathematical consistency of the output.

This prompt template is designed to be copied directly into your application's prompt layer. It instructs the model to parse raw bank statement text and output a clean JSON array of transaction records. The template uses square-bracket placeholders for all dynamic inputs, constraints, and schemas, making it easy to wire into a production harness where these values are populated at runtime. The core instruction enforces strict output formatting, field-level type discipline, and a critical running-balance verification step that catches many common extraction errors before the data enters your ledger.

textCopy
You are a precise financial data extraction engine. Your task is to convert the provided bank statement text into a structured JSON array of transaction records.

## Input
[INPUT]

## Output Schema
Return ONLY a valid JSON array of objects. Each object must conform to this exact schema:
[OUTPUT_SCHEMA]

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

## Critical Verification Step
Before outputting the final JSON, perform this check internally:
1. For each transaction, calculate the expected running balance by applying the transaction amount to the previous running balance.
2. Compare your calculated running balance to the running balance stated in the bank statement text for that transaction.
3. If there is a mismatch, flag the transaction by setting the `"balance_verified"` field to `false` and include the `"calculated_balance"` in the output.
4. If the stated running balance is missing from the source text, set `"balance_verified"` to `null`.

## Risk Level
[RISK_LEVEL]

## Tools
[TOOLS]

To adapt this template, replace each square-bracket placeholder with the concrete values for your specific bank statement format and application requirements. The [OUTPUT_SCHEMA] should be a detailed JSON schema defining fields like transaction_date (ISO 8601 string), description (string), amount (number, positive for credits, negative for debits), category (string or null), and running_balance (number or null). The [CONSTRAINTS] placeholder is where you enforce rules like 'debit amounts must be negative' or 'dates must be parsed from MM/DD/YYYY format.' The [RISK_LEVEL] placeholder should be set to high for financial data, which signals your harness to enable additional validation, logging, and human review gates. After copying this template, the next step is to build the implementation harness that populates these placeholders and validates the model's output against your schema before it touches any financial system of record.

This prompt is designed to be called as part of a structured extraction pipeline, not as a standalone chat interaction. The typical flow is: raw bank statement text enters the system, the prompt converts it into a typed transaction array, and a post-processing harness validates the output before it reaches any database or downstream system. Because financial data is high-risk, the harness must enforce debit-credit sign consistency, running balance verification, and required field presence before accepting any record.

Model choice and invocation pattern: Use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format: { type: 'json_object' }, Claude with tool-use extraction, or Gemini with controlled generation). Always set temperature=0 to minimize variance in numeric fields. Call the prompt with the raw statement text injected into the [STATEMENT_TEXT] placeholder. If the statement exceeds the model's context window, chunk it by statement page or month boundary and merge results in the application layer, checking for duplicate transactions across chunks by matching date, description, and amount within a small tolerance.

Validation and retry logic: After receiving the model response, run a multi-step validator: (1) confirm the output is valid JSON with a transactions array, (2) verify every record has non-null date, description, and amount fields, (3) check that debit and credit values are mutually exclusive per record (one must be zero or null when the other is populated), (4) recalculate the running balance from the first transaction forward and compare against the model's running_balance field with a tolerance of ±0.01, and (5) flag any transaction where the sign of the net change doesn't match the direction of the balance movement. If validation fails, construct a repair prompt that includes the original statement text, the failed output, and the specific validation errors, then retry once. If the retry also fails, route the record to a human review queue with the raw statement, the failed extraction, and the validator error log.

Logging and audit trail: Log every extraction attempt—including the raw input, the model's raw output, validation results, and any retry attempts—to an append-only audit store. This is critical for fintech compliance and debugging. Include a pipeline_run_id and transaction_batch_id in every log entry so you can trace a single statement through extraction, validation, repair, and eventual ingestion. Never silently drop failed records; even rejected extractions should leave an audit artifact explaining why they were rejected.

Integration with downstream systems: Once a transaction batch passes validation, transform the records into your canonical transaction schema before writing to the ledger or database. Map the prompt's category field to your internal chart of accounts using a lookup table or a secondary classification prompt if the model's category doesn't match your taxonomy. For running balance verification, treat the model's running_balance as a cross-check against your system of record—never as the authoritative balance. The authoritative balance must come from the bank's official statement or API, with the extracted balance serving only as a reconciliation signal.

What to avoid: Do not use this prompt for real-time transaction processing or payment initiation. Do not skip the running balance verification step, even if the model appears confident—arithmetic errors are common in long transaction sequences. Do not store raw bank statement text in logs without redacting account numbers and PII first. And do not treat a passing validation as proof of correctness; sampled human review of extracted transactions should be part of your regular quality assurance cadence, especially for high-value or unusual transactions.