Output a spreadsheet or a script can read

You do not need to be a programmer for this

The moment you want to do the same extraction over forty documents, you want output that goes into a spreadsheet without hand-editing. That means one of two formats, and both are easy to ask for.

CSV (one line per row, fields separated by commas) opens directly in Excel, LibreOffice Calc or Google Sheets.

JSON (nested key-value structure) is what a script or an app expects.

For most non-programmers, CSV is the right answer and JSON is a distraction. Ask for CSV.

Asking for CSV without the classic failures

Output CSV only. No prose before or after, no code fence, no header row.
Columns, in this order: invoice_number, date (YYYY-MM-DD), supplier,
amount, currency.
- If a field is absent, write NOT_STATED. Do not guess.
- Never use a comma inside a field; replace any comma with a semicolon.
- Wrap the supplier name in double quotes.
- One line per invoice, no blank lines.

Five rules, and each one prevents a failure that will otherwise waste your evening:

Commas inside fields break every column to the right. “Adeyemi Ltd, Nairobi” becomes two columns. This is the single most common CSV failure and one line prevents it.

Prose around the data means you cannot paste straight into a sheet. “Output CSV only” plus “no code fence” handles it.

Inconsistent date formats: 3/4/26 could be March or April, and will differ by row. Specify YYYY-MM-DD and the ambiguity disappears.

Silent invention. Without NOT_STATED, a missing amount becomes a plausible amount. A blank is obvious; a wrong number is not.

Header rows are useful once and a nuisance when you paste in batches. Decide, and say which.

If you do need JSON

Give the exact structure, using an example rather than a description:

Return JSON matching this shape exactly, and nothing else:

{"invoices": [
  {"number": "INV-1042", "date": "2026-03-14",
   "supplier": "Adeyemi Ltd", "amount": 45200.00,
   "currency": "KES", "vat_included": null}
]}

Use null where the document does not state a value.
Amounts as numbers, not strings. No trailing commas.

The example settles a dozen questions a description leaves open. Some APIs also offer structured output or JSON mode, which constrains generation so the result is valid JSON by construction. Use it if you have it: it removes parse errors entirely.

The thing structured output does not buy you

Valid JSON is not correct JSON. A schema guarantees that amount is a number. It guarantees nothing about whether it is the right number.

This is worth saying plainly because the guarantee feels stronger than it is. Every extraction failure you care about (the wrong total picked off an invoice, the date of the purchase order instead of the invoice) passes schema validation perfectly.

The reasoning problem, and its fix

Ask for bare JSON with a risk_score from 1 to 10 and nothing else, and the scores will look arbitrary, because they are. The text is where the work happens, and you asked for the conclusion with the working removed.

The fix is to make room, then tidy:

For each contract, write one sentence naming the specific clause that concerns you most. Then, after all the sentences, output the JSON array of {id, risk_score} only.

Reasoning first, structure last, in one response. You get both, and the sentences let you spot the contract where the reasoning was wrong even though the JSON parsed.

The same applies to classification with confidence scores. A number produced alongside a reason means something; a number produced alone is decoration.

Checking a batch before you trust it

Three checks, each takes a minute:

1. Count the rows. Forty documents should give forty rows. A short count means something was silently dropped.
2. Open it in a spreadsheet. Broken commas show up instantly as ragged columns.
3. Spot-check three rows against the source. Not the first three: pick one from the middle and one from the end, since the end of a long generation is where quality drifts.

If you can run code, a five-line Python script that reads the CSV and prints the row count and any row with the wrong number of fields will catch most of this automatically. That is free, offline, and worth learning if this becomes routine.