Routing by Exception

Everything about approval capacity comes down to one ratio: the number of records requiring judgement against the time available for judgement. Every other improvement is marginal next to reducing the numerator.

The practical lesson in “Routing by Exception” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring how employee monitoring works, Monitask can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.

Exception routing does that by asking a prior question of each submission — is there anything here worth a human looking at — and sending only those that answer yes into a queue that cannot be bulk-approved.

For a separate benchmark relevant to “Routing by Exception”, consult the Acas working-hours guidance. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

Why it is defensible

The objection is that it means most timesheets are not reviewed. That is already true; the difference is that it becomes deliberate, labelled and recorded rather than concealed behind an approval that claims otherwise.

It is also the structure used by every other control function in the organisation. Nobody reviews every expense line, every journal or every transaction; they set rules, route the exceptions, and sample the remainder. Timesheet approval is the one place this standard practice is routinely not applied.

The first rule set

Start with rules that are unambiguous and cheap to compute.

Variance from contracted or rostered hours beyond a threshold. Overtime of any kind. Premium categories: callout, standby, unsocial hours, weekend, public holiday. A code the person has not used in the last three months. Hours against a project with no current budget or past its end date. A week submitted for somebody recorded as absent. Entries modified after submission. Perfectly flat weeks. A total above a plausibility ceiling.

Nine rules, all computable, and together they will usually flag fifteen to twenty-five per cent of submissions.

Tuning the proportion

Below ten per cent flagged, the rules are too loose and you are approving things that should have been looked at. Above twenty-five, the queue stops being reviewable and approvers start bulk-approving the exceptions, which returns you to where you started and is worse because it now has a process diagram.

Tune on real data before switching anything on: run the rules against the last six periods and look at what they would have flagged. This also reveals which rule is doing all the work, which is usually the variance threshold.

What happens to the remainder

They are approved — in bulk, in one action, with the record saying that is what happened.

This is the part to insist on. A bulk approval under exception routing is a defensible statement: this record matched the expected pattern on every tested rule and was approved on that basis. A bulk approval without it is a claim of individual review that did not occur. Same action, entirely different record, and the difference is what an auditor is asking about.

Sampling the remainder

Because the rules only catch what they test, take a small random sample of the unflagged population each period — twenty records is usually enough — and review them properly.

Two purposes. It finds the error types the rules do not cover, which is how the rule set improves. And it means the organisation can say that unflagged records were subject to sampling rather than to nothing, which is a materially stronger position.

Reviewing the rules

Quarterly, against what the sampling and the downstream corrections found. A rule that never fires is noise in the configuration. An error type that keeps appearing in corrections and is not covered by any rule is a missing rule.

This is a twenty-minute job for one person with two reports in front of them, and it is the thing that keeps the set from calcifying into the configuration somebody wrote at implementation and nobody has touched since.

What the rules will never catch

Rules test what can be computed from the record against something else the system holds. They cannot detect an entry that is internally consistent, correctly coded, within every threshold and simply untrue.

That is what the sampling is for, and it is also the honest limit to state when the approach is described to an auditor or a funder. Exception routing is a control over the things that can be tested mechanically plus a sample of the rest; it is not a claim that every record was examined, and describing it accurately is what makes it stronger than the universal review it replaces.