Check the results

Extracted documents appear on the parser's Documents page, one row each, with the extracted values shown as columns.

A document is Extracting while it is being read — its value columns show as placeholders — and Complete when it is done. The filter row above the table narrows to Processed, Processing, Preview, or Failed.

Open a row to see the source document alongside what was pulled out of it.

Reading a result

Three things are worth attention.

Empty values. A field the engine could not ground in the document comes back empty — not guessed. This is deliberate, and it is a feature: a blank is a fact about your document, whereas a confident wrong number is a liability. An empty due_date usually means no due date was printed.

Confidence. Values the engine is less sure about are flagged. Low confidence is not an error; it is a request that a human look before the number goes into a ledger.

Tables. Table fields come back as rows. If a table is missing rows, that is a field-definition problem rather than a reading problem — see below.

Diagnosing a wrong extraction

Work in this order. It is roughly the order of how often each one is the actual cause.

1. Is the field name ambiguous?

By far the most common cause. amount on a document with a subtotal, a tax line, and a total is a coin toss. total_including_tax is not.

Rename it. This fixes more than any other single change.

2. Is the type wrong?

A currency amount typed string comes back as a string — symbol, separators and all. A date typed string comes back however it was printed.

Set decimal for money, date for dates, number for counts.

3. Would a description help?

One sentence: "The final amount payable, after tax and any discount." Descriptions resolve ambiguity that a name alone cannot carry.

4. Is this a genuine edge case?

Conditional rules belong in Extraction instructions — "if there is an early-payment discount, use the discounted total".

5. Is the value actually in the document?

Worth checking before spending an afternoon on the first four. If the due date is not printed anywhere, no configuration produces one. Empty is the correct answer.

Reprocessing

Once you have changed a field definition, run documents again to pick up the change. Reprocessing charges pages again, at the same rate.

Two habits that keep this cheap:

• Iterate on one representative document, not the whole batch. One tells you nearly everything a hundred would.
• Use a short document while tuning. A one-page sample costs one page; the forty-page statement costs forty each time you try something.

Missing table rows

If a table returns fewer rows than the document shows, the usual causes are:

1. Ambiguous column names. total inside a table on an invoice that also has an overall total. Rename to line_total.
2. The table was modelled as numbered fields. item_1_price, item_2_price cannot grow. Use a Table field. See tables and nested data.
3. Rows continue on a page you did not send. Check the source document is complete.

Documents that fail entirely

A failed extraction is refunded — credits are reserved beforehand and returned on failure, so a failure costs nothing.

If the same document fails twice, the document is usually the problem: a corrupt PDF, an encrypted file, or a scan too degraded to read. Try opening it yourself; if you cannot read it, neither can the engine.

What to do about low-confidence values

Do not ignore them, and do not treat them as errors. Route them.

• Flag required fields so their absence is visible rather than silent.
• Check before posting to a ledger. See accounting systems.
• Handle empties in code. A null total should reach a person, not become a zero. See webhooks.

The point is not to eliminate uncertainty — some documents genuinely are ambiguous — but to make sure uncertainty reaches a human instead of a database.