What happens to the documents the AI can't handle?

No desk gets the same document twice. Customers change their forms, people write on printouts, and paperwork that ought to agree often doesn't. Four kinds come up again and again:

• A new layout. A customer moves to a new ERP and its POs come out with the fields in new places. Nothing on the page is wrong; it just isn't where it was.
• A handwritten change. A buyer crosses out a printed quantity and writes another, or initials a new price in the margin. For checks and notes, section 3-114 of the Uniform Commercial Code settles contradictory terms: handwritten beats typewritten and printed, and words beat numbers. A PO isn't a check, so which figure binds is for your counsel and your customer to say, not software. This isn't legal advice.
• A missing reference. No PO number on the invoice, no release number on the order, a job name where the job number belongs.
• Numbers that disagree. The price on the PO isn't the price on the quote, or the invoice bills for more than was received.

Even check clearing, one of the most automated paper jobs there is, writes its exceptions into the rules. The Federal Reserve Banks' answers to common questions about electronic check processing give three reasons an item comes back as a non-conforming image: it fails their image quality standards, its routing number is invalid or missing from their sort table, or it isn't eligible for image clearing, such as a foreign item. The sending bank fixes the reported problem and puts the item back into collection, imaged again or as the original paper check. Each rejection has a reason and a way back in.

A document job needs the same. It stops on the item and says why: the document, the field, what the page shows and what is missing or in conflict. Quantity printed as 40, 48 written over it and initialed. No PO number, and two open POs for this vendor at this price. The draft keeps everything it could read, and nothing about that item moves until a person decides.

ISO 9001 already describes what happens next. Its clause 8.7, on control of nonconforming outputs, asks that output which doesn't meet requirements be identified and controlled so it isn't used or delivered by mistake, and names the ways to deal with it. A corrected item is checked again before release, and the record keeps the problem, the action, any concession and who decided. On a document desk:

• Correct it. The person fixes the field, and the draft is checked again before it goes anywhere.
• Hold it or send it back. The order waits, or the invoice returns to the vendor with a request for the PO number.
• Tell the customer. The buyer is asked which quantity they meant.
• Accept it under concession. Someone with the authority takes the higher price this once, and the record says who.

Choose the 20 to 30 documents so that some went wrong on the day, including the ones your team still talks about. A tidy set shows how well the drafts read and nothing about what they do when the paper is wrong. Then write the exceptions into the success criteria: the kinds the drafts must flag, and the rule that a confident wrong value on one of them counts as a miss.

Old documents also tell you how each one ended. The exceptions your team handled left marks: a revised order keyed a day later, a credit memo, an email asking a vendor for the PO number, a note that the buyer was called. Your reviewer, the person on your team who knows the work best, can list those cases before any draft exists. Every document then lands in one of four places:

• Both caught it. The draft flagged it, and your team treated it as an exception too.
• Only your team caught it. The record shows a correction or a call, and the draft carried on as if nothing were odd. Look hardest at these: in a live run, each would reach the approver looking routine.
• Only the draft caught it. It stopped on something your team keyed straight through. Some of these are noise; some are real problems nobody noticed at the time.
• Neither caught it. The trouble surfaced later as a short payment, a return or a credit weeks afterward. Only old documents can show these, because the later record already exists.

No test hands you a right share of the work to send back. Decide kind by kind, by how hard a mistake would be to undo. Canada's federal Directive on Automated Decision-Making, last updated in June 2025, does this for government systems. It defines an automated decision system as any technology that assists or replaces the judgment of human decision makers, and sorts each one into four impact levels, partly by reversibility: easily reversible and brief at the bottom, irreversible and perpetual at the top. Unstructured or incomplete data pushes a system higher, which describes most of the paper a back office receives.

At the two lower levels a system may decide without direct human involvement, with people checking quality and free to step in. At the two higher levels the final decision must be made by a human, with that involvement clearly defined. A back office can borrow the shape:

• Always to a person. A change to where money goes, a customer or vendor not yet on file, a price that differs from what was agreed, a promise to a customer.
• Settled by the draft, evidence shown. A part number your desk maps the same way every time, a ship-to already on file, a regular customer's usual unit. A person still approves each item in the live month; these just carry no flag.
• Not seen enough yet. Anything the sample held only once or twice stays an exception until there is more to go on.

A flag sent to someone who can't act on it is a delay, not a control. The Article 29 Working Party, Europe's data protection authorities writing on automated decisions under the GDPR (guidelines last revised in 2018), set out when a person's part counts: oversight that is meaningful rather than a token gesture, by someone with the authority and competence to change the decision, who considers all the relevant data. Routinely applying the system's output without real influence on the result doesn't count.

Those guidelines concern decisions about people, not invoices, and this isn't legal advice, but the test fits a desk. Whoever gets the flag needs the authority to hold an order, call the customer or accept a price, the knowledge of what this customer meant last time, and the source document, not only the draft's summary. The guidelines also ask that the degree and stage of human involvement be recorded. On a desk, that is a log line per flag: who picked it up, when, and what they did.

The same log keeps your list honest. Canada's Directive asks for human overrides to be documented and used to find and correct issues, and at its higher levels it requires training in how to evaluate the system's decisions and, if necessary, override them. Log every flag, and every change a person makes to a draft that wasn't flagged, with its reason. An exception corrected the same way every time is a rule waiting to be written down; a change nobody flagged is a gap in the list.

Clean documents are the part of the job a new hire learns first. Exceptions are why you keep experienced people on the desk: they know which customer always means the written number, which price change was agreed on a call, and when a missing PO number means an order nobody approved. A job built to flag instead of guess leaves those calls with them and takes away the keying around them.

Our free AI proof of concept is built to show this before you commit. It runs on copies of 20 to 30 documents your team already processed, sent after an NDA, with nothing touching a live system and no login to any of yours. The owner names your reviewer, and the success criteria, including the exceptions the drafts must flag, are agreed first. Your reviewer sets each draft beside what your team actually did, and that call decides it. If the answer is yes, the job then runs in your systems for about 30 days, with every item approved by someone on your team before it posts.