Structured Extraction vs Plain Text: When It's Worth a Credit

There are two different things a computer can do with a photograph of a document, and confusing them is the most common reason people either overpay or get output they cannot use.

The first is reading: turning the marks on the page into characters. You get back the words, in roughly the order a person would read them.

The second is understanding: working out what those words are. Which of the six numbers on this receipt is the total. Which line is the vendor and which is the customer. Where one line item ends and the next begins.

The first is cheap and runs on everything. The second costs more, because it is a genuinely harder job, and on most plans it is metered. Here is how to decide which one a given document needs.

The test: does a human read the output, or does software?

That is the whole rule. Everything else is a special case of it.

A human reads it → plain text is fine. You are copying a paragraph, searching a scanned book, checking a serial number, pasting a passage into a document. A person is already in the loop and a person can find the total on a receipt in about half a second. Paying extra to have a model find it first buys you nothing.

Software reads it → you want structure. You are pushing a supplier invoice into your accounts, filling a spreadsheet column, triggering a workflow when an amount exceeds a threshold, matching a payment to a record. Software cannot find the total on a receipt. It needs to be handed total: 1247.50 as a labelled value, and it needs to be handed the same shape every time regardless of which supplier's layout the document came in.

If you find yourself reading the extracted text and then typing part of it somewhere else, that is the signal. You are the integration, and you are doing it by hand.

What structure actually looks like

Take a supplier invoice. Plain text gets you something like:

NORTHGATE SUPPLIES LTD
Invoice 88413    14 August 2026
Oak trim 12ft        268.00
Delivery              42.00
VAT                   62.00
Total due            372.00

Perfectly readable. Completely unusable by a program, because nothing in it says which token is which. A parser has to guess that the last number is the total, and it will be right until the day a supplier puts "Amount paid: 0.00" underneath it.

Structured extraction gets you fields:

{
  "vendor": "Northgate Supplies Ltd",
  "invoice_number": "88413",
  "invoice_date": "2026-08-14",
  "line_items": [
    { "description": "Oak trim 12ft", "amount": 268.00 },
    { "description": "Delivery", "amount": 42.00 }
  ],
  "tax": 62.00,
  "total": 372.00
}

Same document, same words. The difference is that the second one can be sent somewhere without a human in the middle, and that is the only difference that matters to your Tuesday.

Why layout-specific readers beat one general model

A second thing worth knowing: "structured extraction" is not one operation. An invoice, a medical form, a contract and an insurance claim are not the same shape, and a model tuned for invoice layouts is meaningfully better at invoices than a general model that has seen everything once.

On the Business plan those four run as separate processors rather than one, and you pick the one that matches what you are holding. That sounds like a minor implementation detail and is not: the difference between a general reader and a layout-specific reader on a dense claim form is usually the difference between fields you can trust and fields you have to check.

How metering should work, and what to watch for

Understanding costs more to run than reading, so nearly every product meters it. That is fair. What is not fair is how the meter is usually shaped.

The common pattern is a quota that, when you exceed it, forces you to the next plan — often a large jump — for the rest of the billing period. You had a busy month, so now you have an annual contract.

The shape we settled on instead is a quota plus a unit price. Business includes 100 structured extractions a month; past that they are $0.35 each, as a line on your invoice. A month where you process 140 documents costs the plan plus fourteen dollars, and then next month goes back to normal. No tier jump, no renegotiation, no call.

Whichever tool you use, these are the questions worth asking:

1. What happens on document 101? A hard stop, an overage price, or a forced upgrade? All three exist in the market and they are wildly different products.
2. Is a failed extraction charged? A document the model could not read should not cost the same as one it read.
3. Does a retry count twice? If you re-run a page because the first photo was poor, find out whether that is one unit or two.
4. Is plain text metered too? It generally should not be — reading is cheap. If both are on the same meter, you are paying understanding prices for reading work.

A workflow that spends credits sensibly

The pattern that costs the least while staying useful:

• Scan everything as plain text. It is unlimited on both paid plans, it is fast, and it makes every document searchable. This is your default.
• Escalate to structured extraction only where the output leaves your hands. Supplier invoices going into your books. Claim forms going to an insurer. Anything feeding a spreadsheet column or a webhook.
• Batch the escalations. Twenty supplier invoices on a Friday is twenty credits either way, but doing it in one pass means you notice a systematically misread field once instead of twenty times.
• Watch the first month's meter and then stop watching it. Most solo operators land well inside a hundred a month and never think about it again. If you land outside it, you now know your real number and can price the work accordingly.

The short version

Plain text is for when you are going to read it. Structure is for when you are not.

If a person is going to look at the output anyway, do not pay a model to understand a document that a human is about to understand for free. If the output is going into software, do not accept a wall of text and then become the integration yourself.

Most people need both, on different documents, in the same week — which is the actual reason the two are priced differently rather than bundled into one number.