Settlement is the daily control that holds a route business together. Done well it takes ten minutes per driver and catches problems the same day. Done badly it takes an hour, produces numbers nobody trusts, and pushes discrepancies into a monthly write-off.
What settlement reconciles
Three separate reconciliations, often conflated:
1. Stock. Opening van stock plus load-out, minus sales, minus returns to depot, minus damages and write-offs, equals expected closing stock. Compare with counted closing stock.
2. Cash and payments. Invoiced cash sales, minus credits, equals expected collection. Compare with cash counted, cheques listed and card transactions settled.
3. Documents. Every invoice number accounted for — issued, voided or unused. Gaps in a numbered sequence are the classic fraud indicator and the classic system misconfiguration.
A settlement process that only reconciles cash is missing two thirds of the control.
The daily sequence
- Driver completes final stop and returns to depot.
- Device syncs all transactions; settlement cannot start until sync is confirmed complete.
- Physical return of unsold stock, empties and returns, recorded as they are unloaded.
- Count of remaining van stock — blind for the SKUs under scrutiny.
- System computes expected versus actual for stock and cash.
- Driver reviews variances and provides explanations against reason codes.
- Supervisor reviews, approves within limits or escalates.
- Cash banked or secured, with dual control on counting.
- Settlement closed; the day is locked and posts to finance.
The critical design decision: settlement closes daily, without exception. Operations that allow "we'll sort it tomorrow" accumulate open days, and open days are where discrepancies become unresolvable.
Variance handling
Define tolerances in advance, in writing.
| Variance | Typical handling |
|---|---|
| Zero | Auto-close |
| Within minor threshold (e.g. small cash rounding) | Driver explanation, auto-approve |
| Above threshold, explained with valid reason code | Supervisor approval, logged |
| Above threshold, unexplained | Escalation, count repeated, investigation |
| Repeated pattern on one route | Investigation regardless of size |
Reason codes should be short and meaningful: damaged in transit, customer refused, miscount at load, returned unprocessed, price adjustment, sample. A free-text box produces "misc" and no analysis.
The pattern matters more than the individual variance. A route with £3 of variance every day is more interesting than one with a single £200 event, because the former indicates a systematic process gap.
Cash controls
Where cash is collected, controls are non-negotiable:
- Dual control on counting and banking.
- Sequentially numbered receipts issued to customers, reconciled to collections.
- Daily banking, with variance from expected reported before the day closes.
- Segregation of duties — the person who counts is not the person who reconciles is not the person who approves adjustments.
- Surprise counts at random intervals during the day, not only at settlement.
- Direct customer confirmation on a sample of collections each month.
The trend towards card and electronic payment reduces this burden substantially, which is a genuine operational argument for pushing customers away from cash beyond the obvious efficiency benefits.
Reporting that keeps it honest
Weekly:
- Settlement variance by route, value and count, trended
- Variances by reason code
- Routes with open settlements
- Invoice number sequence gaps
- Credits issued by driver, by reason
- Price overrides by driver
Monthly:
- Variance trend by driver, normalised for route value
- Write-off total against budget
- Time to settle per driver
- Repeat variance patterns
The credits and price override reports deserve particular attention. In many route businesses, unmonitored credit authority is a larger margin leak than inventory shrinkage, and it rarely appears in a stock reconciliation.
Making it fast
Settlement that takes too long gets rushed, and rushed settlement is not a control.
- Sync during the return journey so data is ready when the driver arrives.
- Pre-populate expected values rather than requiring re-entry.
- Count only what needs counting — full counts of every SKU daily is disproportionate for most operations.
- Stagger driver returns so five drivers do not arrive at one settlement desk simultaneously.
- Self-service settlement on the device for drivers with a clean record, with supervisor review by exception.
Ten minutes per driver is a reasonable target. Over thirty minutes, the process will be shortcut within a month.
Frequently asked questions
Should settlement happen daily or weekly?
Daily, in nearly all cases. Weekly settlement makes attribution impossible and delays detection to the point where explanations are unavailable. The only common exception is multi-day routes, where settlement occurs on return.
What tolerance is acceptable?
Set it as a percentage of route value rather than an absolute figure, so it scales across routes. The precise number matters less than that it is defined, published and consistently applied — and that patterns are investigated regardless of whether individual variances fall inside it.
Who should approve variances?
A supervisor, not the driver, and not the person who performed the count. Approval limits should escalate by value, and every approval should be logged with the approver's identity.
How do we handle a driver who consistently balances perfectly?
Verify it. Perfect settlement every day across hundreds of transactions is statistically unusual and can indicate that counts are being adjusted to match expectations rather than performed blind. Occasional blind supervisor counts resolve the question quickly.
Can settlement be automated entirely?
The computation can be. The physical count, the explanation of variance and the approval cannot, and should not be — the human steps are the control. Automation should remove arithmetic and data entry, not judgement.
