Verified Document Extraction: What the Certificate Proves [2026]

If you have ever paid for document extraction — invoices into your accounting
system, a scraped directory into a spreadsheet, a decade of messy CSV exports
normalized into one schema — you have probably asked some version of the same
question: how do I know these numbers are right without re-reading every
document myself? The honest answer from most pipelines, human or AI, is that
you don't. You get a data file. The checking is your problem.

We built our extraction service around a different deliverable. Every job
returns two things: the structured data you asked for, and a verification
certificate — a document that states, field by field, what was
machine-verified against the source, how it was verified, and what was not.
This post shows a real certificate from our own test batch and walks through
what each line actually proves, because the certificate is the product; the
data file is just what it certifies.

The problem with "extraction accuracy"

A vendor quoting "99% accuracy" is making a claim about the past — about other
people's documents, measured some other time, by some method you can't
inspect. It tells you nothing checkable about the batch you just received.
When an LLM does the extracting, the failure mode gets quieter: modern models
rarely leave a field blank. Asked for a vendor name the document doesn't
contain, a model will often supply a plausible one. The result reads clean,
loads fine, and is wrong in the one way that is expensive to discover later —
silently.

The fix is not a better model. It is refusing to let any value into the
output without evidence that survives checking, and saying so per field, on
this batch — a certificate that names what it could not verify, instead of an
accuracy percentage that averages away the field you will get burned by.

How the pipeline decides what to trust

Extraction runs in two lanes, and the certificate records which lane every
field came through:

1. Deterministic first. Anything a committed pattern can lift —
   fixed-position fields, labeled lines, CSV columns, HTML selectors — is
   extracted by code, not by a model. Every deterministic value carries an
   exact source location: the page or row it came from and the character span
   it occupies. There is nothing to hallucinate; the value either sits at
   that location in the document or the test suite fails.

2. The model fills only the residue. Fields the parser cannot lift go to
   a language model — and the model is not trusted either. It must return a
   verbatim evidence quote for every value, and each value then passes three
   fail-closed gates: the quote must be present; the quote must appear
   verbatim in the source document and contain the value (so the model
   cannot cite one line and answer from another); and the quote must actually
   entail the claim, checked by a separate verifier model (so a "Bill To:"
   line quoted as the vendor name fails, even though the quote is real).

Fail-closed means exactly that: if a gate cannot run — verifier down,
timeout, malformed response — the field fails. A field that fails any gate is
not deleted and not guessed; it lands in the certificate under needs
review, with machine-readable reasons, excluded from the verified set.
Nothing is silently shipped.

The failure the third gate exists for

The first two gates sound sufficient until you watch a model fail in the
specific way they cannot catch. Suppose an invoice carries both a vendor
block and a "Bill To:" block, and the model is asked for the vendor. It
quotes the "Bill To:" line — a real line, verbatim, present in the document —
and returns the customer's name as the vendor. Gate one passes: a quote was
supplied. Gate two passes: the quote is genuinely in the document, and the
returned value is genuinely in the quote. Every string-level check agrees,
and the answer is still wrong, because the quote does not mean what the
field claims it means.

That is what the third gate checks: whether the cited quote actually entails
the statement "the vendor is this value," judged by a separate
natural-language-inference verifier that never saw the rest of the document.
The premise is deliberately the quote alone — gate two already proved the
quote is real, so gate three's only job is killing misattributed citations.
In calibration against our verifier, true field claims score 0.995 or higher
in entailment against their own supporting quote; the "Bill To:"-as-vendor
case scores as unsupported and the field lands in needs-review, where a
human resolves it with both blocks in front of them. A pipeline without this
gate does not merely miss the error — it certifies it, with a real quote
attached, which is worse than no certificate at all.

A real certificate, line by line

Below is the certificate from our invoice-extraction test batch — two fixture
invoices we wrote ourselves, run through the identical pipeline a paid batch
gets. We publish the fixture run because client data never appears on this
site; what matters is the shape of what you receive.

Verification Certificate — invoices_to_json
Jobspec SHA-256:      40b57c25b0a9…
Source invoice_001.pdf SHA-256: eceb404b76ed…
Source invoice_002.pdf SHA-256: 9ec86ddce90a…

records: 2 · fields: 10 · deterministic: 6 · llm: 4
verified: 10 · needs_review: 0

Human spot-check sample (1 of 10 verified):
invoice_number = INV-2026-0042 · deterministic
  invoice_001.pdf, page 1, chars 24–37
  "INVOICE  Invoice Number: INV-2026-0042  Invoice Date: 2026-05-14 …"

What each part proves:

• The hashes at the top pin the certificate to exact bytes. The jobspec
  hash proves which extraction rules ran; the per-document hashes prove which
  files they ran against. If anyone later disputes a value, there is no
  argument about which version of which document was processed.

• The lane counts (six deterministic, four model-extracted here) tell you
  how much of the batch never touched a model at all. On highly structured
  documents that fraction is large, and those fields carry page-and-character
  provenance rather than model output.

• Verified vs. needs-review is the honest core. "Verified 10, needs
  review 0" on this batch means every field affirmatively passed every gate
  that applies to it — not that failures were dropped. When a batch does have
  unverifiable fields, they are listed with reasons, and you know exactly
  where human eyes are required before the data is trusted.

• The spot-check sample is drawn deterministically — seeded from the
  jobspec and document hashes, so the sample is identical on re-run and we
  cannot cherry-pick easy rows after the fact. It exists so a human can audit
  the machine's verification in minutes, not hours.

What this is for, and what it costs

The service fits three recurring shapes of work, matching the three job types
the pipeline ships with today: batches of invoices or similar semi-structured
PDFs into JSON or CSV for your accounting or analytics stack; directories of
HTML pages into a clean tabular dataset; and inconsistent CSV exports —
years of slightly different column layouts — normalized into one agreed
schema. In every case the deliverable is the same trio: the data file, the
per-field audit trail, and the certificate.

The path from this page to a delivered batch has three steps:

1. Read the certificate above — it is the entire promise, shown rather
   than described. If your documents are the kind where a wrong value costs
   real money, the needs-review list alone is worth more than the data.

2. Tell us about one batch at
   ustechautomations.com/partner?interest=doc-extract
   — document type, rough count, and the fields you need. We reply the same
   working day with the jobspec we would commit to, including which fields we
   expect to extract deterministically.

3. The paid batch: $249 per batch of up to 200 documents, one-time, to
   your agreed schema, delivered within two business days as the data file
   plus per-field audit trail plus the signed certificate. If our certificate
   marks a field needs-review, that is us telling you where not to trust us
   yet — the honesty is the deliverable, and it is priced once, not per
   surprise.

That $249 figure is our service fee for a defined batch, stated here so you
can decide before contacting anyone whether the economics work for your
documents. Larger or recurring volumes get a jobspec-specific quote through
the same form.

The uncomfortable disclosure

We publish weekly data products in other domains, and we hold ourselves to
the same rule everywhere: claims you cannot check are marketing. So, plainly:
the certificate shown above is from our fixture batch, not a customer
engagement, and this extraction service has not yet delivered a paid batch to
an external customer. You would be early. What we can prove today is the
machinery — the gates, the certificate, and the refusal to ship a value we
could not verify — and that proof is reproducible on your documents within
two business days of a jobspec agreement. Nothing on this page is legal,
accounting, or financial advice; the fee above is our own service price, and
extraction output should still pass whatever review your domain requires
before money moves because of it.