From Scanned Contract to Structured Record, with the Source Shown

A contract is signed. A purchase order is issued. A vendor submits a bond certificate. Each of these arrives as a document, and none of them is governed until it becomes a record.

That conversion is one of the least discussed and most expensive activities in capital delivery. Somebody reads the document, finds the values that matter, decides which existing record they belong to, and types them in. On a large programme this happens thousands of times, it is done by people whose time is worth considerably more than data entry, and it is where a meaningful share of data quality problems originate.

Extraction is the obvious application of AI to this, and every vendor in the market is building it. What separates a useful implementation from a dangerous one is not the extraction.

A contract is not governed until it becomes a record. That conversion is one of the least discussed and most expensive activities in capital delivery.

What the capability does

In PMWEB 2026, the assistant reads a source document — a scanned contract, a purchase order — and extracts the information needed to create the corresponding record.

So far this describes every extraction product ever built. Two further behaviours are what make it usable in a governed environment.

Extracted content is matched to the relevant PMWEB entity rather than being used to create a standalone record.

This addresses a failure mode that is easy to underestimate. An extraction engine that reads a change order and creates a change order has done its job by its own measure. But if that record is not connected to the commitment it varies, it is an orphan. It will not appear in the commitment's revised value. It will not show in exposure reporting against the vendor. It exists, it is accurate, and it is invisible to every question anyone will actually ask.

A database accumulating orphan records degrades quietly. Nothing breaks. The totals are simply wrong, and they stay wrong until someone reconciles manually and discovers why.

It shows you where every value came from

Each extracted value is displayed against its location in the source document. The reviewer verifies rather than trusts, and confirms before the record is saved.

This is the design decision that determines whether the capability saves any time at all, and the arithmetic is worth doing explicitly.

Extraction you cannot verify has to be checked in full. Someone opens the source document, reads it, and compares every extracted value against it — which costs approximately what typing the record would have cost, plus the risk that checking is more boring than typing and therefore done less carefully.

Extraction with the source shown is checked by exception. The reviewer's eye goes to the values, sees where each one came from, and stops at the one that looks wrong. The work is no longer reading a document. It is confirming a mapping.

This is the requirement PMWEB places first on its own buyer checklist for AI: can it show the source record behind every number? Extraction is the point at which that requirement is either met or lost. A value that arrives in the becomes, from that moment, a number nobody can account for.

Unverifiable extraction costs what typing costs. Extraction with the source shown is checked by exception. That difference is the entire business case.

Where the gate sits

Nothing is saved without a person. The reviewer confirms before the record is created, and where the AI has prepared updates to an existing record, those updates remain pending until someone applies them.

For an organisation whose contract records feed payment certification, this is not a nicety. A record created from a document without human confirmation is a commercial position taken by a machine, and it will eventually be a commercial position nobody can account for.

What it does not do

One boundary is worth stating clearly, because it is the point where expectations run ahead of the capability.

This reads documents. It does not adjudicate them. A clause that is ambiguous in the contract is ambiguous in the extracted record. Where a document contains terms that conflict with an earlier instrument, extraction will faithfully surface what the document says, and deciding which instrument governs remains a commercial judgement made by a person who understands the contract chain.

That is the correct division, and it should be presented as such rather than glossed. A capability that claimed to resolve contractual ambiguity would be a capability nobody responsible should deploy.

What to establish before you deploy it

Four questions worth answering with your own documents rather than a vendor sample.

First, what is the document estate actually like? Extraction performs differently on a born-digital PDF and on a scanned photocopy of a fax from 2011, and most programmes have both. Test on the worst of what you hold, not the best.

Second, who reviews? The value of the capability is realised at the confirmation step, so it matters whether that step lands with someone who understands what the values mean. Extraction reviewed by someone without commercial context is extraction that gets confirmed without being verified.

Third, what is the exception path? When the reviewer sees a value that is wrong, what happens — do they correct it in place, reject the extraction, or escalate? A capability without a defined exception path produces a queue of documents nobody wants to own.

Fourth, where do the documents go? A scanned contract carries prices, terms and positions a counterparty expects to stay confidential. Establish whether documents processed by the AI leave your tenant, how long they are retained, and whether they are used to train models serving other organisations. As PMWEB's own checklist advises, get the answers in the contract rather than the sales deck.

This reads documents. It does not adjudicate them. That is the correct division of labour, and it should be presented as such rather than glossed.

Next week: generating an adaptive form from a plain-language description, and what that does to the economics of process change.