Most forwarders believe they have their customers' loading point master data in the system. Geofence and telematics are meant to secure it. One field in the TMS. An address. Street, number, city. Done, or so it seems.
That is almost never true. The address in the TMS is the billing address. Or the address from the first order anyone ever entered. It points at the plant. Not at the gate. Not at the dock behind it. At a corporate customer, the billing address and the goods receiving point often sit at opposite ends of the same industrial park. A recent German address-quality study found 13.2 percent of business addresses erroneous. Across 120 million records. From 200 companies. More than in the prior study.
For a person, that is not a problem. The driver knows the dock after the second run. For an automation with geofence and telematics, it is the biggest problem there is. Arrival detection, shipment notices, demurrage evidence. All three need a coordinate at the gate. Not one that happens to be nearby.
A loading point record is more than an address. It needs the coordinate of the gate or dock. Not the reception building. A geofence radius sized to the site. Opening and check-in hours. A plant stops accepting trucks at 10pm, no matter how punctual the driver was. A notice rule. Some receivers want a heads-up by mail, others through a portal. A contact for disputes. And exceptions. Gatehouse pre-registration. A safety briefing. Gate A for pallets, gate C for bulk.
Without that record, the automation guesses. A geofence auto-built from the TMS address lands on the admin building. Arrival detection fires "arrived" when the truck turns into the visitor car park. The demurrage clock starts at the wrong moment. The notice reaches the right company. And the wrong dock. None of this shows up day to day. The workflow still reports "success." The gap surfaces only in a dispute. Once someone checks the numbers.
The obvious first step: geocode the address. Turn street and number into a coordinate. That works almost every time. Technically. The result is still often wrong for the purpose.
A geocoding service returns a coordinate for the address it was given. With a full house number, it usually lands close to the right building. Within 10 to 50 meters. Without a house number, the same service returns only the center of the postal code area. That is not a dock. That is a point somewhere in open ground.
Even a correct coordinate at the building leaves the real problem unsolved. The building is not the loading point. A plant site often has several gates. A visitor entrance. A separate goods entrance on no public map. Logistics software confirms exactly this gap. Geofences get generated automatically straight from the pickup or delivery address. As soon as the order enters the system. With no separate check on accuracy. If the address is wrong, the geofence is wrong. Automatically. Unnoticed.
The better path does not start on a map. It starts with your own runs. Every completed trip leaves position data. Where did the truck stand when a tour got marked done? Not once. Across weeks. Across dozens of runs to the same customer.
These positions form a pattern. Most sit close together. Often a few hundred meters from the TMS address. That cluster is the best candidate for the real dock. Not because anyone surveyed it. Because trucks actually stood there. While a tour got marked complete.
One number makes this gap visible. One anonymized customer project. Workflow fleetboard3/matcher-simple, a five-minute cadence. Queried on 2026-09-14 from public.workflow_runs. The matcher logs roughly 143 open position clusters per run, on an average day. At existing geofences. Only about 80 tours are carried as pending in the same window. Only about 21 clusters get matched to a tour through the geofence method. More real stop clusters than the tour plan can account for. Only a fraction resolve. That held steady across 8-12 September 2026. Clusters between 124 and 147 per day. Matches between 17 and 21. The rest are candidates. Real stops with no loading point record to match against.
That gap is the raw material. For a record that grows with reality. Instead of freezing at the first address ever typed.
A cluster does not become the new truth automatically. It is a proposal. Comparing address against cluster needs a fixed tolerance. Within 300 meters, the existing coordinate is probably usable. Maybe with a tighter geofence. Further out, the case goes to a review queue. With a fixed category. Address-cluster mismatch. Several clusters for one loading point. No cluster despite several runs. The same reason-column logic carries the vehicle master data behind a plate match. Never guess. Log the mismatch with a reason. Hand it to a person.
Every new address is a master data event this way. Not a line typed into a free-text field in a hurry. A new customer, a new branch, a second gate at the same company. Each case triggers a check. Before the coordinate goes live.
Two errors show up about equally often. In opposite directions. First: two different gates at the same company end up as one loading point. Because both carry the same billing address. Arrivals at the wrong gate get credited to the right dock. Or the reverse: marked late, though the truck stood at the side gate on time.
Second: the same dock gets two entries. From a slightly different spelling. A missing hyphen. An old postal code after a boundary change. The same duplicate check catches both. Not exact text match. Coordinate proximity plus name similarity. Entries almost on top of each other are a candidate for merging. Same address, clearly different cluster coordinates: a candidate for splitting.
Demurrage evidence from geofence data assumes exactly this coordinate. Without it, the cleanest timestamp match proves only one thing. That the truck stood somewhere nearby. Not at the agreed gate.
For dispatch, the moment of setup changes. A new loading point is not a field filled in while entering an order. It is a short check. Address geocoded. Marked provisional. Until the first completed runs deliver a cluster that confirms or corrects it.
For the driver, the navigation target changes. No longer the finance department's address. The dock coordinate, once confirmed. Fewer calls from the cab over an unfindable gate. Fewer misdeliveries to gate A when the goods were meant for gate C. And in a demurrage dispute, evidence built on a coordinate at the scene. Not at the accounting office.
Three honest limits.
A cluster from a handful of runs is unreliable. One outlier skews the picture. The automation should require a minimum run count before proposing a cluster. Or it just fills the queue.
Some loading points have no fixed dock. A construction truck delivers to shifting points. A branch takes goods at the front some days, the back on others. A wider geofence, or skipping tight detection, is the more honest answer.
And a loading point record does not decide who owns its upkeep. It delivers proposals and a mismatch list. Who approves a new loading point stays an organizational question. Not a script's.
A geocoding step on every new address. Flagged provisional. A telematics cluster over completed runs as a coordinate proposal. A review queue with fixed reasons. Mismatch, missing cluster, multiple matches. A duplicate check by coordinate plus name similarity. Not text equality. A minimum run count before a cluster counts. None of it replaces an on-site survey. All of it shows where address and dock diverge. Before the first demurrage dispute does.
How many of your loading points sit on the billing address instead of the dock? Pull a handful that caused trouble recently and check. If the coordinate is already off there, I will show you in a process check how your own telematics data builds the record.
