In this note
Adding an approval button creates a job for someone. They have to find the source, compare it with the proposal, fix an error, and decide whether the result is usable. A proposal can take a second to generate and several minutes to review.
I'd check that job before counting it as a safety control or a saving. Give a reviewer one case with an error and inspect the choices available when they find it. Then check whether the team can do the same work when twenty cases arrive together.
Put the source beside the proposed fields
Invoice: INV-101
Currency: USD
Total: 120.50
Supplier: Sample Parts. Two replacement valves.{
"action": "draft",
"invoice_id": "INV-101",
"currency": "USD",
"amount_cents": 12000,
"evidence_quote": "Total: 120.50",
"reason": "Draft prepared for review"
}The source says USD 120.50. The proposal says 12,000 cents: USD 120.00. Its quote is real, its invoice ID matches, and its fields have the right format. The amount is still fifty cents wrong. To catch it, the reviewer needs the proposal beside the source document and its revision.
Check the invoice ID, currency, amount, and revision together. A correct quote can sit beside the wrong number or come from an old document. Give the reviewer access to the authoritative source and any conflicting evidence, rather than asking them to trust a summary.
Here the source is clear: correct the draft to 12,050 cents and record why. Keep the initial proposal beside the correction so another reader can inspect it. Accepting that practice draft doesn't approve posting or payment; those actions need separate permission and confirmation.
Let the reviewer do something with the error
| Choice | Evidence, state, and boundary |
|---|---|
| Correct, then accept a draft | Change 12,000 to 12,050 cents, check the source, and retain the reviewer and rationale. This is no posting approval. |
| Reject the proposal | Record the reason and retain the attempted proposal. A bad draft can be rejected even when its fields are invalid. |
| Escalate missing or conflicting evidence | Keep the work with an accountable manual/source owner. An escalation is not an accepted invoice. |
| Pause and resume | Retain fields, disable decisions while paused, and resume deliberately. Pausing a page does not prove durable case ownership. |
| Export the review evidence | Include source revision, initial and final fields, decision, rationale, edits, and timing limits. An editable export is practice data, not an authenticated audit trail. |
A local teaching screen illustrates a weakness in this design: it checks that the source-checked box is ticked and the fields are valid, but doesn't run the separate source-comparison test. Someone can tick the box without comparing the amounts and accept the wrong draft. The checkbox records what the reviewer says they did; it doesn't prove they caught the error. The download here is a paper audit of that behavior, not the screen itself.
The local screen also accepts a typed reviewer name and keeps the decision for the loaded attempt; reloading starts another attempt. Neither behavior is suitable evidence of an authenticated, durable case decision. In your own review service, check how it identifies the reviewer, obtains current sources, and saves the case. Keep draft acceptance separate from permission to act.
Let reviewers reject or ask for help when a source is missing, contradictory, or outside scope. Acceptance shouldn't be the only way to clear the screen. Keep a person responsible for blocked work and send the reason and evidence with it. Check that the receiving team has time; a manual queue doesn't provide free review.
Include a failed save in the audit. The local teaching page warns that its decision is only in memory when browser storage fails and asks for an export. For your service, establish what the reviewer sees and who recovers the case. Reviewers shouldn't have to guess whether clicking accept saved their work.
Set a limit for the burst
Suppose a review takes five minutes, including the source check, correction, and decision. Two reviewers each have thirty minutes for the next batch. That provides sixty minutes of review time, enough for twelve cases on paper. Test the estimate: disputes and interruptions may make five minutes too optimistic.
| Scenario | Demand, declared admission, and overflow |
|---|---|
| Routine: 12 cases, 2 reviewers | 12 × 5 = 60 review minutes; 2 × 30 = 60 available. Admit at most 12; no modeled overflow. |
| Burst: 20 cases, 2 reviewers | 20 × 5 = 100 review minutes; 60 available. Admit at most 12; hold 8 cases with an owner. |
| Absence: 12 cases, 1 reviewer | 12 × 5 = 60 review minutes; 30 available. Reduce admission to 6; hold 6 cases with an owner. |
In this proposed design, the queue owner stops automated intake at the limit. Extra cases wait with an assigned owner, visible age, and next review time. Send them to the manual team only if that team has room. If neither team does, hold the cases and escalate the delay. Don't shorten the source check to clear the backlog.
The live system would need to enforce the limit and the team would need to rehearse the fallback; the table does neither. Try an absent reviewer, an interrupted review, and a difficult case. Agree how long a case may wait. Enough average capacity doesn't guarantee that the oldest case gets attention in time.
Measure missed corrections as well as edits
A trial could compare manual entry with assisted proposals using different but comparable cases that you're permitted to use. Vary which method people try first to reduce learning effects. Include planted wrong amounts, conflicting sources, and cases that should be escalated. Independently compare the final fields with the source. Quickly accepting a wrong draft is a failure.
Measure time spent checking sources and correcting fields, plus missed errors, rejections, escalations, abandoned work, waiting, and support. An elapsed browser timer, such as the local exercise uses, includes pauses and idle time; it doesn't measure labor saved. An edit count won't tell you whether the change was right or how hard it was.
Compare the full cost with today's manual process, including unfinished work and support for the next team. Report rejected and escalated attempts separately from completed work. A faster draft can still increase the review and repair bill.
Audit one packet before expanding the queue
Use the worksheet to audit the fifty-cent error on paper. Work through what a reviewer would need to see and what each choice must retain. Then inspect those choices in your own review interface: correction, rejection, escalation, pause, and failed save. Ask the queue owner for real availability and an overflow plan before proposing a trial.
Give the finished record to a second reader. Can they find the original error, correction, source, and decision without trusting the accepted label? That checks whether the record contains enough evidence. A live trial is still needed to learn how often reviewers catch errors under workload.
If reviewers can't open the source or nobody can handle overflow, hold expansion. Repair and try that part of the job before admitting more cases.