The paperwork chase, and the one tool that shortens it
Buy this instead of hiring
Somebody in your office opens an email at 8:40 on a Monday with the subject line "docs attached." Eleven files. Two are photos of paper taken at an angle, one is last year's certificate, one is the right form with the second page missing, and one is a duplicate of something that came in Thursday. She spends forty minutes sorting it, then writes back asking for the three things that are wrong. The client replies Wednesday. The job sits until then.
That is the recurring job: opening what people send you and deciding whether it is usable before it goes any further. Contractors do it with insurance certificates and lien waivers. Practices do it with client records. Distributors do it with supplier paperwork. It is nobody's title and it eats a person's morning.
It is three questions, not one
Asking "is this document okay" is really asking three things. Is it the thing we asked for — pure matching against a list. Is it legible and complete — clerical, a human eye, no thought. And does it actually support the decision we need to make — that one is judgment, and it is the only one worth your senior person's time. In most shops the first two consume the morning and the third gets four seconds at the end.
What shipped
Suralink, which sells an agentic automation platform to accounting firms and their clients, announced on August 12, 2026 a Client Document Prescreen Agent that flags incorrect or missing documents and works with the client in real time to fix them, alongside a Multi-Level Vouching Agent and a Version Compare Agent that identifies changes between drafts. That is questions one and two, handled at the door, before the file reaches your person.
What it does not do is worth more than what it does. It prescreens inside Suralink's own request-list portal — attachments that land in someone's inbox or on a shared drive are outside it. "Correct and complete" is whatever your request list says it is, so if nobody has built that list, there is nothing to check against and the agent has no opinion. And nothing here keys the numbers into your job costing or accounting system. Someone still types.
If you are a practice already running client requests through a portal, this is a straightforward buy. If your documents arrive by email, write the request list first. That document is the real asset; the software is just something that reads it.
Delete the all-green report and the Monday meeting stops existing
Reorganize and the job disappears
It's 6:50 on Monday morning and your operations manager is at the printer with the daily production report. Four pages. Yesterday's output by line, scrap, downtime, labor hours against standard. He reads all four pages looking for the one number that's wrong. At 7:30 he walks six other people through the same four pages so they can also look for the one number that's wrong. Somewhere around 7:50 somebody says "line 3 was down a while Thursday, wasn't it," and the real conversation finally starts, with ten minutes left.
If you're a contractor it's the job-cost and progress report. If you're a distributor it's the stock report and the open-order list. If it's a practice, it's the AR aging that gets printed and walked through every Friday. Same job, different paper. The job has a name in every one of these businesses and the name is some version of going through the numbers to see if anything's wrong.
Going through the numbers is four different jobs wearing one coat
Watch what actually happens between the printer and the decision, because it isn't one activity.
First, somebody assembles the numbers. Pure clerical. Export, paste, format, distribute.
Second, somebody compares each number to where it's supposed to be. That is a rule. Output should be above X. Gross margin on this job type should land between Y and Z. Nothing sits past 60 days. It feels like skill because the ranges live in one person's head, but a rule you can say out loud is a rule, not judgment.
Third, somebody figures out which bad number is the cause and which are symptoms. Labor variance is high because the machine was down, and the machine was down because the part didn't come. This is diagnosis, and it's mostly rule-shaped too, once you write down which things cause which.
Fourth — and only fourth — somebody decides what to do. Do we run Saturday, do we call the customer, do we stop shipping this account, do we eat it. That's the part that needs a person with authority, experience, and something at stake.
Now count where the time goes. Nearly all of it goes to the first three. The fourth one gets whatever minutes are left, because it comes last.
An airline captain describes the version of this that got deleted
Captain Alexandre Gandini flies 737s for GOL Airlines. In an interview published by the Lean Enterprise Institute in August 2026, he describes what cockpits used to be: banks of analog gauges and pointers, pilots memorizing what yellow and red meant on each one, burning most of their attention confirming that things were normal. Some aircraft carried a flight engineer whose entire job was watching the systems during the flight. His description of the result is the important part — all that information got in the way, and spotting an actual anomaly often took a long time.
Here is what finding a hydraulic failure used to require, per Gandini. Before Boeing's EICAS, the crew noticed a symptom — the flight controls felt wrong, or the autopilot dropped out. Then they compared pressures and fluid levels across each hydraulic system to work out which one had failed. Then they identified the fault. Then they opened the right procedure. Then they decided whether to continue or divert.
With EICAS, the aircraft names the specific failure. The crew opens the checklist. The crew decides: continue or divert.
Five steps became three, and notice which three survived. The scanning didn't get faster. The comparing didn't get more efficient. In the design philosophy Gandini calls the dark cockpit — which he dates to the late 1970s and early 1980s — every indication of things running normally was removed. Indicators became lights that stay off. No light, no warning. If something goes wrong, a light comes on, with an audio alert for critical failures, and it points at the system.
The flight engineer's job did not get automated. It stopped existing. There was nothing left to monitor, because normal operation produces no output at all.
Your dashboard is the halfway version, and halfway is where it stalls
Gandini describes glass cockpits — screens replacing pointers — as the first generation, and the dark cockpit as a later iteration. That distinction is worth your attention, because almost every owner who tries to fix the Monday meeting builds a glass cockpit and stops. A prettier dashboard, color-coded, on a TV in the hallway. All that does is make the first two steps faster while keeping all five. Somebody still has to look. Somebody still has to interpret. The meeting still happens.
The dark version looks like this instead. Nothing arrives when the week is normal. When a job crosses its margin threshold, or a machine exceeds its downtime allowance, or an account passes 60 days, one message goes to one named person and it says which thing, by name, with the number. No report. No scan. No walkthrough.
Steps one, two, and three are gone — not shortened. The 7:30 meeting doesn't get trimmed to fifteen minutes. There is nothing to hold it about.
Borrow one more detail from the 737, because it's the piece people get wrong. Gandini describes a hierarchy: a Master Caution light comes on in front of the pilot, a panel indicates fuel, and only then does he look at the overhead panel and find the low pressure light. One thing gets your attention, a second thing names the area, a third thing names the condition. Not forty alerts of equal weight. If you build forty, you've rebuilt the wall of gauges with sound effects, and Gandini's own warning applies: overload people with information and the real problem becomes invisible.
Four reasons not to do this
Don't do it if you're watching a small number of things. If you have three jobs running or four accounts that matter, you already hold them in your head, and you'll spend real money to be told what you know. The math starts working somewhere north of twenty or thirty things nobody can carry — open jobs, active SKUs, machines, aging accounts.
Don't do it if the tolerances aren't written down anywhere. No alert can fire on a threshold that has never been stated. If "normal margin" lives in your estimator's head and shifts by job type, your alerts will be wrong for two months and everyone will learn to ignore them. Sit down and write the ranges: for each thing we watch, what number is fine, what number is not, and who gets told. That document is worth more than any automation you'd buy afterward, and you may find you don't buy anything.
Don't build anything until you've run the cheap test. Stop sending the all-green report for three weeks. Say nothing. See who asks. Most owners discover that two of the seven recipients notice, and one of them only wanted a single line off page three. You can hand that person that line.
And don't start with a purchase. As of 2026, the accounting package, the CRM, and the industry system you already run all have some form of rule-based alerting or saved exception view buried in them. The constraint was never the software. It was that nobody had ever written down what abnormal means.
The lump-sum deposit nobody can code by rule
Nothing off the shelf fits
A $41,380 deposit lands from a general contractor on a Tuesday. Your bookkeeper knows the name, so she prints the AR aging for that customer, runs her pen down the column, and starts adding invoices until she gets close. She gets to $43,700 across four progress bills. She's $2,320 off. Now she's guessing: retainage, a freight deduction, or that credit memo from last fall nobody ever applied. She emails the GC's AP clerk and the deposit sits there until someone answers or month end forces it.
That single act — apply the payment — is really three questions wearing one coat. Whose money is this is clerical; the bank feed usually tells you. Which invoices does it cover is arithmetic, and it's arithmetic a computer is far better at than a person with a pen, because it has to consider partial pays and combinations. Why is it short is judgment, and it's the only one that needs your bookkeeper. It also gets the least attention, because by the time she reaches it she's already burned forty minutes on the middle question.
Xero's Auto Bank Reconciliation beta has been chipping steadily at the coding-and-matching half of this. Its August 2026 update lets you fix an account code on the Reconciled page without unwinding the reconciliation, shows whether each line was settled by match, rule, memory, prediction or by hand, and revisits transactions when a bill or receipt shows up late. It acts only where confidence is high and leaves the rest for you. Xero also says outright that one payment covering multiple invoices is still on the list of things it's working on — which is precisely the case that eats the afternoon.
The thing that doesn't exist is a cash-application layer: something that reads the remittance detail wherever it actually arrives — email body, PDF stub, customer portal, check memo — solves the deposit against open AR including partials, short-pays, retainage and early-pay discounts, and writes back one payment split across many invoices with a job code on each line. What it can't close to the penny goes to a queue with ranked candidate combinations and a probable deduction reason, not a blank "unmatched."
Don't build it if most customers pay one invoice per check — that's a handful a month, and she'll clear them faster than you can tune a queue. And don't build it if your customers send bare ACH deposits with no remittance at all. The fix there is asking them for a stub, or turning on a payment portal. A solver with nothing to read is just a slower pen.
Corrected August 25, 2026: the announcement date was August 12, not August 13.