Direct Store Delivery Software Problems: The 7 That Cost You Cases and Margin, and How to Avoid Them

Why does the driver app scope keep producing the wrong system?

The project usually starts as an app for drivers. Show the route, confirm the delivery, capture a signature, done. That description fits parcel delivery and field service, and it is the reason so many route operations end up with a tidy mobile application and a settlement window that still runs on paper.

A route truck is not a delivery vehicle. It is a moving warehouse with a salesperson on board who has authority to change the transaction: to accept a refusal, to issue a credit, to take back stale product, to apply a promotional price, to move stock to another truck at a cross dock, and to collect cash. Every one of those is a financial event, and a delivery confirmation app records none of them. So they happen on paper, get rekeyed the next morning, and settlement becomes a reconstruction from memory after the store has closed.

The test to apply before you sign anything is to ask the developer to explain settlement back to you. If they describe a delivery confirmation report, they have built parcel software. The answer you want involves an opening truck position, stock movements through the day, collections captured at the store, and a closing variance already known before the driver reaches the window. They should ask how you handle truck to truck transfers before you raise it.

What goes wrong when you migrate item, price and customer master data?

The master data behind a route business is messier than anyone admits until it has to be loaded into something new. Items exist as case codes, unit codes and retailer specific codes, and the mapping between them lives partly in a spreadsheet and partly in a warehouse manager's head. The same product carries different codes for different chains. Customer records include stores that closed, stores that changed banner, and stores entered twice because a different salesperson set them up.

Pricing is worse, because it is not a list. It is a base price, a chain agreement, a state or territory rule, a promotional allowance with dates, a display allowance that depends on the display being built, and a driver with some discretion. Those layers usually live in three or four places, and the resolved price a driver charges today is a calculation nobody has written down.

The mistake teams make is trying to rationalise this during the build. Somebody sensibly proposes cleaning up promotions and standardising the item codes at the same time as the migration, and the project immediately acquires a second workstream owned by a sales team with its own priorities. Load the price structure exactly as it is, including the parts that look wrong, and prove the system reproduces today's invoice for a sample of real stores across each chain before anything goes live. Rationalise afterwards, once the system can show you which promotions are actually being used.

Why do offline sync and chain EDI break weeks after launch?

Offline capable is the easiest claim in this category and the hardest thing to build correctly. Caching data for a truck is straightforward. Resolving conflict is not, and conflict is guaranteed: two drivers service the same store during a route transfer, a price change publishes mid morning while a driver has been offline since eight, a return is entered twice because a driver was not sure the first one saved.

The failure that hurts is a device that sends its whole state and a server that accepts it. One bad sync and a driver's entire day disappears, or worse, reappears wrong and nobody notices until settlement. The correct model is an ordered event log from the device, with timestamps and driver identity, applied by the depot against its own record, raising exceptions where events conflict rather than silently overwriting. The difference is invisible in a demo and decisive in production, so ask about it directly.

Chain electronic data interchange fails differently. It works at go live because it was tested against the documents the trading partner sent during implementation, and then the partner changes a segment, adds a required qualifier, or starts sending a purchase order variant nobody had seen. Rejections come back as codes, and if nobody owns the rejection queue they accumulate until a chain calls about missing invoices. Every trading partner is a separate integration with its own implementation of the same standard, so price them individually and give the queue a named owner with a daily rhythm.

What happens when deposits, empties and stale returns share one field?

Most systems that were not built for this treat returns as a single bucket, and that single decision destroys three different pieces of financial information at once.

Deposits in states with container deposit laws are a legislated liability rather than revenue, and estimating them is how a distributor ends up with a balance sheet line nobody can substantiate. Empty containers are a physical flow that has to be counted, sorted and often paid on, and they move independently of product. Stale and damaged product needs a reason code, because the reason decides whether the cost sits with you, the retailer or the brand, and whether the manufacturer owes you a credit.

When these collapse into one field, the visible symptom is a returns number that finance cannot explain. The invisible symptom is worse: manufacturer claims that never get filed, because the stale reason was never captured, so the credit you were contractually entitled to simply does not get claimed. That is money you have already lost on the product, forgone a second time.

The fix is three distinct movement types with their own handling. Deposit movements post to the liability, not to revenue. Empties are counted as their own inventory with their own reconciliation. Product returns carry a reason code from a controlled list, land in a segregated bucket that cannot be resold, and roll up into a manufacturer claim that the system produces as an output rather than something a person assembles quarterly and dreads.

Should you build custom or configure what you already own?

Vermont Information Processing, eoStar and Encompass Technologies are the real names in route accounting and they should be on your list. They understand this domain in a way most software companies do not, and if you are a conventional distributor with one category, straightforward pricing and no scan based trading, one of them configured properly is the right answer. Under roughly fifteen routes, that is almost certainly true, and the capital is better spent on trucks.

It is also the right answer if your drivers do not carry sales and credit authority at the store door, because the hard part of this problem does not exist for you.

Before commissioning anything, be honest about whether your complaint is capability or configuration. Distributors frequently blame the product for pricing that was never set up properly, or for a settlement process that is manual because nobody enforced scanned load out. Both are fixable inside a packaged system by someone who knows it, and fixing them costs a fraction of a build.

Build when the edges are where your margin lives. Multiple categories with genuinely different rules. A regulated category such as beer, where three tier structure and state specific pricing have to be built correctly rather than approximately. Scan based trading with grocery chains, where payment follows what the store scans rather than what you delivered, which changes what a delivery even means. Or chain agreements complex enough that price has to be derived rather than looked up.

How do hidden costs get into the quote?

The first is trading partner count. Chain electronic data interchange is quoted as one line called EDI and is actually one project per trading partner, each measured in weeks, because every partner implements the standard slightly differently and validates on their own terms. Ask for a per partner figure and a named list.

The second is hardware. Rugged handhelds, mounts, in cab printers and their consumables are a procurement and support programme, not an accessory. Many receivers still require paper at the door, particularly independent grocery and convenience accounts, so a driver holding up a phone screen at a receiving desk with a queue behind him is not a workflow that survives a busy morning. Confirm the specific printer models a developer has actually deployed, not a claim of printer support.

The third is regulated category work. Alcohol brings state specific pricing rules and reporting obligations, and these must be right rather than approximately right. That is analysis time with someone who knows the rules, and it belongs in the estimate.

The fourth is accounting posting, since a controller who cannot reconcile it line by line will build a spreadsheet alongside it and you will have paid for a second set of numbers. The fifth is scan based trading, which is not a feature you add later, because it changes the settlement model for those accounts.

What separates a build that works here from one that fails?

Every event that changes the truck is recorded when and where it happens, with the driver's identity attached: a delivery reduces truck stock, a refusal returns it, a stale pickup adds to a segregated bucket, a transfer carries two signatures, and cash is captured at the store with the store's own reference. Settlement then becomes a variance report, and variance becomes visible by driver, route, store and product, which turns shrink from a total into a diagnosis.

Every invoice line stores its full price derivation: the base, the chain agreement, the promotional allowance with its dates, and any driver discretion applied within limits. This is the single feature that converts deductions from a write off into a routine dispute you usually win, and it costs almost nothing to build if it is designed in at the start and is painful to retrofit.

The rollout follows one route for a week, then one depot, then the rest, because a depot running mixed paper and digital settlement puts the clerk through both processes and teaches them the new one is slower.

And settle ownership before kickoff. You should hold the repository, the infrastructure accounts and the unrestricted right to hire another firm. 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.