Custom direct store delivery (DSD) software development
With direct store delivery, the driver is often the salesperson too: they sell from the stock in their van, adjust to what the shop needs and invoice on the spot. That makes the van a mobile warehouse with its own stock administration, and a connection to the office is not something you can count on.
Why sales needs different software from delivery
With direct store delivery, goods go straight to the point of sale, bypassing the retailer's distribution centre. Within that model there are two similar ways of working. With pre-sold delivery, a sales representative takes the order and the driver delivers what has already been sold. With van sales, the driver is the seller: they decide with the store manager what is needed, load it from their own stock and invoice on the spot.
That second way of working turns the software around. The van is not a means of transport but a warehouse location with its own balance per item, and the sales document is created at the door. Assumptions that are self-evident in the office no longer hold: the price does not come from a central list, and the invoice number does not come from a central counter.
If your challenge lies elsewhere, another page may be more suitable. If your driver only delivers pre-sold orders and proof of receipt is the final step, you are looking for a proof of delivery app. If it concerns the wider working day with route lists, tasks and scheduling, see the driver app. If the bottleneck is planning, start with a transport planning API.
The van as a stock location
Each van has its own balance per item. What is on van A cannot be sold by van B.
Invoicing at the door
Price and customer agreements are determined on the device and recorded against the line.
Two opposing flows
Packaging, deposits and returns move in the other direction and are the most often forgotten.
Offline is the normal state, not a fault
The driver may be in a loading bay under a supermarket, on a back street or on a site where the signal just won't reach. Software that needs a connection to fetch a price or issue a number grinds to a halt, and so does the driver. Offline-first is therefore not a fallback: the device is where the transaction happens.
This requires an explicit decision about what the device itself may decide. Prices and customer agreements are held locally, with the version applied fixed on the line. Each device gets its own invoice number series; the Tax Authority's invoicing requirements permit multiple series as long as each number is unique and the series is traceable. Credit stops are carried along at loading, because online lookups fail precisely when they are needed.
On synchronisation, a sale is not treated as a request but as a fact that has already occurred. Visits are sent upstream as events, with device ID, sequence number and idempotency key, so that a repeated upload never produces a second invoice. Master data flows the other way and overwrites the device.
The real conflicts lie in scarcity, not in changed fields. Two drivers claiming the same remaining batch can only happen if both devices deduct offline from the same central pool. The solution is for each van to be its own location. Transfers between vans can then only be two-sided: one side deducts, the other confirms with a scan, and as long as one side is missing the batch is sellable to no one. More cumbersome than a shared stock pool, but the only variant that stays consistent offline.
- Prices and customer agreements local, version fixed on the line
- Own invoice number series per device
- Deduct to zero, never negative van stock
- Resumable sync per visit, not one upload per day
- Transfers between vans only confirmed on both sides
- Exceptions to a work list, no silent corrections
The end-of-day close is the moment of truth
At the end of the route, three counts must reconcile: what was unloaded, what the visits show as sold and taken back, and what physically comes back. In the parcel world this is called route accounting; SAP has a settlement cockpit for it. More important than the name is when a discrepancy becomes visible. If that only happens the next morning, the driver has gone and the reconstruction relies on memory.
Discrepancies rarely arise from bad intent: a mispick during loading, breakage, a forgotten sample, a variant whose packaging barely differs from its neighbour, and above all confusion between cases and consumer units. A crate counted as twelve bottles one day and as a single crate the next produces an unexplained difference.
A workable close-out therefore confronts you at intake, per item, and forces each discrepancy into a category: breakage, return, giveaway or unexplained. Unexplained differences never disappear entirely, and a system that pretends otherwise gets bypassed. What you can insist on is that releasing stock is a recorded action, so patterns become visible per route. Cash variance is closed off separately from stock variance.
What moves against the sales flow
Empties, deposits and returns
A deposit is not revenue but an obligation that moves back and forth and belongs separately on the invoice. Verpact runs the Dutch deposit system and publishes the rates annually, so your software must carry a rate change with an effective date without rewriting old receipts. Crates, roll cages and pallets work as an exchange system: what goes in full should come back empty, and the difference is a running account per outlet. For recording, GS1 code lists for packaging exist.
In addition, unsold items come back. Regulation (EU) No 1169/2011 recognises two markings with different consequences: best before concerns quality, use by concerns food safety. At intake, the system records per item what happens: back into saleable stock, rejected or written off. For chilled products this depends on temperature, and the hygiene code for transport, storage and distribution requires recording it.
Route, time window and unloading point
Shops have delivery windows, shared loading bays and unloading points behind the premises. A route that works on paper but misses the window costs not minutes but a trip: the van returns with the consignment still aboard and the shelf stays empty. The window is therefore a hard constraint, and waiting time at a loading bay belongs in the driving time.
Vehicle-specific restrictions also come into play. Municipalities are introducing zero-emission zones for urban logistics, meaning not every van can serve every customer. If you drive vans across the border, bear in mind the tachograph requirement that has applied since 1 July 2026 for vehicles over 2,500 kg in international transport and cabotage; domestically the threshold remains 3,500 kg.
The visiting order also determines the loading order: if the planner reshuffles the route without the van being loaded differently, the first consignment ends up at the back.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Integrations, messaging and frameworks
On the office side, the van app connects to your ERP or warehouse system, where the van is a stock location and issuing stock is a posting. On the customer side, chains often work with GS1 messages such as ORDERS, DESADV with an SSCC per shipping unit, RECADV for what was actually received, and INVOIC for the invoice.
There is a tension here that you resolve in advance. Sending a dispatch notice beforehand assumes the quantity is fixed, whereas with van sales only at the door does it become clear what the shop takes. Per customer you then choose a variant: build the message after the visit from the actual take, or let deviations run through the receipt notification. That is an agreement with your customer, not a setting. For temperature, the requirements that the NVWA supervises apply.
When an off-the-shelf package is the better choice
DSD is not uncharted territory. SAP offers a solution for direct store delivery with route accounting and a settlement cockpit, there are sales apps that connect to Microsoft Dynamics 365, and in beverage and foodservice distribution, mature route accounting packages have spent years refining end-of-day closing, cash flow and returnable packaging. If you recognise your process in that, you are buying a solved problem.
Custom software makes sense when your sales model departs from what those packages assume: returns-based delivery, sales by weight, or store-specific pricing agreements that don't fit a standard structure. Above all, it matters for the offline reality. Modules that allow offline entry but still need a connection for pricing, credit checks or number assignment fail on real routes. Test this before you choose, in a loading bay rather than a demo setup.
Be honest about the burden of custom development, too. Accountability shifts to you: which version of the app ran on which device, how the invoice sequences are structured, how temperature logging is safeguarded. That requires documentation, version control and logging, and maintenance must be part of the decision because your fleet starts up on it every morning. A hybrid approach is often the wisest: keep the ERP standard and build only the van app to measure.
- Your sales model departs from standard pre-sales or sales
- Store-specific pricing agreements do not fit the standard structure
- The package does not really track packaging and returns
- The existing module turns out not to be able to complete offline
- A hybrid setup is sufficient: standard ERP, custom development on the van
Frequently asked questions about DSD software
A proof of delivery app records that a pre-sold order has been delivered: scan, signature, exception, photo. A driver app covers the working day: route list, tasks and contact with planning. DSD software adds sales to that, with pricing, van stock, invoicing and end-of-day closing. First establish which of the three is your bottleneck.
That requirement is where the design stands or falls. A loading bay is often a concrete pit with no coverage, and a driver can't wait for a signal. The device therefore decides on price, stock and invoice number itself, and the end-of-day close is also generated locally. Mind the difference between offline entry and offline completion: if a package only manages the former, you'll still get stuck.
Often that is the wisest choice. SAP has a DSD solution with route accounting and a settlement cockpit, there are sales apps on Microsoft Dynamics 365, and mature route accounting packages exist in beverage distribution. With a conventional sales model, you are buying a solved problem there. Custom development only becomes logical with a departing sales model or a module that cannot complete offline.
By setting three counts against each other: what has been unloaded, what has been sold and returned according to the visits, and what comes back. Show the difference at intake, per item and at packaging level. Differences never disappear entirely; the goal is for them to be named and for their release to be recorded.
Custom development should come with source code in a repository you own, along with the environments and documentation. Record this in the contract, even when the collaboration is going well. More important is whether another party can take it over, and that depends on readable code, up-to-date documentation and mainstream technology.
That the accountability lies with you rather than with a package provider. If you transport chilled products, your process falls under Regulation (EC) No 852/2004, documented through the Hygiene Code for transport, storage and distribution. For invoices, the Dutch Tax Authority's invoice requirements apply, even when the number is generated on a handheld terminal.
Related services
Proof of delivery app
For routes where pre-sold orders are delivered and the proof of receipt is the final step.
Building a driver app
The broader working day on one device: route list, tasks, documents and contact with planning.
Transport planning API
Link routes, time windows and vehicle profiles to your planning system.
Your route as the starting point, not a demo setup
Tell us what is being loaded, what the driver may decide at the customer's site and where the end-of-day close-out currently gets stuck. Then we'll decide together whether a standard package is enough or whether custom software on the vehicle is the better route.