CSV Generation Prompt for Financial Transactions

This prompt is designed for engineering teams building AI-powered accounting integrations, financial data pipelines, and bookkeeping automation. It forces the model to produce RFC 4180-compliant CSV output with strict column ordering, consistent decimal precision, proper escaping, and mandatory header rows. Use this when your downstream system is a CSV parser, an ERP import module, or a general ledger that rejects malformed files. The ideal user is a backend engineer or AI builder who already has structured or semi-structured transaction data and needs the model to normalize it into a predictable CSV contract before ingestion.

Do not use this prompt for JSON or XML output, for human-readable summaries, or when the transaction source is a scanned image without OCR preprocessing. The prompt assumes the input data is already digitized and interpretable. It is not a document-reading prompt. If you need to extract data from PDFs or images first, pair this with a document intelligence prompt before the CSV generation step. The prompt also assumes you have defined a target column schema; if your downstream system requires a dynamic or user-defined schema, you will need to adapt the [OUTPUT_SCHEMA] placeholder carefully and add a schema validation step in your harness.

In production, this prompt is most effective when wrapped in a validation harness that checks for RFC 4180 compliance, correct column count per row, consistent decimal places, and proper escaping of commas, quotes, and newlines. For high-stakes financial workflows, always add a human review step or a reconciliation check against source totals before the CSV is ingested into a general ledger. The prompt itself is a formatting contract, not an accuracy guarantee. If the input data contains ambiguities, the model may guess; your harness should catch those guesses before they become ledger entries.

This prompt is designed to be placed in the system instructions of your AI model, with the raw transaction data passed in the user message. It enforces column ordering, escaping rules, decimal precision, and header conventions that downstream accounting systems expect. The prompt includes explicit validation instructions so the model checks its own output before returning it, reducing the chance of malformed CSV reaching your ingestion pipeline.

textCopy
You are a financial transaction CSV generator. Your only job is to produce a valid, well-formed CSV string from the transaction data provided in the user message. You must follow every rule below without exception.

## OUTPUT SCHEMA
Generate a CSV with exactly these columns in this order:
[COLUMN_ORDER]

## FIELD CONSTRAINTS
[FIELD_CONSTRAINTS]

## CSV FORMATTING RULES
1. Always include a header row as the first line.
2. Use commas as delimiters. Do not use semicolons, tabs, or pipes.
3. Wrap any field containing a comma, double quote, or newline in double quotes.
4. Escape double quotes inside quoted fields by doubling them ("" becomes """").
5. Use RFC 4180 line endings (CRLF).
6. Represent decimal values with exactly [DECIMAL_PRECISION] decimal places, rounded using standard rounding rules.
7. Format dates as [DATE_FORMAT].
8. Do not include a trailing newline after the last data row.

## VALIDATION CHECKLIST
Before returning the CSV, verify:
- The header row matches [COLUMN_ORDER] exactly, including case and spelling.
- Every data row has the same number of columns as the header row.
- No field contains unescaped delimiters or quotes.
- All decimal fields have exactly [DECIMAL_PRECISION] decimal places.
- All date fields match [DATE_FORMAT].
- The total number of rows matches the number of transactions provided.

## CONSTRAINTS
- Return ONLY the CSV string. No markdown fences, no explanations, no surrounding text.
- If the input data is missing a required field, use an empty string for that field.
- If a transaction amount is ambiguous or unparseable, set the amount field to "ERROR" and include all other available fields.
- Do not invent, infer, or hallucinate transaction data not present in the input.

## RISK LEVEL
[RISK_LEVEL]

To adapt this prompt, replace each square-bracket placeholder with your specific requirements. For [COLUMN_ORDER], provide a comma-separated list like date,description,amount,currency,category,reference_id. For [FIELD_CONSTRAINTS], specify per-field rules such as amount: positive decimal, must not be zero or reference_id: alphanumeric, max 20 characters. Set [DECIMAL_PRECISION] to 2 for most accounting systems. Set [DATE_FORMAT] to YYYY-MM-DD or your system's expected format. For [RISK_LEVEL], use high if the CSV feeds directly into a financial system of record; this signals the model to apply stricter validation and refuse ambiguous data. If you set risk to high, you must also implement a human review step in your application layer before the CSV reaches your accounting system.

Integrating this CSV generation prompt into a financial application requires treating the model output as an untrusted data source that must pass through a deterministic validation layer before it reaches any accounting system. The prompt itself enforces column ordering, escaping rules, decimal precision, and header conventions, but the application harness is responsible for verifying that the model actually followed those instructions. Start by wrapping the model call in a function that accepts the [INPUT] transaction data, injects it into the prompt template, and captures the raw string response. Never pass the raw model output directly to a downstream system—always validate first.

The validation layer should perform at minimum these checks: (1) confirm the first line matches the expected header exactly, including case and column order; (2) verify the column count in every data row matches the header column count; (3) check that numeric fields parse to the declared decimal precision without trailing or missing digits; (4) validate that string fields containing commas, quotes, or newlines are properly escaped according to RFC 4180; (5) confirm the delimiter character is consistent throughout and matches the declared delimiter; and (6) reject any row where the transaction date, amount, or account identifier is missing or unparseable. If any validation check fails, log the failure with the raw model output, the specific validation error, and the input context before proceeding to retry logic.

Implement a retry loop with a maximum of three attempts. On each retry, append the structured validation error message to the prompt as additional [CONSTRAINTS] context, instructing the model exactly which row and which field failed and what correction is required. Use a lower temperature setting (0.0–0.2) for retries to reduce output variability. If all retries are exhausted and validation still fails, route the transaction batch to a human review queue with the original input, all failed outputs, and the accumulated validation errors. For high-value or regulated transactions where errors carry compliance risk, consider requiring human approval on every batch regardless of validation status by setting [RISK_LEVEL] to 'high' and gating the output behind a review step.

Model choice matters for this workflow. Prefer models with strong instruction-following and structured output capabilities. If your provider supports structured output modes or JSON mode, consider generating JSON first and converting to CSV in application code rather than relying on the model to produce valid CSV directly—this eliminates entire classes of formatting errors. Log every model call, validation result, retry attempt, and human review decision to an audit trail that includes the prompt version hash, model identifier, timestamp, and input hash. This audit trail is essential for financial compliance and debugging production failures. Avoid using this prompt for real-time payment initiation or ledger posting without a human-in-the-loop gate, and never allow the model to compute financial totals independently—always recalculate sums, balances, and derived fields in application code after extraction.