Scope it as a measurement, not a feature

"Extract the data from uploaded invoices."

That sentence has appeared in a signed contract, and it is not a specification. It does not say which fields, on which documents, to what accuracy, or what happens when it fails. Every one of those is a decision, and leaving them unstated does not remove them — it just means they get decided later, by whoever is under the most pressure.

An AI feature is not done when it works. It is done when it hits a number, on a defined set of inputs, with a defined path for everything else. Without those three, there is no finish line.

The four numbers that decide buildability

Before anyone quotes, these have to exist. Not estimates — measurements.

1. What is the input distribution?

Not "invoices". A hundred real documents, sampled rather than chosen, with the mix stated: how many are native PDFs, scans, photographs? How many suppliers? How many pages? What proportion are in a second language?

This is the number that most often changes a project. A team says "invoices" and means the twelve clean templates they see daily; production includes photographs taken in a warehouse.

2. What accuracy is required, per field, and what does wrong cost?

Per field, because a single number hides the field that matters. And the cost of an error, because that is what sets the threshold:

total must reach 99.5% precision — a wrong total posts a wrong payment. poNumber at 95% is fine; wrong ones are caught at reconciliation. description is best-effort; it is used for search.

Three fields, three different targets, three different amounts of work. A single "99% accurate" applies the hardest requirement to everything.

3. What happens to the exceptions?

The most commonly skipped question and the one that decides the operating cost. If accuracy is 96%, what happens to the other 4%? Who looks at them, how fast, in what interface, and what does that person cost?

A feature with no answer here has decided the exceptions go into the database unmarked. That is a decision; it should be an explicit one.

4. What volume, and what latency?

Documents per month, peak burst, and whether a person is waiting. These decide architecture — batch versus synchronous is a 50% cost difference — and they decide whether the review queue is staffable.

The scoping document

What we produce before quoting. Each field exists because omitting it has caused a problem.

## Inputs
- Document types:        invoices, credit notes
- Sample size:           120, stratified by source
- Source mix:            58% native PDF, 31% scan, 11% photo
- Suppliers:             ~40, of which 6 are 70% of volume
- Pages:                 1-4, median 1
- Languages:             EN, DE
- Volume:                ~40,000/month, peaks 3x at month end

## Fields
| Field | Target | Metric | Cost of error | Exception path |
|---|---|---|---|---|
| total | 99.5% | precision | wrong payment | review queue, 4h SLA |
| issuedOn | 99% | precision | wrong terms | review queue |
| supplier | 99% | precision | wrong ledger | review queue |
| lineItems | 95% | recall | manual entry | review queue |
| poNumber | 95% | precision | caught downstream | write with flag |

## Exceptions
- Expected rate:         4-8% of documents, at least one field
- Reviewer:              existing AP team, ~2 FTE-hours/day at volume
- Interface:             field-level, cropped image, keyboard-only
- Unresolvable:          returned to supplier, tracked

## Latency
- Path:                  asynchronous, email on completion
- Target:                95% within 30 minutes of upload

## Out of scope
- Handwritten invoices   (route to manual, no attempt)
- Non-EN/DE             (route to manual)
- Multi-currency lines within one invoice

That Out of scope section is the most valuable part of the document. It is the only place where the answer "we do not attempt that" is written down before someone asks why it did not work.

Write the eval before writing the feature

The strongest thing you can do at scoping time is agree the test.

If both sides sign off on a golden set and a target, "done" is a number both can compute. If not, done is an argument, and the party with more patience wins it.

Practically: build the golden set during scoping, from the sample. It takes a day or two, it belongs to the client, and it is the artefact the whole engagement is measured against.

The useful side effect is that the baseline is measured before the price is agreed. Sometimes a straightforward implementation already hits the target and the project is smaller than everybody expected. That is worth finding out at the start.

Two shapes that mean "stop"

The target is unreachable on those inputs. If 15% of the sample is handwritten and the requirement is 99% on all fields, the answer is no, and the right time to say it is now. Either the target moves, the input set narrows, or the project does not happen. All three are better than discovering it in month five.

Nobody will own the exceptions. If the answer to "who reviews the 5%?" is that nobody has capacity, the feature does not work at any accuracy level short of perfect, and perfect is not available. A pipeline whose exceptions have no owner is a pipeline that writes errors into the system of record and hopes.

Scoping is a paid phase

The document above takes a few days and requires real documents, real conversations with whoever handles exceptions today, and a measured baseline.

Doing it free, in a sales conversation, produces the version based on three sample PDFs and an optimistic description — which is precisely the input that produces the estimate everybody later regrets. A client unwilling to fund a small scoping engagement before a large build is telling you something about how the rest of it will go.

More in what an AI feature costs to build, seven questions for an AI contractor, and the AI reliability audit.