In this guide 6 sections
Constant corrections usually have one narrow cause, not a weak model. Count corrections by field, by supplier or sender and by step in the approval queue. The pattern points to messy samples, one badly read field, one odd source, or a step that should be a plain rule.
Start by counting, not by complaining
Staff say the drafts are wrong all the time. That feeling is real, but it cannot be fixed. A tally can. A tally turns a vague mood into a ranked list, and a ranked list tells you which of three or four fixes to try first.
Every correction in the approval queue should record who changed it, which field, the old value, the new one and the supplier or document type the draft came from. If your queue does not store this, add it first. Without it you are guessing.
After two weeks, sort the log three ways: by field, by source and by step, and you will usually find that a few cells hold most of the corrections.
- Corrections per field, such as due date or tax number
- Corrections per supplier, sender or customer
- Corrections per step, such as extraction, coding or reply wording
- Corrections per person reviewing
When one field is the culprit
Suppose the delivery date is changed in most drafts while quantities are almost never touched. The model is not weak. The date is probably ambiguous, written day-first on some purchase orders and month-first on others, or tucked into a footer beside the dispatch note number.
Read twenty corrected examples side by side. Do not skim. Look for the shape of the mistake: a swapped format, a missed line on a second page, a stamp over the number. A date such as 04/05/2026 reads as April on a US form and May on a UK one, and the model may pick either.
Fix the field, not the whole system. A format rule, a clearer instruction or a few more examples of that exact field, taken from the two worst sources, usually removes it.
When one supplier or sender is the culprit
A single supplier with a scanned, skewed invoice can produce more corrections than fifty clean ones, and the log shows this at once if you sort by sender. Sorting the log by sender also exposes the opposite case, where one habitual sender produces nearly all the clean results and hides how weak the rest are.
Decide what that supplier deserves. Ask them for a digital copy, add their layout as a named template, or send their documents straight to manual entry. Any of these beats correcting the same error weekly. Pick one.
Check the sample set too. If the examples you trained on were tidy PDFs and half your mail is phone photos, the drafts will struggle on exactly those. Add real, messy samples.
When a step should be a rule instead
Sometimes people make an identical fix on every draft. A customer code always gets a prefix. A cost centre always follows the department. That is not judgement, it is a rule.
Move it out of the model and into plain code or a lookup table, because rules are exact, free of drift and easy to explain to an auditor. A lookup table kept in a spreadsheet that the finance team owns lets them change a code mapping on Monday without waiting for a developer release.
Keep the model for the parts that really vary, such as reading free text on a handwritten delivery note, and let fixed logic handle what never varies.
When can confident cases skip review?
Once a field or a source has run for several weeks with almost no corrections, test letting it through without review. Use the model’s own confidence score and set a threshold from the correction log, not a hunch, then send anything below it to a person.
Release in steps. Auto-approve one field from one clean source, such as the invoice total from your steadiest supplier, then sample a few each week to confirm it holds. If corrections rise, pull it back. Keep the reviewer’s tool open on a sample of released items, so a drifting field shows up as a handful of corrections and not as a customer complaint.
Review the log monthly. Note the date each change was made, so that a later rise in corrections can be tied to a specific edit. Your next step is simple: add the field, source and step columns to the queue export and run the first tally.
Correction log review sheet
Three small tables share a printed sheet, split by field, by source and by step. Each has columns for items processed, items corrected, the typical fix and the decided action, such as new rule, new template or leave. A closing box notes the date any case was released from review.
Open a blank worksheet to printQuestions owners ask
How many corrections is too many?
There is no universal number. Compare each field with its own history, not with a single target for the whole queue. A field whose corrections are falling week on week is healthy, and one that has risen for two weeks running needs a look at its samples.
Should we retrain the model every time staff correct something?
No. Most fixes are better made by a lookup rule, a clearer instruction or a named supplier template, because those change in minutes and can be undone. Retrain only when the log shows the same kind of error spread across many sources and no rule or template can catch it.
Is the reviewer part of the problem?
Sometimes. If one person corrects far more drafts than the others, compare their edits with a colleague’s edits on the same documents. They may be fixing style, not errors. Agree what counts as a real correction.
Can we stop reviewing altogether?
For low-risk fields from steady sources, yes, with sampling. For payment amounts, legal wording or anything a customer will read, keep a person in the loop and sample even the clean cases.