Ingka Group acquires Locus! Built for the real world, backed for the long run. Read here>Read the full story>
Ingka Group acquires Locus! Built for the real world, backed for the long run. Read the full story

Optimising Logistics Fulfilment Under Europe's Rules

Locus Logistics Optimiser September 2026 9 min read

European logistics runs on rules. Driver hours, union contracts, subcontractor terms, dock capacity, emission zones. Those rules have to live inside the optimisation model, not as checks around it. Vendors whose models cannot absorb them produce plans that do not survive contact with the ground.

The volume of planning European operations require is very high, and the question worth asking is whether that effort is carried out by hand or by a system that understands the constraints and learns from them.

Without the right planning you leak money across every resource you hold: assets, workers and drivers. The right optimiser tells you where the leakage is.

This paper works through that argument in eight parts: the rules you are optimising under, emission zones and EV mandates, driver hours and dock capacity, contracting and lane design for a mixed workforce, the cost model, the optimisation engine under the hood, explainability and human oversight, and how control divides between headquarters and the regions.

Fig. 1 Constraints around the model, or inside it

Two ways of handling the same rules. Only one of them optimises cost.

Constraints applied around the optimisation model against constraints inside it On the left, constraints around the model: step one optimises routes on distance and time, step two checks driver hours, union terms, dock slots and zone access, step three finds a breach and returns the plan to be optimised again. The planner ends up rebuilding by hand and cost is whatever is left after compliance. On the right, constraints inside the model: one optimisation pass in which driver hours, union and contract terms, subcontractor rules, dock and preload capacity, emission-zone access, vehicle and trailer models and cost parameters are all decision variables rather than filters. The result is a feasible, executable plan the first time, with cost optimised rather than reconciled. CONSTRAINTS AROUND THE MODEL CONSTRAINTS INSIDE THE MODEL STEP 1 · OPTIMISESTEP 2 · CHECKSTEP 3 · BREACH FOUND Routes built on distance and time Driver hours · union terms · dock slots · zone access Send the plan back and optimise again The planner rebuilds by hand. Cost is whatever is left after compliance. One optimisation pass CONSTRAINTS ARE DECISION VARIABLES, NOT FILTERS Driver hours of serviceUnion & contract terms Subcontractor rulesDock & preload capacity Emission-zone accessVehicle & trailer models A feasible, executable plan the first time. Cost is optimised, not reconciled. The rules are the same in both. Only the second one prices them.

The eight sections below work through the constraints this figure compresses.

1Mandatory, not preferences

The rules you are optimising under

Before the planning and execution questions, it is worth naming the system-level constraints and governance that European logistics operates under. These are not preferences. They are mandatory, and each one shapes what a plan is allowed to look like.

Two of the four moved during 2026, which matters for anyone sizing a compliance programme this year. The sustainability regimes were narrowed, and the AI Act's obligations for worker-affecting systems were pushed back and given a firm date.

Fig. 2 The four regimes, and where each one is answered

Each rule shapes what a plan is allowed to look like, before cost, service or utilisation enter the model at all.

Four European regulatory regimes and where each is answered Four cards. GDPR governs driver and customer personal data, telematics, location history, retention periods, data processing agreements and sub-processor lists. The EU AI Act governs algorithmic decisions affecting workers, including route, shift and order allocation, and its high-risk obligations apply from 2 December 2027. CSRD with CSDDD governs sustainability and supply-chain due diligence reporting, narrowed in 2026 to companies above one thousand employees and four hundred and fifty million euro turnover. Data residency requires EU hosting and is often expected to be in-country. Every plan the optimiser produces stands on all four. MANDATORY, NOT PREFERENCES GDPREU AI ActCSRD / CSDDDData residency PERSONAL DATAALGORITHMIC DECISIONSSUSTAINABILITYWHERE IT LIVES Driver and customerpersonal data, telematics,location history, retentionperiods, DPAs andsub-processor lists.None of it is optional. Algorithmic decisionsaffecting workers, includingroute, shift and orderallocation, need documentedexplainability and humanoversight. Sustainability andsupply-chain due-diligencereporting. Emissions perroute need to be auditablefor operators in scope. EU-hosted, and oftenexpected to bein-country. High risk applies 2 Dec 2027 Narrowed 2026 to 1,000+ staff and EUR 450m+ turnover Every plan the optimiser produces stands on all four Each rule shapes what a plan is allowed to look like, before cost, service or utilisation are considered at all. Compliance is not a filter applied at the end. It is the shape of the plan.

Regulatory dates and thresholds are cited in full under Notes & sources.

On the AI Act specifically. The obligations for Annex III high-risk systems, the category that covers employment and worker management, were postponed to 2 December 2027. Systems already in use before that date sit outside scope unless they undergo significant changes in design. Whether a given dispatch or allocation system falls inside that category is a scoping question each operator has to answer, and it is worth answering early: the platform chosen in 2026 is the one that will be running when the date arrives.

2Zero-emission zones and electric fleets

Emission zones and EV mandates

Parts of Europe now restrict access to zero-emission vehicles, and those restrictions are enforced with fines rather than guidance. A plan that ignores them is not a cheaper plan, it is an unaffordable one.

Electric routing brings its own constraints. An electric vehicle carries weight and volume limits a diesel tractor does not. It has to be charged for long enough to be available, and charging imposes a range limit on how far it can then operate. Those three facts interact, which is why an EV day cannot be planned on hours alone.

Fig. 3 An EV day is bounded by range and charge, not only by hours

The feasibility question is not whether the driver has hours left. It is whether the second trip still completes above the reserve.

An electric vehicle's day plotted as state of charge against two trips and a charging window A vehicle duty bar shows trip one from depot to stores in the morning, a charging window in the middle of the day, and trip two in the afternoon, with two zero-emission zones shaded. Below, state of charge falls from full at six in the morning to near the minimum reserve by eleven, rises during charging, then falls again across trip two, finishing just above the reserve at six in the evening. Because it completes above the reserve, the second trip is allowed. Three questions follow: whether the vehicle can carry the load at all given weight and volume limits, whether a second trip fits once charging time is modelled, and what happens if range drops mid-route. ZERO-EMISSION ZONE ZERO-EMISSION ZONE VEHICLE DUTY Trip 1 · depot to storesChargeTrip 2 · depot to stores STATE OF CHARGE 100%50%0% MINIMUM RESERVE Trip 2 completes above reserve, so it is allowed 06:0009:0012:00 15:0018:00 Can it carry the load at all?Does a second trip fit?And if range drops mid-route? EVs carry weight and volumelimits a diesel tractor does not.The load is sized to the vehicle first. Charging time and trip start andend times are optimised againstrange before a multi-trip is offered. The vehicle is re-routed to acharging station in flight, withoutbreaking the customer promise.

Schematic. The state-of-charge curve is illustrative, not measured.

12M kgof CO2 prevented
68M milessaved

3Hard statutory limits

Driver hours, vehicles and dock capacity

With multiple vehicle and trailer models operating out of one distribution centre, the system has to be told when a resource should be loaded, preloaded and dispatched. Dock capacity and resources have to be constrained without damaging on-time in-full delivery to the customer.

Those vehicles are available around the clock and can run for the whole day. The drivers cannot, and it would be unfair to expect it. This is where European and UK logistics differ from much of the rest of the world: the limits are statutory, they are specific, and a breach invites a fine. Nine hours of daily driving, extendable to ten twice a week. A break of at least forty-five minutes after four and a half hours at the latest. Eleven hours of daily rest, reducible to nine no more than three times a week.

Holding all of that while still arriving at an optimal, deployable plan is the task. To do it, the software has to carry the constraints and apply them in the optimiser rather than check them afterwards.

Fig. 4 The asset is never what runs out. The driver is

Store D sits inside the vehicle's availability and outside driver 1's hours, so it moves to a second driver rather than stretching the first.

A schematic day showing dock, vehicle, two drivers and customer windows against statutory driving limits Five tracks across a day from four in the morning to eight in the evening. The dock preloads and loads, with bays capping how many vehicles go at once. The vehicle is available twenty-four seven and is never the thing that runs out. Driver one starts at six thirty, drives four and a half hours to the statutory break point, takes a forty-five minute break, drives again and exhausts hours of service by four in the afternoon. Driver two comes on shift later and picks up store D. Customer windows for stores A, B and C fall inside driver one's hours while store D falls outside them, so the optimiser places store D on the second driver rather than stretching the first. 04:0006:0008:0010:00 12:0014:0016:0018:0020:00 DOCKVEHICLEDRIVER 1DRIVER 2CUSTOMER capacity-boundno statutory limithours-boundfresh hourspromised windows Preload Load Load Dispatch 06:30 · bays cap how many go at once Available 24 / 7 · the asset is never the thing that runs out Driving Break Driving Hours of service exhausted 4.5 H MAX BEFORE A BREAK 45 MIN 9 H DAILY DRIVING LIMIT REACHED Not yet on shift Driving · picks up Store D Store AStore BStore CStore D DRIVER 1 IS OUT OF HOURS HERE SO STORE D GOES TO DRIVER 2 The limits are numbers, not preferences. A plan either respects them or it is not a plan.

Schematic day. Driving and break limits per Regulation (EC) No 561/2006

4Contracting, lanes and priority

Design the lane before you contract to it

A business rarely holds all the resources it needs, so outsourcing is common across the region and it is governed by the rules of each country. There is also the question of workforce priority: a business will have workers contracted for set durations, and those commitments have to be honoured ahead of ad-hoc capacity.

The interesting question is when you should contract those drivers. The obvious answer is on demand, and that is correct as far as it goes. It matters just as much to know which routes the contracted drivers will run.

Fig. 5 Design the lane first, then contract to it

Contract before the lane is designed and the lane has to fit a contract that is already signed.

Two orderings of the same four decisions: contracting before lane design, and lane design before contracting The common order runs forecast demand, contract the drivers, design the lanes, allocate the work. The lane then has to fit a contract already signed, and traffic, road conditions, one-ways and the right asset model are discovered after the fact. The order that works runs forecast demand, design the lanes, contract to the lane, allocate by priority. Six things a lane has to carry before anyone signs for it: traffic actually calculated rather than assumed, road conditions on the route, highways and one-ways to avoid, the right asset model for the lane, working hours which differ per worker, and whether the trip is one-way or round trip and what that costs. THE COMMON ORDER Demand first, people second, geography last Forecast demandContract the driversDesign the lanesAllocate the work Duration, shift pattern, rateAround terms already signed The lane now has to fit a contract that is already signed. Traffic, road conditions, one-ways and the right asset model are discovered after the fact. THE ORDER THAT WORKS Decide the geography before you commit to the people Forecast demandDesign the lanesContract to the laneAllocate by priority Traffic, road rules, asset modelDuration and hours that fit itContracted before ad-hoc Lane design is the decision that constrains every later one. WHAT A LANE HAS TO CARRY BEFORE ANYONE SIGNS FOR IT 010203040506 Traffic actuallycalculated, notassumed Road conditionson the route Highways andone-ways toavoid The right assetmodel for thelane Working hours,which differ perworker One-way or roundtrip, and its cost The order of these decisions determines how much room you have left in the last one.

Lanes can be redesigned against operational and business constraints, then run as static routes alongside dynamic optimisation.

The lanes you design come with their own challenges: traffic actually calculated rather than assumed, road conditions, highways and one-ways to avoid, and the right asset model. Each worker can also have different working hours. Lanes further depend on the nature of the deliveries. If you only run forward deliveries, the vehicle and driver may not need to return to the depot. Using a driver for a round trip is always available as an option, and it costs more.

Locus models 250+ real-world operating constraints in one decisioning layer, across owned fleet, contracted carriers and purchased capacity. See how the constraints are modelled.

5Cost as an input, not a report

Optimising for the right cost model

Cost is the metric most operators track when evaluating a TMS, but the structure underneath the number is multi-factor: route distance and time, resource cost across the fleet you own, workforce cost including agency and subcontracted labour, and the cost of trailers and tractors.

Ask a data scientist whether it is better to optimise the routes and then apply cost to arrive at a total, or to build the relevant costs into the model itself, and the answer is the same. The model gives better results when cost goes in as an input parameter.

Fig. 6 Cost as a report, or cost as a decision variable

The difference is not the accuracy of the cost number. It is whether the number changed the plan.

Cost applied after routing compared with cost held inside the optimisation model Above, cost applied after the fact: orders feed a router that optimises on distance and time only, cost rates including a static fuel surcharge are applied afterwards, and a total cost of dispatch is reported. Cost is a number you report and it never changed which plan was chosen. Below, cost inside the model: distance, captive fleet, workforce, trailers and tractors, subcontractor rates and a refreshed fuel surcharge all feed a multi-objective optimiser together with the orders, producing the plan that is cheapest to run rather than the plan that was cheapest to price. Cost becomes a decision variable that changes which plan the optimiser picks. COST APPLIED AFTER THE FACT OrdersOptimise the routesApply the cost ratesTotal cost ofdispatch Distance and time onlyFuel surcharge held static Cost is a number you report. It never changed which plan was chosen. COST INSIDE THE MODEL DistanceCaptive fleetWorkforceTrailers & tractorsSubcontractorFuel surcharge route distanceand time cost of whatyou own core, agency,subcontracted cost per assetmodel rates per laneand per trip refreshed, notstatic Multi-objective optimiser Orders plus every cost parameter, solved together The plan that is cheapest to run Not the plan that was cheapest to price Cost is a decision variable. It changes which plan the optimiser picks.

Fuel surcharge is the clearest case: a static number is easy to hold, and a refreshed one makes better decisions.

One further point enterprises should test is whether the system improves over time. Geography changes, union demands and restrictions change, and there is a cost attached to everything the optimiser uses. A flexible optimiser takes a new cost driver as configuration. A rigid one takes it as a development cycle, and by the time that ships the union terms have moved again.

6Due diligence on the engine

Which optimisation model is under the hood

Enterprises often do not assess what optimisation techniques sit inside the platforms they evaluate. On the surface it all looks clean. The distinction that matters is what happens when a hard statutory constraint meets a cost objective, because that is where a general-purpose solver and a purpose-built one diverge.

A model that treats driver hours as a penalty will trade them away when the cost saving is large enough. A model that treats them as infeasible will not. That is not a tuning preference, it is an architectural property, and it is the one worth asking about. Ask what is proprietary, how it performs on your own data, and what happens to your roadmap when a constraint you need is not in the model yet.

11 yearsof core algorithm development
10+ patentson routing algorithms

Industry shapes the model too. Retail needs differ from those of a courier, express and parcel operator, and the constraints each uses differ sharply. Compliance varies with the nature of the customer being delivered to and the type of city or geography the demand comes from. A retail delivery at a wholesale outlet or a hypermarket takes longer depending on order volume. Does the site have space for parking? When does it open and close? What vehicle can you use to deliver there? Those are all model inputs, not notes on a manifest.

7Explainability, oversight and scenarios

What may be relaxed, and what may never be

Explainability, human oversight and traceability are no longer preferences. The EU AI Act named in section 1 attaches a date to them, and when a system chooses one decision out of millions of possibilities, knowing why it chose that one is a requirement in its own right.

Plan-level explainability. The algorithms make millions of decisions to identify the right route for each customer while optimising cost and reducing emissions. It therefore matters a great deal to be able to say why a given route was generated, or why one carrier was chosen over another.

Human in the loop. A human should oversee the decisions that matter while the regular and non-value-added work is automated end to end. Execution teams should be able to configure exactly where that line sits, and the system should learn from the feedback across geocoding, route planning and carrier scoring.

Traceability. Where decisions are taken by agents and where they are taken by execution teams, everything is time-stamped and geo-tagged for accountability at every stage of the lifecycle.

Feasibility and relaxation order. Multiple scenarios can be run to find the right fit to execute. The harder question is which constraint an operations team is allowed to relax and which it must hold. In Europe you cannot relax driver working hours by adding buffers, and you cannot touch the breaks governed by hours-of-service rules.

Fig. 7 What may be relaxed, in what order, and what may never be

Hard constraints are identical across every scenario. Only the tradeable layer moves.

The relaxation order, and scenarios run in parallel against identical hard constraints On the left, a locked box of constraints that may never be relaxed with no buffer, exception or scenario: driver hours of service, statutory breaks, zero-emission zone access, and union and contract terms. Below it, the tradeable layer in order: service-window tolerance in minutes, vehicle and trailer preference by model swap, lane preference between static and dynamic, multi-trip allowance for a second trip, and maximum stops per route by density. On the right, three scenarios run in parallel rather than in sequence. Scenario A holds everything with no soft constraint relaxed. Scenario B relaxes the first two, allowing wider windows and vehicle substitution. Scenario C relaxes the first four, turning multi-trip on and dropping lane preference. The cost and effect of each are compared, and because hard constraints are identical in every scenario the operations team only ever chooses between feasible plans. The relaxation order What operations may trade, and what it may never touch Never relaxed No buffer, no exception, no scenario Driver hours of serviceStatutory breaks Zero-emission zone accessUnion and contract terms 9 H DRIVING · 45 MIN AFTER 4.5 H · 11 H REST THE LINE OPERATIONS CANNOT CROSS 0102030405 Service-window toleranceVehicle and trailer preference Lane preferenceMulti-trip allowanceMaximum stops per route minutesmodel swapstatic or dynamicsecond tripdensity Scenarios run in parallel, not in sequence Design the hard and soft constraint decisions, then compare what they cost Scenario AScenario BScenario C Hold everything.No soft constraintrelaxed. Baselinecost and service. Relax 01 and 02.Wider windows,vehicle substitutionallowed. Relax 01 through04. Multi-trip on,lane preferencedropped. Compare the cost and the effect, then choose Hard constraints are identical in every scenario, so nothing on the compare screen is a plan you are not allowed to run. WHAT THE OPERATIONS TEAM CHOOSES BETWEEN Feasible plans only. Never between a compliant plan and a non-compliant one. The locked box is what makes the rest of the screen safe to choose from.

Driving, break and rest limits per Regulation (EC) No 561/2006

8Headquarters, region, area

Hierarchy of control

Working with enterprises, we have observed that most run decentralised planning and execution, which makes cost and efficiency leakage hard to control. When every region plans for itself, leakage happens in places nobody is measuring and nobody owns the total.

What is needed is a system that can plan and execute at region level and at area level, so that only the decisions that genuinely need to reach the execution team are passed down. Everything else can be decided centrally. In essence: choose what should be controlled, and how much of it should be controlled centrally.

Fig. 8 Three levels of control, and what belongs at each

The narrower each level gets, the less noise reaches the team that has to execute.

Three levels of control: headquarters, region and country, and area and execution Level one, headquarters, decides once and centrally: network and lane design, cost parameters and rate cards, compliance policy, which constraints are hard, and the relaxation order. One model and one cost basis, so leakage has nowhere to hide. Passed down are the approved lanes, the cost model and the constraint hierarchy. Level two, region and country, is where the nuance lives: local constraints and logic, union terms, emission-zone rules, the subcontractor pool and shift patterns, because constraints differ at every European region. Passed down is a regional plan that already sits inside the central model. Level three, area and execution, receives only what must reach the ground: exceptions, in-flight re-routes and driver allocation on the day. Three decisions rather than thirty, so the team executes rather than re-plans. LEVEL 1 Headquarters DECIDED CENTRALLY, ONCE Network and lane designCost parameters, rate cardsCompliance policy Which constraints are hardThe relaxation order One model, one cost basis so leakage has nowhere to hide Passed down: approved lanes, the cost model and the constraint hierarchy LEVEL 2 Region / country WHERE THE NUANCE LIVES Local constraints and logicUnion termsEmission-zone rules Subcontractor poolShift patterns Constraints differ at every European region Passed down: a regional plan that already sits inside the central model LEVEL 3 Area / execution ONLY WHAT MUST REACH THE GROUND ExceptionsIn-flight re-routesDriver allocation on the day Three decisions, not thirty Decentralised planning is where the leakage hides. The team executes rather than re-plans.

Constraints and logic differ by country and region, and each level can be modelled separately.

The leadership takeaway

Three questions decide whether a European TMS pays for itself

01

Do the rules sit inside the optimisation model, or are they checked around it?

That is what separates a plan you can run from one your planners rebuild by hand.

02

Does cost enter the model as an input, or get applied to a route already fixed?

Only then is the cost in your business case a number the optimiser actually worked to reduce.

03

Can the engine absorb the next regulation by configuration, not a development cycle?

And account for every decision to a regulator afterwards.

Answer those three and compliance stops being the cost of operating in Europe. It becomes the shape of the plan itself.

Notes & sources

Notes

Not every European operation needs this. An operator running one country, one mode and a single depot, with a stable subcontractor pool and no zero-emission zone on its network, can hold these rules in a checklist and get adequate results. The argument bites where several countries, union agreements and zone regimes meet one planning cycle, and where the cost of a rebuilt plan is material.

Two of the four regimes in Fig. 2 moved during 2026, and the figures quoted are current as at September 2026. Regulatory scope and dates in this area have changed more than once, so treat the thresholds as a prompt to check your own position rather than as advice. This paper is not legal advice and assumes no particular corporate structure.

Whether a dispatch or allocation system falls inside the EU AI Act's high-risk category is a scoping question each operator must answer on its own facts. Annex III covers employment and worker management, including task allocation and performance monitoring, so driver allocation plausibly falls within it. We have not asserted that it always does.

The fix is not only software. An optimiser that models constraints correctly still depends on the constraint data being right: union terms entered accurately, zone boundaries current, rate cards refreshed. Getting that data clean and keeping it clean is a programme in itself, and it sits on the operator's side of the line.

Sources

  • Driver hours, breaks and rest (Figs. 4 and 7): European Commission, driving time and rest periods, Regulation (EC) No 561/2006. Nine hours daily driving, extendable to ten twice weekly; break of at least 45 minutes, splittable into 15 then 30, after 4.5 hours at the latest; 11 hours daily rest, reducible to nine up to three times a week; 45 hours weekly rest, reducible to 24 every second week. Scope: road haulage and passenger transport in the EU, subject to specified exceptions and national derogations, so check your own derogations.
  • EU AI Act, high-risk timing (Figs. 2 and section 7): European Commission, AI Act regulatory framework · Annex III, high-risk AI systems. Annex III obligations, which cover employment and worker management, apply from 2 December 2027, postponed from 2 September 2026 by the AI Omnibus. Systems in use before that date sit outside scope unless they undergo significant changes in design; public-authority deployments have until 2 August 2030.
  • CSRD and CSDDD scope after Omnibus I (Fig. 2): Council of the EU, 24 February 2026 · PwC Viewpoint on the finalised Omnibus directive. Directive (EU) 2026/470, published 26 February 2026 and in force 18 March 2026, narrows CSRD scope to undertakings above 1,000 employees and above EUR 450 million net turnover, both thresholds. Non-EU parents are caught above EUR 450 million EU turnover with a EUR 200 million subsidiary or branch test. Wave-one companies falling out of scope receive a transition exemption for 2025 and 2026.
  • Emission zones and EV operation (Fig. 3): no single source. Zero-emission and low-emission zone rules are set city by city and change frequently, so the figure is schematic and the state-of-charge curve is illustrative rather than measured. Operators should check the specific access rules on their own network.
  • Locus figures: CO2 prevented, distance saved, years of algorithm development, patents held and orders routed are Locus's own internal measures, carried over from the source deck and not independently audited.
hemanth gowda

Hemanth Gowda

Lead - Pre-Sales

Hemanth leads Pre-sales at Locus, working closely with enterprises to optimize transportation management through advanced planning solutions. Outside of his professional role, he actively engages in sports.