Automate the work you can check first

Before any document automation project, I want one question answered... what will you check the machine's answer against once it hands one back? If there's something to compare it to (a purchase order, a ledger, a total that has to add up), you're probably in good shape. If the only check is a smart person rereading the whole thing, the demo doesn't matter much, because you'll end up doing the work twice.

This isn't my idea. FourWeekMBA's piece on Ramp and coding agents sums it up as "automation scales exactly as far as verification does," and even though the article is about software, I think it explains document work better than any accuracy benchmark I've read.

The easy point to skim past is that coding didn't get automated first because programming is easy -- it went first because software is full of cheap, fast checks, like whether the code compiles, whether the tests pass and whether the deploy preview renders. The argument is that you can only trust an agent to finish work when someone can confirm it's done without redoing it. Ramp is the big example, since its chief product officer said on Lenny's Podcast that Inspect, Ramp's internal coding agent, is responsible for 75% of the company's pull requests. The article is careful with that figure, pointing out it was self-reported on a podcast rather than audited, and that 75% of pull requests is not 75% of engineering work, so I hold it loosely too... the principle is the useful part, not the number.

Documents follow the same rule

Take an ordinary invoice. The total can be matched to a purchase order, the line items have to add up, and the vendor either exists in your master list or it doesn't, so nearly every value has something to compare against and most of those checks can run without a person. A contract risk is different, because a note like "this indemnity clause is unusual" can't be matched to anything, and the only real check is someone who knows contracts reading it. Fraud is harder still, since the whole point of fraud is that it looks right on the surface.

That split matches where the industry is. Forrester's look at agentic AI in accounts payable says that for many organizations invoice capture has already become a lights-out process, and it lists exceptional invoice handling and invoice matching among the use cases delivering meaningful value today, with agents routing only the truly ambiguous cases for approval. Fraud and risk management, by its account, is earlier in maturity. Forrester doesn't frame any of this as checkability (that framing is mine), but the order comes out the same, with automation furthest along wherever the answer is easiest to check.

Production numbers tell a similar story. Osher Digital, writing about invoice processing patterns, reports 88 to 94 percent straight-through extraction with no human touch across its last six AP rollouts. One step further along, at three-way matching for a construction client handling around 1,200 invoices a month, the auto-match rate is 71 percent, auto-flag is 4 percent, and the remaining 25 percent lands in a middle band where a human reviews it. That's Osher's own client work, so treat it as one firm's experience, not an industry average.

I like the second set because the 25 percent isn't really a failure -- it's the system being honest about what it could and couldn't check on its own. Reading a number off a page is easy to verify, but deciding whether an invoice that doesn't quite match its PO is still fine to pay takes more context.

So when you pick the next thing to automate, don't get pulled toward whichever demo looked best. List the document jobs your team handles and ask four questions of each. Is there something to compare the answer against, like a PO, a contract, last month's figure or some other system of record? Can that comparison run without a person, so it's a lookup or a sum rather than a judgment call? When it's wrong, is it obviously wrong... a total that doesn't match fails loudly and gets caught, while a misread clause fails quietly. And how long does checking one take compared with doing it, because if checking takes nearly as long as doing the job from scratch, automation saves you very little. Sort by those answers and the jobs near the top are where automation tends to hold up in production, and the ones near the bottom are where a great demo turns into a person quietly redoing everything.

For the hard jobs, build the review screen first

The jobs at the bottom still matter, and they're often the most expensive. I just wouldn't start by automating the decision -- I'd make the check cheap instead. For contract review that means putting each extracted point right next to the clause it came from, so a reviewer can confirm or reject it in seconds rather than hunting through the whole document. Then measure how long a check takes, because as that drops you can trust the machine with more. Forrester's advice for buyers points the same way, since it says to judge vendors on demonstrated performance in production (accuracy, exception reduction, matching success) rather than on feature lists or conceptual demos.

I'll admit contract analysis looks far more impressive on a slide than invoice matching does. But the boring, checkable work is where teams get their time back, and it builds the trust you'll need for the harder stuff later. That's how we think about Workbricks too, which is why we show the reviewer the source page next to each value, to make checking cheap.

Check first, then automate.