Cash Custody, Stock Reconciliation and Delivery Verification: Automating Distribution Controls

TL;DR: In van-sales and field distribution, cash and stock move through a field team while custody, reconciliation and proof of delivery are tracked on paper and trust, so leakage and disputes surface weeks late. The fix is not a bigger ERP. It is a last-mile control layer: per-delivery confirmation that is hard to bypass, a reconciliation engine that matches dispatched stock against confirmed deliveries against cash collected, and same-day exception reporting backed by an attributable audit log.

Where the money actually leaks in distribution

Walk the flow of a typical FMCG or beverage distributor and the risk is easy to locate. Stock is loaded onto a van in the morning. A salesman or driver spends the day dropping cases at groceries, cafeterias, hypermarket back-docks and small retailers, collecting cash from some, extending credit to others, and taking returns from a few. At the end of the day the van comes back, cash is counted, empties are logged, and someone reconciles the sheet against the load-out. On paper it balances. In practice, the gap between what left the warehouse and what was accounted for is settled by memory, goodwill and a stack of handwritten delivery notes.

That gap is where distribution operations bleed. Not usually through dramatic theft, but through a hundred small ambiguities: a case recorded as delivered that the customer says never arrived, cash collected today and settled next week, a return that was never logged, a short-delivery that becomes the customer's word against the driver's. Each one is minor. In aggregate, across dozens of routes and thousands of drops a month, they compound into real shrinkage and a reconciliation process that consumes senior time and still cannot prove what happened. This is the problem distribution cash and custody control is built to solve, and it is worth understanding why the obvious tools do not close it.

Why your ERP stops at the warehouse

Distributors often assume their ERP already covers this. It does not, and the reason is structural rather than a matter of configuration. An ERP such as SAP Business One or Zoho Inventory is excellent at recording two facts: what stock left the warehouse, and what was eventually invoiced or settled. Between those two points sits the van route, and to the ERP that route is a black box. The system knows 400 cases were dispatched to Van 12. It knows, days later, that a certain amount was invoiced and a certain amount of cash was banked. What it has no native record of is the sequence of actual handovers in between, each with its own quantity, its own recipient, and its own moment of custody transfer.

ERPs were designed around fixed locations, warehouses, branches, stores, where a transaction happens at a terminal under a login. Field distribution violates that assumption. The transaction happens at the tailgate of a truck, in a car park, at a shop counter, with no terminal and no login, and it is reconstructed into the ERP after the fact from paper. The ERP is therefore precise about the warehouse and structurally blind about the last mile. Bolting more fields onto it does not help, because the missing data is not a field, it is a confirmation event that never gets captured at the point and time it occurs.

Why after-the-fact reconciliation is too late

The traditional answer is end-of-day, end-of-week or month-end reconciliation: compare the load-out to the settlement and investigate the difference. The flaw is timing. By the time a monthly reconciliation flags a shortfall on a route three weeks ago, every input needed to resolve it has degraded. The driver does not remember a specific drop. The customer does not remember a specific quantity. The delivery note, if it exists, is a scrawl. The cash has been co-mingled across dozens of collections. You are running a forensic reconstruction with no reliable evidence, and the honest outcome is usually a write-off and a shrug.

Reconciliation done late is not a control. It is an autopsy. A control has to act while the facts are still fresh enough to correct, which in field distribution means the same day, ideally within the hour. The difference between finding a two-case discrepancy on Van 12 at 4pm today, when the driver can still call the customer, and finding it at month close, is the difference between a resolvable exception and an unrecoverable loss.

Why trust-based controls fail

The other common answer is trust reinforced by paperwork: honest drivers, signed delivery notes, and a supervisor who spot-checks. This fails for a reason that has nothing to do with the integrity of any individual. Trust-based controls are skippable, and anything skippable will be skipped under pressure. On a busy route, the driver who is behind schedule stops collecting signatures. The customer who is mid-rush waves the delivery through without checking the count. The supervisor who is covering three routes stops spot-checking. None of this requires bad intent. It requires a normal day.

Because the control depends on a person choosing to perform an optional step, its coverage is exactly as good as the busiest, most rushed moment on the route, which is to say, weakest precisely when volume and therefore exposure is highest. And a paper trail that can be completed retrospectively is not evidence of what happened, it is evidence of what someone later wrote down. The lesson is not to find more trustworthy people. It is to stop relying on optional human diligence for the one confirmation that the entire control depends on, and to make that confirmation a structural part of completing the delivery rather than an extra chore layered on top of it.

How to build last-mile distribution controls that hold

A control layer that actually closes the gap has four parts. None is exotic. The engineering discipline is in making the confirmation genuinely hard to bypass and the exceptions genuinely fast, and in fitting all of it around a field team that will not tolerate friction. This is how Soluvide approaches AI and workflow automation for operations where the risk lives outside the four walls of a system.

1. Per-delivery confirmation that is hard to bypass

The foundation is a confirmation captured at the moment of handover, tied to a specific delivery, a specific quantity and a specific customer, that the driver cannot self-certify. The strongest common pattern is a customer one-time password: at the drop, the customer receives a short code, by SMS or on WhatsApp through the WhatsApp Cloud API, and reads it to the driver or enters it, releasing that delivery in the system. Because the code goes to the customer, not the driver, it proves the customer was present and party to the handover. An alternative or complement is a signed digital handover, a fingertip signature or a photographed, geotagged receipt captured in a lightweight field app, which raises the effort of faking a confirmation far above the effort of simply doing the delivery correctly.

The design test is simple: can this delivery be marked complete without any independent party doing anything? If yes, it is skippable and will be skipped. If the only way to close the delivery is a confirmation that requires the customer's participation, custody transfer becomes a fact in the system rather than a claim on paper.

2. A reconciliation layer that matches three things

Confirmation on its own is just data. The value comes from a reconciliation engine that runs a three-way match continuously: stock dispatched to each van, deliveries confirmed by customers, and cash or credit recorded against those deliveries. When those three agree, the route is clean and nobody needs to look at it. When they diverge, the engine isolates the difference to a specific van, route, customer and time window. Two cases dispatched but never confirmed as delivered is a stock exception. A delivery confirmed but no matching cash or approved credit is a settlement exception. Cash recorded against a delivery the customer never confirmed is a different exception again. Each type points at a different failure and a different response, which is only possible because the match is granular per delivery, not aggregated per day.

3. Same-day exception reporting

The reconciliation engine feeds an exception report that reaches a supervisor the same day, not a spreadsheet reviewed at month-end. The report should be short by design, because a clean route generates nothing. What surfaces is only the divergences, each already attributed and quantified, so a supervisor can act while the trail is warm, call the customer, question the driver, correct the record, or escalate. The target is compression of the loop between an anomaly occurring and a human with authority seeing it, from weeks to hours. That compression is where recovery actually happens.

4. An attributable audit log

Underneath all of it sits an append-only audit log in which every custody event, dispatch, handover confirmation, cash entry, return, exception and resolution, is recorded with who, what, when and where, and cannot be quietly edited after the fact. This is what turns "the customer says it never arrived" from an argument into a lookup. The value is not only forensic. An attributable log changes behaviour, because a field team that knows every handover is confirmed by an independent party and permanently recorded operates differently from one that knows the record is a sheet of paper it fills in itself.

Two design principles that decide whether it works

Distribution controls fail in practice for predictable reasons, and two principles guard against the worst of them.

Confirmation must be un-skippable, exceptions must not be. The one thing the system depends on, the moment-of-handover confirmation, has to be structural: completing the delivery requires it, full stop. Everything downstream, chasing an exception, correcting a record, is allowed to be human and asynchronous. Teams get this backwards. They make confirmation optional and reconciliation mandatory, which is exactly wrong, because it leaves the load-bearing step to discretion and bureaucratises the recovery.

Surface exceptions, do not block the route. It is tempting to make the system refuse to proceed when something does not reconcile. Resist it. A control that stops a truck over a data mismatch turns a minor discrepancy into a missed delivery and a frustrated customer, and it teaches the field team to route around the system entirely. The route must always continue. The system's job is to make the exception visible and fast, not to sit as a gate on the road. A driver held up by your software will find a way to work without it, and then you have paid for a control that made coverage worse.

How this fits your existing stack

This does not mean replacing your ERP. The control layer is deliberately built to sit alongside it. Dispatch, invoice and customer-master data are read from the system of record, whether that is SAP Business One, Zoho or another platform, so nothing is re-keyed. Field confirmations are captured through channels the team and customers already use, commonly WhatsApp via the WhatsApp Cloud API and SMS for one-time passwords, so adoption does not depend on installing and training everyone on a heavy new app. Orchestration between systems, the confirmation events, the reconciliation runs, the exception alerts, can be built on a workflow engine such as n8n, with the audit log held in a dedicated database rather than scattered across the tools it observes. The ERP remains the source of truth; the new layer simply captures and reconciles the last mile the ERP was never designed to see.

For UAE distributors there is a further reason to make custody data clean and attributable at source. The country's move toward mandatory electronic invoicing raises the bar for defensible, machine-readable transaction records, and an operation whose last-mile handovers are already confirmed and logged is in a far stronger position than one still reconstructing them from paper. This is the same discipline we bring to other field-heavy logistics and distribution operations, where the controllable risk consistently lives outside the warehouse.

Where to start

The mistake is trying to instrument every route and every custody event at once. Start where the exposure and the ambiguity are highest, usually cash-collected van sales to small trade, and prove the loop on a handful of routes: un-skippable customer confirmation at handover, a three-way reconciliation running daily, and a same-day exception report going to one accountable supervisor. Once that loop is demonstrably tightening on those routes, extend it. The architecture is the same whether it covers three vans or three hundred; confidence is earned on a small, real slice before it is scaled.

Because every distribution operation breaks custody in slightly different places, there is no honest fixed price for this. We scope each build against your actual routes, systems and handover points, then send a fixed-fee proposal for the defined work, with the main cost drivers being integration depth with your ERP and the number of distinct handover points that need confirmation. If cash, stock and proof of delivery in your field operation are still tracked on trust and paper, the useful first step is mapping exactly where custody transfers and where the record goes dark. That map, not another spreadsheet, is what turns leakage from something you absorb into something you can see and stop.