How we make AI read a PDF once and never pay for it again

An insurance broker in the UAE spends real time every week on one task: taking quotes from several insurers, each a PDF in its own format, and turning them into a side-by-side comparison a client can understand. Premiums, networks, inpatient and outpatient limits, maternity, dental, waiting periods. It is careful, repetitive reading.

AI can do that reading. The usual way to use it is to send every PDF to a model and ask for the fields. That works, and it costs money on every page, forever. When we built Compare, we took a different route: the model reads a layout once, writes down how to read it, and never needs to read that layout again.

Why does per-document AI extraction get expensive?

Because insurers do not change their quote format every week. A broker receives a steady stream of quotes, but they come from a limited set of insurers and administrators, each using a handful of templates. Paying a model to rediscover where the annual premium sits on the same template, again and again, is paying for knowledge you already bought.

The question we asked was not "how do we make each read cheaper?" It was "how do we stop paying for reads we have already done?"

There is a second cost that per-document extraction hides: inconsistency. A model asked to read the same template twice can return slightly different answers. A written recipe returns the same answer every time for the same document, which makes the output easier to check and easier to trust.

How does Compare recognise a document it has seen before?

Two checks run before any model is involved. Both are free.

Content dedup

Every upload gets a content hash. If the same file has been processed before, Compare recognises it before extraction runs. Re-uploading a set of quotes, which happens more than you would expect, costs nothing instead of paying for the same reads twice.

Layout fingerprinting

Compare extracts the text and tables from each PDF, falling back to OCR for scanned quotes. From that structure it builds a stable fingerprint of the layout: not of the numbers in it, but of how the document is put together. Two quotes from the same insurer template share a fingerprint even when every figure differs.

The fingerprint is the key to everything else. It tells Compare whether it already knows how to read this document.

What happens the first time Compare sees a layout?

A new fingerprint goes to the model once. The model's job is not to extract this quote's values. Its job is to write a recipe: a set of deterministic rules that say where each field lives in this layout and how to pull it out.

The recipe covers Compare's field schema: 80 extraction targets across 11 sections. Those include premiums, network, inpatient and outpatient benefits, maternity, dental and optical, wellness, policy terms and eligibility (waiting periods, age bands, deductibles, out-of-pocket maximums, out-of-network reimbursement) and service depth (direct-billing hospitals, pharmacy network, claims turnaround). The schema is a configuration file, so adding a field does not need a database change.

Recipes are versioned. A reviewer can promote a new version or roll back to an earlier one from the web interface.

What happens every time after that?

The next quote with that fingerprint is read by the recipe. No model call, no tokens, no marginal cost. The same goes for the one after that, and every one after that, until the insurer changes the template.

In steady state, Compare runs with no model key at all. The model is a tool for learning new layouts, not a cost on every document.

What if the layout drifts?

Insurers do change templates, sometimes subtly: a moved column, a renamed benefit, an extra page. A rule that was right last month can quietly start reading the wrong cell. Saving money is worthless if the comparison is wrong, so the recipe library heals itself.

• Disagreements are recorded. Whenever a saved rule loses to a live model read of the same document, Compare records the disagreement against that layout.
• A nightly sweep looks for drift. Layouts whose rules keep losing are flagged as drifted.
• Reviewers are told once. A reviewer gets one notification per escalation, not one per document, and a one-click option to rebuild the recipe.
• Promotion resets the count. When a rebuilt recipe is promoted, that layout's drift record is cleared, so the next sweep judges the rules that are running now, not the old ones.

The point is that a broken rule surfaces as a flagged layout with a fix ready, not as a wrong number in a client proposal.

How do you know the numbers are right?

For brokers who want more certainty, Compare has an optional consensus mode. It runs a ladder of model reads and only accepts a value when two independent reads agree. If they disagree, the field goes to a person in the review queue rather than into the comparison.

Consensus is backed by further checks:

• Coherence checks catch values that do not make sense together.
• Vagueness checks catch answers that are technically present but too vague to compare.
• A review queue collects anything the checks could not settle, so a person decides.

Consensus costs more than reading by recipe, because it calls the model more than once. That is the trade: you choose it where certainty matters more than cost.

What stops a batch from running away?

New layouts cost money, and a batch full of formats Compare has never seen could cost a lot. So every batch runs under a spend ceiling. When it is reached, Compare stops spending on that batch, so a set of unseen layouts cannot run up a bill.

That is the same principle we apply on every AI product we run: a hard limit set in advance, so cost is never a surprise.

What does the broker see?

Not any of this. Every upload is opened for a named client before any file is processed, and that client stays attached through the batch, the review queue and the finished comparison, so no deliverable is ever unattributed. Fingerprints, batch identifiers, recipe versions and extraction costs are engineering details, and Compare keeps them off every screen a client can see. The broker opens a client, uploads the quotes, and receives a comparison in Excel, HTML, PDF or on a dashboard: frozen header rows, the best value per benefit highlighted, a weighted ranking with a recommended option, and no blank rows for benefits no insurer quoted.

Around that sits the rest of the brokerage's work: a client directory, request-for-quote intake linked through to the comparison, shareable proposals with maker-checker approval, and renewals compared against the plan the client bought, benefit by benefit.

What can you take from this for your own documents?

The pattern is not specific to insurance. It fits any process where documents arrive in a limited set of recurring formats: supplier invoices, delivery notes, bank statements, freight rate sheets, lab reports.

• Measure how many layouts you really have. Often it is far fewer than the number of documents.
• Recognise duplicates before you spend. A content hash is free; a model read is not.
• Use the model to learn, not to repeat. Let it write rules for a layout, then run the rules.
• Watch the rules. Record when they disagree with a live read, and flag layouts that drift.
• Cap the spend per batch. Pause when the limit is reached.
• Keep a person on anything uncertain.

We build the same approach into our AI document processing projects: learn each layout once, check the rules, and pay the model only for what is new.