How to check DVS before a London delivery fails
A practical guide to using a DVS checker for UK haulage: what it shows, what to verify before a job, and how to avoid refused London deliveries.
If you take London work, a DVS check needs to happen before the job is accepted, not while the driver is on the way to site. A proper DVS check tells you whether the vehicle is rated appropriately for the Direct Vision Standard rules, whether a permit is in place where one is needed, and whether the job can legally and practically go ahead inside the London area covered by the scheme.
For small and mid-size operators, that matters because failed checks do not just mean a fine. They mean refused deliveries, wasted miles, missed slots, upset customers, a driver tied up on the wrong side of the river, and an invoice that goes out late because the job never finished cleanly. A DVS checker is useful only if it is part of traffic planning, not a box someone remembers to tick after the six o'clock phone call.
What a DVS checker is actually for
A DVS checker is there to answer a simple operational question. Can this specific vehicle do this specific London job under the current Direct Vision Standard and permit rules?
For a UK haulage operator, that means checking more than the postcode. You need to know which vehicle is going, what star rating applies to that vehicle, whether a permit has been granted by Transport for London where one is required, and whether the route or delivery point falls inside the DVS enforcement area. If you need a quick reference for the area itself, our map of the DVS zone in London helps planners confirm whether the drop is actually inside scope.
This is a London rule, not a general UK or EU-wide one. That matters because operators often assume that if a vehicle is legal and correctly operated under broader UK road transport rules, it is automatically fine for a London delivery. It is not. DVS sits alongside the rest of your obligations, it does not replace them. A vehicle can be taxed, plated, insured, compliant with its O-licence requirements, and still be the wrong vehicle for a London job if the DVS position is wrong.
The point of using a DVS checker is not to admire the rulebook. It is to make a dispatch decision. Do we send our own vehicle, swap to another unit, move the job time, ask the customer to rebook, or put it onto a subcontractor with the right setup? If you only discover the answer when the driver reaches the edge of the zone, the checker has been used too late.
For container operators, this is even more practical. A failed London leg can upset the whole day. One wrong vehicle on a timed box collection or delivery can knock container turnaround, push storage and demurrage risk, and ruin the backload that was meant to make the trip pay.
What to check before you send the vehicle
Before a vehicle is allocated to a London job, we need three things checked together, the vehicle, the job, and the permit status.
Start with the vehicle.
Confirm the exact registration that is intended to run the job. Not the unit you thought would be free yesterday, the one actually being loaded into the plan now. DVS checks attached to the wrong reg are a common source of trouble, especially where operators swap vehicles late because of workshop issues, tyre damage, driver hours, or a trailer problem.
Then confirm the vehicle details you hold are current. In practice that means making sure your office record matches the actual truck in service. If a vehicle has changed, been replaced, or returned to fleet after modification, your planning notes need to reflect that. The DVS position belongs to the actual vehicle, not to a fleet nickname or a driver's usual motor.
Next, check the job itself.
You need the full delivery or collection address, not just "London" and a customer name. Plenty of jobs are described loosely by customers or copied badly from a message chain. If the actual site falls inside the relevant area, the rule applies whether the booking clerk mentioned it or not. Check the postcode, then the access point if the site has more than one entrance. Construction sites, depots and retail distribution points often have a vehicle gate in a different location from the office address.
Also check timing. A planner may assume a job is outside scope because the first leg starts elsewhere, but if the vehicle enters the zone later in the shift, it still needs to be right before it goes. This catches operators doing multi-drop work, container repositioning, and jobs that change during the day.
Then check permit status.
If the vehicle requires a permit for the work, confirm that the permit is actually in place and that the registration matches exactly. Do not rely on "we applied for that one" or "it should be covered". A surprising number of failed jobs come from assuming an application, an old permit, or a similar registration is enough. It is not.
Finally, check the commercial side while you are still in the office. If the planned vehicle cannot legally do the job, decide who pays for the change before the driver leaves. If a different vehicle costs more, or if the slot needs moving, capture that while the customer is reachable. It is far easier to agree a revised charge at planning stage than after a failed attendance.
A basic pre-dispatch checklist for London work should include:
- Vehicle registration
- Vehicle DVS status in your records
- Permit status where required
- Full collection and delivery address
- Confirmation that the route enters the London zone or not
- Driver brief, including any site-specific restrictions
- Customer contact in case the vehicle has to be changed
- Agreed commercial note if the job has been repriced or rescheduled
That is the level of checking that stops a delivery being refused on the day.
Where operators get caught out
Most failed London jobs do not come from obscure legal arguments. They come from ordinary working-day mistakes.
The first is checking the customer, not the vehicle. Someone remembers that "we do that site all the time", so the assumption is that this booking is fine too. But the site being familiar tells you nothing about whether today's allocated registration is suitable.
The second is relying on memory. In a fleet of three to fifty vehicles, someone usually "knows" which trucks are fine for London. That works until a vehicle is sold, hired in, swapped, or taken off the road. Memory is not a record.
The third is late vehicle swaps. A truck gets a defect, a driver runs out of time, the trailer is not ready, or the unit booked for the job is still waiting to tip. Traffic switches the load onto another vehicle and forgets that the DVS position has changed with it. The original plan may have been compliant, the revised one is not.
The fourth is incomplete job information. The office gets "deliver Park Royal" or "site in Dagenham" over the phone, and nobody pins down the exact address until the driver is already moving. At that point the planner is trying to do compliance work by mobile while also sorting the rest of the day.
The fifth is poor handover between office and driver. Even when the permit side is fine, the driver may not know the access point, booking reference, site restrictions, or who to call if turned away. A London refusal often starts as a communication failure before it becomes a compliance problem.
The sixth is bad paperwork discipline after the event. If a job fails or is rebooked, but nobody records why, the same mistake repeats next week. Then the invoice is wrong, the customer disputes waiting time, and the POD trail is a mess.
This is where software helps indirectly. Not by claiming to make a vehicle compliant, but by keeping the job notes, the reg, the brief, the POD and the status in one place. If you are still chasing screenshots across WhatsApp and trying to remember which planner spoke to the customer, the real cost of a failed run goes far beyond the mileage.
How to build the check into traffic planning
For small fleets, the best process is the one that actually happens every day. It does not need an implementation project and it does not need a compliance manager sitting in a separate office.
The key is to move the DVS check to the point where the job first becomes real.
If you run mostly on phone calls and paper notes, add a London prompt to the booking step. When a job comes in, the person taking it asks two things immediately. Is the site in Greater London, and what exact vehicle is likely to do it? If the job is in scope, mark it clearly on the traffic sheet before it disappears into the day's pile.
If you use a spreadsheet, add a column for London DVS check status. Keep it simple. "Not needed", "Check required", "Checked", "Vehicle changed - recheck". The point is not elegance, it is visibility. Anyone looking at the sheet should be able to spot the jobs that cannot be dispatched until somebody has verified them.
If you use WhatsApp heavily, stop letting the check live only in message threads. A message saying "that one is fine for London" is useless next Tuesday when someone else is planning the run. Put the result into the job record, the spreadsheet, or at minimum a shared planning note that survives the day.
If you run a TMS, build the step into allocation. The planner should be able to see the vehicle registration, the destination, and the job notes together before confirming the dispatch. In Logivo, that is the practical value of having jobs and vehicle movements visible in one place through the shared jobs grid for daily traffic planning. It gives the office somewhere to record the actual decision, not just talk about it.
A workable routine for a small office looks like this:
- Booking comes in.
- Office confirms exact delivery or collection point.
- Job is flagged if London is involved.
- Likely vehicle is identified.
- DVS and permit position is checked against that registration.
- Result is written into the job notes.
- If the vehicle changes, the check is repeated before dispatch.
- Driver receives a proper brief with address, contact details and any warning notes.
- POD and job outcome are attached back to the same job record.
That process works whether you have one planner or six. The important part is the trigger. The check happens at booking and again at vehicle change, not after the driver phones from the road.
It also helps to have one person own the exception handling. If a vehicle is not suitable, someone needs authority to swap it, move the slot, notify the customer, or assign a subcontractor. Otherwise the problem sits in limbo while the clock runs down.
For operators who do regular London work, a short standing list of approved vehicles is useful, but only if it is kept current. A stale list is worse than no list because people trust it.
What software can and cannot do here
Software can help you control the process. It cannot make a non-compliant vehicle acceptable for a London job, and it cannot replace checking the official permit and vehicle details.
What it can do well is hold the information where the planner needs it.
A decent TMS should let us record vehicle registrations accurately, attach notes to jobs, flag jobs that need attention, and make sure the driver sees the latest brief rather than yesterday's version. It should also keep the operational record together after the job, so when a customer asks why the delivery slipped, we are not piecing the story together from texts and memory.
That matters because DVS problems rarely stay in one box. They affect dispatch, customer communication, driver briefing, POD capture and invoicing. If the job fails, the office still needs a clean record of what happened, who spoke to the site, whether the vehicle attended, and whether any charge should be raised or disputed.
In Logivo, we focus on those practical parts. We keep the job, updates, driver brief and delivery evidence together. Our driver progress and status updates help the office see what is happening without ringing every hour, and our invoicing workflow after POD is back helps close the gap between a completed job and the invoice going out.
That does not mean software "does DVS compliance" by magic. It does not. You still need the correct vehicle data, the correct job address, and the correct permit status. What software can do is reduce the ordinary failures that cause London jobs to go wrong in the first place:
- the wrong reg on the job
- the brief stuck in a WhatsApp thread
- the late vehicle change nobody recorded
- the missing POD after a refused delivery
- the invoice held up because the office cannot prove what happened
For smaller operators, that is usually the real win. Not a glossy compliance dashboard, but fewer wasted runs, fewer arguments, and less time between the wheels stopping and the invoice being sent.
If London work is part of your week, make the DVS check a planning step, not a rescue job. The operators who handle it best are not necessarily the biggest. They are the ones with a routine that survives a busy morning, a vehicle swap, and that six o'clock phone call. If you want a straightforward way to keep jobs, driver updates and POD together without adding another layer of admin, see more on our haulage software articles and guides.
What does a DVS checker show?
It is used to check whether a vehicle is suitable for DVS-related London work and to confirm the details you should verify before dispatch.
Do I need to check every vehicle for every London job?
If the work depends on DVS rules, yes. The risk is planning the wrong unit, then finding out too late when the driver is already on the move.
Is a DVS check the same as checking the route?
No. A DVS check is about whether the vehicle is acceptable for the job. Route planning is separate and still needs to be done properly.
Can a TMS do the DVS check for me?
A TMS can help you keep the right vehicle details against the job and make the check part of planning, but you should not assume it makes the check on your behalf.
Why does this matter for invoicing?
If a job fails or is delayed because the wrong vehicle was sent, POD is delayed, disputes start, and the invoice often goes out days or weeks later.