Digitalising delivery routes: route optimisation, digital signature of delivery notes and real traceability

There’s a fact that surprises anyone who isn’t close to a delivery fleet: in many Spanish SMEs with 10 or 15 vans, a driver’s day still starts with a stack of paper delivery notes and ends with the manager transcribing by hand what was delivered and what wasn’t. The operation works because the drivers are veterans who know the stops, not because the system is designed for it.

When the conversation about digitalising delivery comes up, one idea usually lands on the table: “we’ll fix it with an app”. But digitalising a fleet properly isn’t about buying an app — it’s three connected pieces: route optimisation, digital signature of delivery notes on delivery and end-to-end traceability. If any of them is missing, the system limps along.

This article is a practical map for logistics and operations managers who are considering the leap. Without selling you a specific product, without promises of “30%” savings and without the word AI unless it’s actually needed.

The three pieces of digital delivery (quick summary)

Fifteen seconds of the map before getting into detail:

• Route optimisation: a system (TMS) that receives the day’s orders and returns the best sequence of stops considering time windows, vehicle capacity, restrictions (low-emission zones, weight, refrigeration) and real traffic times. It’s not Google Maps with several stops. It’s optimisation mathematics.
• Digital signature of delivery notes on delivery: the driver arrives with the goods, the customer signs on the driver’s tablet or phone and the signed delivery note goes back to the ERP automatically. eIDAS legal validity, offline mode for areas without coverage, full traceability.
• End-to-end traceability: every order is tracked from warehouse preparation to the customer’s signature. Geolocation per stop, incident photo, exact delivery time, return reason when applicable. A delivery note without traceability is just a signed piece of paper.

If your fleet has fewer than three vans and the delivery routine is stable (same stops every day), you can do fine without all three pieces: a digital signature and a bit of order will do. From five vehicles up, with changing orders and B2B delivery with agreed time slots, all three pay for themselves.

Route optimisation: what a TMS actually does

The component that’s most misunderstood. People think “Google Maps with several stops” and don’t get much further. A TMS (Transport Management System) does three things Google doesn’t:

1) It solves the travelling salesman problem with real-world constraints. Given N stops, the TMS calculates the optimal sequence. But the “optimal” sequence for a delivery run isn’t the shortest in kilometres: it’s the one that respects the customer’s time windows, doesn’t exceed vehicle capacity, avoids restricted zones according to the time of day, groups deliveries with the same profile (refrigerated vs dry) and minimises total time considering real traffic.

2) It assigns orders to vehicles. If you have five vans and 80 orders, the TMS decides which orders go to which vehicle while respecting each one’s constraints (capacity, authorisation for certain zones, working-day time). It’s a combinatorial decision a spreadsheet can’t solve.

3) It replans in real time when something changes. A customer cancels, another brings their time forward, a driver reports they’ll be late. The TMS recalculates the remaining route in seconds. Without a TMS, the manager hangs up the phone and reorganises with a pen.

The key isn’t the kilometre savings (usually 5-15% in fleets that already optimised through experience, up to 25-30% in fleets that delivered without a system). The key is eliminating “the manager’s minute”: you no longer need someone dedicated to manually coordinating every change during the day. That saved person-hour pays for the TMS on its own.

What to look for when choosing a TMS

• A connector with your existing ERP. Orders aren’t entered into the TMS by hand: they come from the ERP. If the TMS only connects with three ERPs and yours isn’t on the list, the connector has to be custom-built, or you’ll end up with double entry.
• Real-world constraints. Low-emission zones by city and time slot, capacity by volume and weight, multi-temperature for refrigeration, working-day time limits. A TMS that ignores legal restrictions is no use.
• A mobile app for drivers. Without an app, the driver doesn’t follow the optimised route. And the app needs to be designed for real use: one screen per stop, a giant “delivered” button, the customer’s information in large type, the next destination one tap away.
• Offline mode. Industrial estates and rural areas have stretches without coverage. The route must keep working without a connection and sync once signal is recovered.
• Real-time reoptimisation. Cancellations, delays, urgent jobs. The TMS must allow moving stops and reassigning on the fly, not just planning at the start of the day.

If you’re interested in a specific option for fleets with their own vehicles, we’ve built Rowan Rutas with exactly this profile in mind.

Digital signature of delivery notes: why eIDAS matters

This is where a lot of people get it wrong: they confuse “the customer signs on the screen” with “digital signature with legal validity”. They’re not the same thing.

A signature drawn on screen without an eIDAS framework is what any generic app does: the customer signs with their finger, the app saves the image and a PDF. If the customer disputes it a month later, you have no solid proof that they signed it, when, or where.

An eIDAS advanced electronic signature adds signatory linkage (device data, geolocation, qualified timestamp), document integrity (any alteration invalidates the signature) and full traceability of the process. It’s valid against disputes, before the tax authority and in court. It’s the difference between a signed piece of paper and one with a notarial seal.

The eIDAS regulation (electronic IDentification, Authentication and trust Services) is the European framework that has governed electronic signatures since 2014, updated to eIDAS 2 in 2024 with the European digital identity wallet. For delivery notes, the advanced electronic signature is legally sufficient. The qualified signature (with an identity certificate issued by a trusted entity) is stricter and is used for other cases (public contracts, deeds).

Components of a properly built delivery note signature

A digital delivery note signature that holds up to a dispute includes, at minimum:

• Biometric stroke captured on screen (pressure, speed, angle) in addition to the image of the signature.
• Qualified timestamp proving when it was signed.
• Device geolocation at the moment of signing.
• Identification of the operator who presents the delivery note to the customer.
• Cryptographic hash of the signed document, which detects any later alteration.
• Durable storage of the signed PDF with the full audit trail.
• Real offline mode that captures all metadata without a connection and syncs afterwards with the correct timestamp.

Typical risks when choosing the signature component

1) A “digital signature” that’s just a JPG image. Fine for making the customer feel like they’ve signed. No good in a dispute. Always ask whether the signature complies with eIDAS and ask to see the signed PDF generated to verify the metadata is there.

2) A signature that requires a connection at all times. If the app requires coverage to sign, your driver is stuck in an industrial estate or a warehouse 30 km from the city. The signature must always work offline.

3) A signature disconnected from the ERP. If the signed delivery note stays in a folder on the server and isn’t linked to the order in the ERP, you’ve only digitalised half the process. The signature must return to the order automatically, with all its metadata.

4) A signature that only works with one specific device. Some solutions require the provider’s own tablets with closed apps. If your driver loses the tablet, you’re left without a signature. The signature should run on any modern Android device (smartphone or PDA with scanner) or any iPhone, so the fleet stays replaceable.

For real operational cases we’ve built RowanSign, which meets the requirements above and integrates with Rowan ERP, Rowan Rutas and other ERPs via API.

Traceability: the glue that makes everything count

Optimising routes without traceability is perfecting the itinerary without knowing what happened at each stop. Signing digitally without traceability is having loose PDFs with no context. Traceability is what connects the two previous pieces with the rest of the business: the ERP, the WMS, customer service and the collections department.

What full delivery traceability includes

• Order status at every stage: prepared in warehouse, loaded onto vehicle, en route, at stop, delivered, returned, incident.
• Geolocation per stop: where each delivery note was signed. Useful for “it never arrived” disputes when it actually did.
• Exact time of every status change: leaving the warehouse, arriving at the stop, signature, departure for the next stop.
• Incident photo when applicable: damaged goods, incomplete pallet, customer absent, wrong address.
• Structured return reason, not a free-text field, so patterns can be analysed later (customers who return a lot, products with recurring problems, routes with difficult access).
• Audit of who did what: which operator loaded the vehicle, which driver signed the delivery, which administrator authorised the incident.

What traceability lets you do

Once you have the data, operational decisions stop being guesswork:

• Fill-rate analysis per customer: what percentage of orders arrive complete on the first attempt. If a customer has a 70% fill rate, your real margin with that customer is worse than you think.
• Incident pattern detection: if returns cluster around a product type, a zone or a time slot, there’s something concrete to fix.
• Defence against disputes: when a customer disputes a delivery three weeks later, you have geolocation, time, signature with metadata and a photo. The conversation changes.
• Reduced cost per delivery: comparing real times by route and driver reveals training needs, slow vehicles or stops that cost more to serve than they’re worth.
• Automated collections conversation: if there’s a dispute over an invoice, the signed delivery note with all its metadata resolves 80% of cases without negotiation.

Common mistakes when digitalising delivery

I’ve seen the same mistakes across very different SMEs. If any of these sound familiar, check before you buy anything.

1) Starting with the app and leaving integration for later. The project is sold as a “mobile app for drivers” and the ERP connector is left out of scope. On go-live day the driver signs in the app, but the ERP still doesn’t know about it and someone transcribes delivery notes by hand. Integration is half the project, not an extra.

2) Buying a TMS without a driver mobile app. The planner produces an optimised route, but the driver still works from paper. The optimisation is lost the moment something changes during the day. Without an app there’s no digitalisation, just a better planner.

3) Asking for a digital signature without a legal framework. The customer signs on screen, a PDF with their scrawl comes out and nobody asks whether it would hold up to a dispute. When the first serious claim arrives, you discover your “digital signature” is worthless paper.

4) Not training the drivers. The human component of delivery is the one that resists most. Veteran drivers who’ve worked with paper for ten years won’t learn the app in the first week. Without proper training and adjustment time, the system sabotages itself.

5) Optimising routes with bad data. If the ERP’s addresses are messy (no postcode, typos, three different addresses for the same customer), the TMS calculates optimal routes to the wrong points. Data quality is a prerequisite.

6) Buying from three different suppliers without stitching the pieces together. A TMS from one supplier, a digital signature from another, home-grown traceability in a spreadsheet. The pieces don’t talk to each other, the data lives in three places and the driver juggles three apps. Integration is the difference between a digitalised system and three isolated solutions.

Realistic cost and timeline

Without absolute figures (which depend heavily on size and supplier), here are the ranges we see in real projects in Spain, 2026.

Implementation timeline:

• SME with 3-10 vehicles and simple operations: 4-8 weeks to first production phase.
• SME with 10-30 vehicles, several routes and a connector with an existing ERP: 8-16 weeks.
• More complex operations (multi-warehouse, multi-temperature, separate WMS and TMS integration): 4-6 months.

3-year TCO (order of magnitude, not a figure):

• Standard off-the-shelf solution for a small-to-medium fleet: €€ with a per-user or per-vehicle licence. Tends to grow sharply as the fleet grows.
• Adaptable modular product (built core, adapted to your operation): €€-€€€ with a closed implementation fee and no per-user licences. More stable long term.
• Custom development from scratch: €€€-€€€€. Only if the case is genuinely unique or connectors with your legacy system justify it.

What matters isn’t the absolute price but the 3-year TCO, bearing in mind that licence-based solutions scale quickly as fleets grow.

Where to start (a three-month map)

If you’re coming to this conversation with no system, or a system that doesn’t fit, this is the natural order.

Month 1 — Diagnosis and data cleanup

• Audit of how many delivery notes/day you handle, how many vehicles, how many incidents and how much time the manager spends coordinating.
• Cleanup of the customer and address master data in the ERP. Without this, optimising routes is a waste of time.
• Definition of real operational constraints: time windows, capacity per vehicle, multi-temperature, low-emission zones.

Month 2 — Pilot implementation

• Selection of the supplier on merit (not on price, not on a nice demo: on real fit with your operation and their ability to integrate with your ERP).
• Configuration of the TMS with your real data in a pilot area (one route, two vehicles, two weeks).
• Onboarding of the two pilot drivers. Time for them to get used to the app and provide feedback.
• Configuration of the digital signature and testing with real pilot customers.

Month 3 — Rollout and go-live

• Deployment to the rest of the fleet.
• Driver training in small groups (3-4 drivers per session, not 20 at once).
• ERP connector working bidirectionally: orders go out, signed delivery notes come back.
• Basic dashboard with the key metrics (fill rate per route, average time per stop, % of incidents).

From month 4 onwards, it’s about iterating: adjusting route policies, refining incident handling, connecting traceability to collections and customer service, adding layers (advanced analytics, photos at every stop, etc.).

Frequently asked questions

Do I need to buy TMS, digital signature and traceability all at once, or can I start with just one piece? You can start with the digital signature alone if your biggest pain point is disputes and lost delivery notes. It’s the fastest piece to implement and the one that gives visible results in the shortest time. Route optimisation and traceability perform better when combined.

Can I do digital signatures of delivery notes with DocuSign or Adobe Sign? It works technically, but it’s poorly suited to the operational case: they require email, a connection, and someone signing from home a while later, not on the loading dock. For commercial contracts they’re perfect; for delivery notes signed in person there are specific solutions (including RowanSign) built for that exact case.

How much do you really save by optimising routes? It depends on the starting point. A fleet that already optimises through human experience saves between 5 and 15% of kilometres. A fleet that delivers without a system can save between 20 and 30%. The bigger saving is usually in coordination person-hours: the manager who no longer needs to manually reorganise every change.

Does it work with drivers who aren’t digitally native? Yes, if the app is well designed. The learning curve is 1-2 weeks for a veteran driver if the app has large elements and clear steps. If the app looks like a shrunk-down spreadsheet, no.

What happens if I change supplier after a few years? The history of signed delivery notes remains a legal asset and must be exportable. Always ask about portability before signing a contract: signed PDFs with metadata, export path, format. If a supplier makes it hard to extract your signed data, that’s a serious warning sign.

And mandatory B2B electronic invoicing with Verifactu? Signing a delivery note and electronic invoicing are separate but connected things. The signed delivery note triggers the next step (collection, electronic invoice). The delivery system must send delivery confirmation to the ERP; the ERP generates the electronic invoice when appropriate according to the customer’s terms. If your delivery system doesn’t notify the ERP, the invoice never gets issued.

In summary

Digitalising delivery properly is an operational project, not an IT project. The three pieces — optimisation, digital signature and traceability — reinforce each other: each one alone delivers some results; all three together change how the operation works. The criterion for choosing pieces isn’t price or brand: it’s the fit with your ERP, the real quality of the signature from a legal standpoint, and the mobile app’s ability to work offline in field conditions.

If you’re coming to this conversation without clarity on where to start, the most useful thing is usually an honest analysis of your current operation before comparing products. The difference between digitalising properly and digitalising halfway usually lies in the diagnosis, not the software.