Human-in-the-loop design for finance approvals

Human-in-the-loop design decides which finance decisions a person reviews, and shapes each request so review is possible. Most approval queues fail the second half. An approver clicking through 200 line items reviews none of them. The signature lands, the audit trail looks complete, and nothing was checked. An approval queue with a rejection rate near zero and a median approval time under a few seconds is not a control. It is a formality. A control that is rubber-stamped in practice is worse than no control, because it manufactures assurance nobody earned. Below are four approval patterns and how to measure whether yours catches anything.

Key takeaways

• Approval fatigue is measurable. Track median time-to-decision and rejection rate per queue. Near-zero rejections plus instant decisions means the control is decorative.

• Volume is the enemy of judgment. Ardent Partners reports that over 60% of invoices still require some human interaction. Routing all of it to a person guarantees fatigue.

• Four patterns cover most finance approvals: threshold gates, sampling, exception-only review, batch with drill-down. Each fails differently.

• Request design beats routing. An approval that requires opening another system will be rubber-stamped.

• Separate the builder from the approver. Whoever configured the workflow should not sign off on its output.

| Pattern | How it works | Best for | Failure mode | Example configuration | | --- | --- | --- | --- | --- | | Threshold gates | Approve above a dollar or variance limit | Payment runs, journal entries | Too low, everything routes; too high, nothing does | NetSuite bills over $5,000 route to the controller in Slack | | Sampling | Review a random or risk-weighted subset | High-volume, uniform transactions | The frame excludes the risky population | 5% of QuickBooks bills, plus new vendors | | Exception-only review | Review what rules could not resolve | Invoice matching, receipt coding | Rule drift reclassifies exceptions as clean | Match failures and confidence under 0.90 go to Gmail | | Batch with drill-down | Approve a summary, open any item in one click | Recurring, low-variance work | The summary hides the variance that mattered | Weekly Stripe fee batch, lines linked to Xero |

Why approval fatigue breaks finance controls

Approval fatigue is the point at which an approver stops evaluating and starts clearing. It is a rational response to 200 near-identical requests with no signal about which one matters.

The cost lands twice. First, the error the control was meant to catch passes through. IOFM puts the manual invoice error rate at roughly 2%, against below 0.8% automated, and rubber-stamped approvals inherit the manual rate while looking automated. Second, the organisation now believes the transaction was reviewed, and that belief shapes materiality judgments and SOX narratives.

Cycle time compounds it. Manual invoice cycle time averages 14.6 days against three to five days automated, and much of that gap sits in queues waiting on saturated approvers. Adding approvers does not fix saturation. Reducing what reaches them does.

How to detect approval fatigue in your own process

Run two measurements from your existing approval logs. Take the median time between a request appearing and being approved, per queue and per approver. Then take the rejection rate over the same window: rejections and send-backs divided by total decisions.

A queue with a median decision time under a few seconds and a rejection rate near zero is a formality. A queue with a median of several minutes and a rejection rate between roughly 2% and 10% is doing work. Bands vary by transaction type, but the shape holds: real review takes time and produces rejections.

Twenty approvals inside 30 seconds is one pass, not 20 decisions. Step flow: export approval events from NetSuite or QuickBooks → join to the request timestamp → compute median delta and rejection rate per approver.

Pattern one: threshold gates

Threshold gates route a transaction for approval only when it exceeds a dollar amount, a variance percentage, or both. They are the simplest pattern to build and the most commonly mis-set.

How it works. A deterministic rule checks every transaction. Below the limit it posts automatically with a full audit record. Above it, it routes to a named approver with the reason attached.

What it catches. Large-value errors, duplicate payments, and unbudgeted spend in a few big items.

What it misses. Activity structured below the line. Ten invoices at $4,900 against a $5,000 gate pass untouched. Gates also miss high-risk, low-value activity, such as a small payment to a newly added bank account.

When to use it. Payment runs, journal entries, and vendor credits, where value and risk move together.

Example configuration. In Loopfour Studio, a block evaluates each NetSuite bill. Bills over $5,000, or with a purchase-order variance over 5%, route to the controller as a Slack approval card. The rest post automatically. A second rule sends any bill whose vendor bank details changed within 30 days to a different approver. Flow: NetSuite bill → variance and payee checks → Slack card → approval posted back to NetSuite.

Pattern two: sampling

Sampling routes a random or risk-weighted subset for review instead of everything. It is counterintuitive to teams trained on completeness, and stronger than reviewing everything badly.

How it works. A deterministic selector picks items using a stated rule: a fixed percentage, or a sample weighted by amount or vendor age. The logic and seed are recorded, so the sample is reproducible.

Why it beats full review. A saturated queue has an unknown, low detection rate, because attention degrades across the sequence. A 5% sample reviewed properly has a known rate and supports a defensible statement about the rest. Auditors accept this logic already; it is how substantive testing works. The choice is between 5% examined and 100% glanced at.

What it catches. Systematic errors and coding drift. If a rule started miscoding a vendor in March, a sample finds it.

What it misses. One-off high-value events outside the sample. Never sample alone. Layer it under a threshold gate, so material items get full coverage.

When to use it. High-volume, uniform populations: expense coding, receipt matching, subscription charges.

Example configuration. A Loopfour workflow selects 5% of QuickBooks bills at random each week, plus every bill from vendors added in the last 90 days. The sample routes to the finance ops manager in Gmail with reason codes attached, and the selection logic sits in the execution tree.

Pattern three: exception-only review

Exception-only review sends a person only the items rules could not resolve. It is the highest-yield pattern in accounts payable, and it answers the Ardent Partners finding that over 60% of invoices still require human interaction.

How it works. Rules attempt resolution first: three-way match, vendor lookup, general-ledger coding, duplicate detection. Clean items post with a full audit record. Anything that fails a rule becomes a named exception. Read that over-60% figure as a routing instruction rather than a ceiling: most of it is a few repeating exception types, each with a rule that resolves it once someone writes the rule down.

What it catches. Genuine ambiguity: a missing purchase order, a quantity mismatch, a vendor with two active records. The approver arrives knowing why the item was flagged.

What it misses. Anything the rules resolve confidently and wrongly. A rule that codes a new vendor to the wrong account reduces your exception count, which looks like progress. Sample the auto-resolved population to catch it.

When to use it. Wherever rules already cover most cases: invoice processing, receipt coding, bank reconciliation.

Example configuration. The Loopfour Invoice Agent extracts header and line data, then a deterministic block runs the three-way match against NetSuite. Extraction is a scoped task governed by a confidence threshold: below 0.90 on any field, that field routes to a person rather than posting. Flow: invoice arrives in Gmail → Invoice Agent extraction → three-way match against NetSuite → clean items post, exceptions route to the AP lead in Outlook with the failing field highlighted → decision recorded in the execution tree.

Review the top five exception types monthly. Each is a candidate for a rule.

Pattern four: batch with drill-down

Batch with drill-down presents a summarised group of items for one approval, with one-click access to any underlying item. It suits high-volume, low-variance work where item-level approval would produce fatigue.

How it works. The workflow groups items by a meaningful dimension: vendor, account, cost centre, or period. The approver sees totals, counts, and variance against the prior period. Any line expands to the source document inside the request.

What it catches. Aggregate anomalies. A cost centre 40% above its trailing average is visible in a summary and invisible in a list of 300 approvals.

What it misses. Compensating errors inside the batch. A summary by account hides a vendor-level problem, so choose the grouping against the risk you care about.

When to use it. Recurring, uniform work: expense coding, card feeds, fee reclassifications.

Example configuration. A weekly Loopfour workflow groups Stripe fee transactions by account, compares each group against its trailing four-week average, and posts a summary to Slack. Groups within 10% of average show as cleared. Groups outside 10% surface at the top with the driver named, each line linked to the transaction in Xero. One approval clears the batch; any expanded item can be rejected on its own with a reason code.

What an approver needs at the moment of approval

An approval request must be evaluable inside itself. An approval request that requires opening another system to evaluate will be rubber-stamped, because the cost of doing it properly exceeds the perceived risk of clearing it. Five elements make one self-contained.

| Element | What it answers | Poor version | Good version | | --- | --- | --- | --- | | Proposed action | What happens on approval | Approve invoice 4471 | Post $12,400 to 6100 Professional fees, pay 30 September | | Source document | Is the record right | Link to the AP portal | Invoice PDF rendered inline | | Reason flagged | Why me, why now | Requires approval | Purchase-order variance of 12%, over the 5% limit | | Consequence of inaction | What if I do nothing | Nothing stated | Holds the payment run; escalates in 48 hours | | Reject path | How do I say no, and why | Reply to this email | One-click reject with codes: wrong amount, wrong coding, duplicate |

Two details carry weight beyond their size. The consequence of inaction must never default to silent approval; auto-approval on timeout converts a control into a delay. And rejection needs a reason code, because reason codes are the input to next quarter's rules. "Wrong coding, vendor mapped to the wrong account" becomes a rule. "Please fix" becomes another exception.

Loopfour routes approval requests natively to Slack, Gmail, or Outlook, with the document and the reason in the message body, so no portal login stands between the approver and the evidence.

How to measure whether approvals catch anything

Instrument the queue itself. Four measures tell you whether your approval controls work, and all four come from data your workflow already produces.

| Measure | What it tells you | Investigate when | | --- | --- | --- | | Rejection rate by queue | Whether the control produces outcomes | Below 1% for a full quarter | | Rejection rate by approver | Whether one person is clearing | One approver far below peers on a queue | | Rejection rate by exception type | Which rules are miscalibrated | A type rejects over 30% | | Time-to-decision distribution | Whether review happens | Median under five seconds, or a long tail past the deadline |

Read the distribution, not the average. A cluster of instant clears plus a few real reviews averages out to a healthy-looking number.

When a queue's rejection rate is zero for a full quarter, pull 25 approved items and review them properly. Errors mean the control is failing, and request design or volume is the cause. No errors in a clean population means the threshold sits too low; narrow the queue or move it to sampling. No errors in a population other measures show is not clean means the queue never sees the risky items.

Protiviti's 2025 SOX survey found nearly 70% of organisations have implemented automated compliance tools, and 68% are prioritising more technology and automation. Routing without instrumenting produces faster formalities.

Segregation of duties in automated approvals

The person who built the workflow should not approve its output. In a manual process, segregation separates whoever enters a transaction from whoever approves it. In an automated process the entering party is a rule, so whoever writes the rule holds that authority. Setting a threshold at $5,000 is a control decision as consequential as approving any single invoice.

Three practices keep this clean:

• Route configuration changes through their own approval path.

• Version every rule change with an author and a timestamp.

• Assign transaction approval to someone other than the workflow's author.

Loopfour, the deterministic finance workflow automation platform, records every rule version and approval decision in the execution tree, so an auditor can reconstruct which rule ran, who approved the exception, and who last changed the rule.

Choosing an approval pattern

Start from the population, not the tooling. Three questions settle most cases.

Is risk concentrated in a few large items? Use threshold gates, plus a payee-change rule that ignores amount. Payment runs and journal entries land here.

Is the population large and uniform? Use sampling for the auto-resolved portion and batch with drill-down for the rest. Expense coding and card feeds land here.

Do rules already resolve most cases? Use exception-only review, and sample the auto-resolved population to catch drift. Invoice processing and receipt coding land here.

Most teams combine all four: a gate on top, exception-only review underneath, sampling across the remainder, batching for the tail.

The prize is close-cycle time. APQC data covering more than 10,000 organisations shows top performers close in five days or less, against a median of six days and 10 or more calendar days for bottom performers. Saturated queues are a large share of that gap. In a modelled scenario where a mid-market team routes 90% of invoices through rules and reviews the rest as exceptions, the projected effect is a shorter queue and a close that behaves the same every month. Treat that as illustrative and model it on your own volumes, using Levvel Research's manual cost per invoice of $10 to $15 against $2 to $3 automated.

Frequently asked questions

What is human-in-the-loop design in finance approvals?

It is the practice of deciding which decisions a person reviews and building each request so review is possible. Three choices define it: what routes to a human, what the request contains, and what happens if nobody responds. The aim is fewer approvals, each getting real attention.

How do I know if my approval process is just rubber-stamping?

Measure two numbers per queue: median time between request and decision, and rejection rate over a quarter. A median under a few seconds with a near-zero rejection rate means the control is a formality. Confirm by pulling 25 approved items and reviewing them.

Is sampling defensible to auditors compared with reviewing everything?

Yes, when the selection rule is documented and reproducible. Auditors use statistical sampling for substantive testing, and the same logic applies to internal controls. A 5% sample reviewed carefully produces a known detection rate; a queue cleared in one pass produces an unknown one. Record the logic, population, and sample with each run.

What should an approval request contain?

Five things: the proposed action in plain terms, the source document inline, the reason it was flagged, what happens if the approver does nothing, and a one-click reject path with reason codes. If evaluating it means opening another system, the request is incomplete.

How does Loopfour decide what routes to a human?

Deterministic rules run first and resolve what they can. Anything left becomes a named exception and routes to a person. Loopfour is not an AI agent with a wrapper. Execution is programmatic and identical on run #1 and run #1,000,000, with an execution tree on every action.

Can AI approve transactions on its own?

Not in a Loopfour workflow. AI handles scoped tasks such as extracting invoice fields with the Invoice Agent or contract terms with the Contract Agent, each governed by a confidence threshold with a human fallback below it. The decision sits with a named person, and the record shows who decided, when, and on what evidence. The FinanceReasoning benchmark (ACL 2025, arXiv:2506.05828) tested 2,238 problems and found the strongest reasoning model reached 89.1% on the hard subset, with numerical calculation errors at roughly 37.5% of failures.

Where to start

Pick your highest-volume approval queue. Measure its median time-to-decision and its rejection rate over the last quarter. If the rate sits near zero and decisions land in seconds, that queue produces assurance without producing review. Narrow what reaches the approver, put the evidence inside the request, instrument the outcome.

Loopfour builds, monitors, and maintains these workflows on your existing finance stack, so your team approves only the exceptions. We are SOC 2 Type II certified with a SOC 1 audit underway, encrypt data with AES-256 at rest and TLS 1.3 in transit, and never use your data to train models.

Book a workflow review, and we will map your approval queues, measure where fatigue is hiding, and show you the pattern that fits each one.