Extraction instructions

Sometimes what you want cannot be said in a field name. That is what descriptions and instructions are for.

Reach for them in this order — the cheapest fix first.

1. Fix the name

Most "the extraction is wrong" problems are a field called amount on a document with three amounts. Renaming it total_including_tax fixes more than any instruction will.

Try this before anything else. See defining what to extract.

2. Add a description

A Field description is one sentence saying what you mean. It travels with the field and applies every time.

Descriptions handle ambiguity. Use them whenever a reasonable person could pick the wrong value.

3. Add extraction instructions

Extraction instructions handle rules and edge cases — conditional logic, formatting, fallbacks. They come in two scopes.

Per field

The box labelled AI instructions under each field in Fields & Tables.

• "If the invoice shows an early-payment discount, use the discounted total."
• "Strip any currency symbol and return the number only."
• "If there is no PO number, use the invoice number instead."

Parser-wide

In the parser's Settings, applying to every extraction that parser runs — including Full Document Extraction.

• "Normalise all dates to YYYY-MM-DD."
• "Amounts are in GBP unless the document says otherwise."
• "Ignore anything in the footer or the terms and conditions."
• "If a value appears twice and disagrees, prefer the one in the summary table."

Use parser-wide for conventions that hold across the whole document type. Use per-field for a rule about one value.

Writing instructions that work

Be specific about the failure you are fixing. "Extract the total correctly" says nothing. "Use the total after discount, not the gross total" is actionable.

Say what to do when the thing is absent. "If no delivery date is shown, leave it empty" is better than silence — it confirms empty is the right answer rather than something to hunt for.

Prefer constraints to prose. If a field should be one of three values, make it a Select field. A constrained type is more reliable than an instruction asking for the same thing.

One rule per instruction. A paragraph containing four rules is harder to satisfy than four instructions.

What instructions cannot do

Worth knowing before you spend an afternoon on it:

• They cannot conjure absent information. If the due date is not printed, no instruction produces one. Parsli will leave it empty, which is the correct behaviour.
• They cannot reliably do arithmetic across documents. Matching an invoice to a purchase order is not extraction. That is a job for your system, or a premium workspace.
• They do not fix a bad field type. If a currency amount is typed string, it comes back as a string no matter what the instruction says. Fix the type.

A worked example

An invoice parser producing a total that is sometimes gross, sometimes net.

Wrong first move — instruction: "always get the right total". Nothing changes; it was already trying.

What actually works:

1. Rename total → total_payable
2. Description: "The final amount the customer must pay."
3. Instruction: "If an early-payment discount is shown, use the discounted amount. Otherwise use the gross total including tax."

Three changes, from most to least general. Re-run the same document after each so you know which one moved the result.