Direct Store Delivery Software: Why End of Day Settlement Never Matches the Truck

Why a route truck is a warehouse that argues back

It is 4:50pm at the depot. A driver is standing at the settlement window with a tote of paperwork. His truck went out with 412 cases and came back with 38. He has 19 delivery tickets, four amended at the store because the receiver refused two cases of a promotional item not on the store's authorised list. He has a bag of returns: nine cases of stale product, a damaged case, and a pallet of empties from a deposit state. He collected two cheques and one store paid cash. The settlement clerk has to reconcile all of that against what the system thinks he took, and the difference this evening is 11 cases and $340.

Nobody is stealing. A moving warehouse ran a full trading day with no system of record on board. Every event, the refused case, the credit, the stale pickup, the deposit, the price override the driver agreed to keep an account happy, occurred outside any software and was captured on paper to be rekeyed later. By then the store is closed, the receiver has gone home, and the driver's memory is the only evidence.

This is the specific shape of direct store delivery, and it is not the same as parcel delivery, field service or a normal wholesale route. Your driver is simultaneously a delivery person, a salesperson, a merchandiser, a returns agent and a cashier, standing in someone else's building with authority to change the transaction. The software has to be the financial control over that, which is why generic delivery apps and generic sales tools both fail here.

What the incumbents do well and where they stop

Vermont Information Processing, eoStar and Encompass Technologies are the real names in this category and they should be on your list. They understand route accounting properly, which most software companies do not, and if you are a conventional beverage distributor with a conventional structure they will serve you.

Where operators start looking elsewhere is at the edges that define their own business. Category matters enormously. Beer distribution carries three tier regulatory structure and state specific rules on pricing and what can be given to a retailer. Snacks and bakery frequently run scan based trading with grocery chains, where you are paid on what the store scans rather than what you delivered, which turns the delivery document into something quite different. Direct store delivery to convenience versus grocery versus club stores involves three different receiving processes. Products built to serve the middle of this market handle the common case cleanly and treat your specific case as configuration, and if your specific case is where your margin lives, that is a problem.

Problem one: offline is a requirement, not a feature

Stores have back rooms with concrete walls and metal shelving. Loading docks are underground. Rural routes have dead zones for miles. A driver who cannot complete a delivery because the app is waiting on a network is a driver who reverts to paper, and once one driver reverts, settlement is manual again for everyone.

Offline capable is easy to claim and hard to build. The genuinely difficult part is not caching data, it is conflict. Two drivers on adjacent routes both service a store during a transfer. A price change is published mid morning and a driver who has been offline since eight applies the old one. The system has to have an opinion about which record wins, and that opinion has to match how your business actually resolves disputes.

What we build is a truck as an authoritative local ledger that syncs events rather than states. The truck records what happened, in order, with timestamps and the driver's identity. The depot applies those events against its own record and raises exceptions where they conflict rather than silently overwriting. That distinction sounds academic until a driver's whole day disappears because a sync overwrote it.

Problem two: settlement is the entire financial control and it is done by eye

Settlement should be a closed loop. The truck was loaded with a known quantity, sold a known quantity, returned a known quantity, collected a known amount, and everything must balance. In practice the loop is open in several places at once: the load was picked short and nobody adjusted it, a driver moved product to another truck at a cross dock, returns were counted approximately, and a cash collection is in an envelope.

A build worth paying for closes each of those. Load out is scanned and confirmed by the driver, so the opening position is agreed rather than assumed. Every store event moves stock: a delivery reduces truck stock, a refusal returns it, a stale pickup adds to a segregated return bucket that cannot be resold. Truck transfers are transactions with two signatures. Cash and cheque collections are recorded at the store with the store's own reference. Then settlement is a report of variance rather than a reconstruction, and the driver signs a number that was already true at 4:30pm rather than one produced at the window.

The settlement queue then disappears, and variance becomes visible by driver, route, store and product, which turns shrink from a total into a diagnosis.

Problem three: pricing at the store door is where the margin actually goes

Direct store delivery pricing is not a price list. It is a base price, a chain agreement, a state or territory rule, a temporary promotional allowance with a start and end date, a case stacking deal, a display allowance that depends on the display actually being built, and a driver with some discretion.

Deductions are the tell. Distributors who cannot price accurately at the door discover their pricing errors months later as deductions from a grocery chain's remittance, and by then the evidence is gone and the deduction is written off. That is a permanent transfer from your margin to theirs, and almost nobody measures it as a pricing failure because it arrives disguised as an accounting problem.

What custom software does is hold price as a resolved calculation at the moment of the transaction, with the full derivation stored. The invoice line records which promotion applied, which agreement it came from, and what the base was. When a deduction arrives, you answer it in minutes with evidence instead of accepting it.

Problem four: deposits, empties and returns are three different things and one field

In states with container deposit laws you are collecting and refunding deposits at a legislated rate, which is a liability on your balance sheet and not revenue. Empties come back and have to be counted, sorted and often paid on. Stale and damaged product comes back and needs a reason code, because that reason decides whether the cost sits with you, the retailer or the brand, and whether the manufacturer owes you a credit.

Systems that treat all returns as one bucket lose the stale reason, so no manufacturer claim is filed, and estimate the deposit liability. A build should separate deposit movements, empty containers and product returns with reasons, and produce the manufacturer claim as an output rather than a quarterly project someone dreads.

What a custom direct store delivery build has to include

• A fully offline capable mobile application that records events in order with driver identity and syncs by event rather than by overwriting state.
• Truck stock as a real inventory location with scanned load out, confirmed transfers between trucks and segregated return buckets.
• Price resolution at the moment of sale with full derivation stored on the invoice line, covering base price, chain agreement, promotional allowance and driver discretion within limits.
• Deposit, empty container and product return handled as three distinct movement types with reason codes that drive manufacturer claims.
• Store level receiving support for the different processes at convenience, grocery and club accounts, including scan based trading where you are paid on scans rather than deliveries.
• In cab printing of invoices and credits, because many receivers still require paper at the door and a driver holding a phone at a receiving desk is not a workflow.
• Settlement as a variance report produced from events already recorded, with cash and cheque collection captured at the store.
• A posting interface to your accounting system that your controller can reconcile line by line, plus deduction evidence retrieval for chain accounts.

What this costs and how long it takes

A focused first release, meaning the offline mobile application, truck stock control, store delivery with pricing, and settlement, runs $90,000 to $180,000 and ships in 12 to 18 weeks. That is a system your drivers use on the road on day one, not a pilot on two trucks. A full platform adding presales, promotional management, deposits and returns with manufacturer claims, in cab printing, chain electronic data interchange and accounting posting runs $250,000 to $550,000 phased over 8 to 15 months.

What drives the number up in this category: the number of product categories, since beer, snacks and bakery carry different rules and different chain relationships; regulated categories generally, because alcohol brings state specific pricing and reporting obligations that must be built correctly rather than approximately; electronic data interchange with grocery chains, as each trading partner's purchase order and invoice implementation is its own effort measured in weeks; and scan based trading, which changes the whole settlement model for those accounts.

What keeps the number down: start with one category, one depot and your existing price structure exactly as it is, and do not rationalise promotions during the build.

When buying off the shelf is right

Buy if you run under roughly 15 routes in a single category with straightforward pricing and no scan based trading. Vermont Information Processing, eoStar and Encompass will do the job, they know route accounting, and a custom build would be capital better spent on fleet. Buy also if you are primarily a delivery operation without selling at the door, since without the sales and credit authority on the truck the hard part of this problem does not exist.

Build when two or more of these are true. Settlement takes a supervisor more than an hour a day and ends in adjustments. Chain deductions arrive that you cannot dispute because you cannot reproduce the pricing derivation. You run multiple categories or a regulated category with rules your current system expresses through workarounds. Scan based trading accounts are a growing share of your revenue and your system treats them as normal deliveries. Your bridge from route settlement to accounting is maintained by one person and breaks regularly. At that point the route is your business, and the logic that governs it should be yours too.

How to choose a developer for route accounting software

Ask them to explain settlement back to you before they quote. If they describe it as a delivery confirmation report, they have built parcel software. The right answer involves an opening truck position, a set of movements and a closing variance, and they should ask you how you handle truck to truck transfers before you mention them.

Ask specifically how their offline model resolves conflict. The answer you want involves an ordered event log from the device and exception handling at the depot. The answer that should worry you is that the device sends its state and the server accepts it.

Ask what they have integrated, naming the specific printer model and the specific trading partner document. In cab printers, rugged handhelds, chain electronic data interchange and an accounting system are four distinct problems, and only the last looks like normal software work.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. When the software is the financial control over every truck you run, a dependency on the developer is a risk to the business rather than an inconvenience.