An analyst opens a mapping tool, selects the polygon instrument, and clicks four corners around a warehouse roof. The satellite image is two years old, but it is close enough. The analyst saves the geofence, assigns it to the customer site, and closes the tab. Eighteen months later, a carrier’s account manager and a shipper’s transportation manager are on a call comparing spreadsheets. The carrier’s spreadsheet shows an arrival time from the telematics system. The shipper’s spreadsheet shows a gate check-in time from the guard log. They disagree on a meaningful share of shipments by tens of minutes. Neither spreadsheet is wrong. They are measuring different things at different points with different clocks, and the contract just says “arrival at facility.” The dispute starts with a polygon drawn by an analyst who no longer works there.
When a geofence triggers a detention billing event, calculates driver pay, or initiates a theft alarm, it stops being a reference point on a map. It becomes a financial instrument. Finance departments dispute invoices based on GPS timestamps crossing a line drawn during onboarding. The physical site is a continuous operation. Distribution centers add overflow lots, move security gates, and change traffic flows. The map provider’s imagery is a snapshot. The site is a movie. A facility might add a second inbound gate a few hundred yards outside the original polygon. Inbound trucks use the new gate. The telematics system never registers an arrival. Detention is billed from the driver’s manual punch, which the shipper disputes because their system says the truck never arrived. The physical gate moved in a weekend. The digital boundary stayed in the database until someone threatened a lawsuit over unpaid detention.
Geofences assume a binary state: inside or outside. GPS hardware exists in a state of probability. Telematics units drift due to atmospheric conditions, canopy cover, or signal reflection off corrugated steel warehouse walls. A truck parked ten meters inside the fence will digitally wander across the boundary all night. A truck waiting for a dock assignment parks on the shoulder of the access road, right on the fence boundary. The GPS scatter puts it inside, outside, inside, outside, every thirty seconds. The alert engine fires an arrival, then a departure, then an arrival. By the time the driver pulls into the dock, the system has logged fourteen arrival events and fourteen departure events. The dispatcher’s screen shows a column of alerts. She highlights them all and marks them as dismissed. Alert fatigue is a system property, not a dispatcher failure. Every dispatcher has a mental list of alerts they do not read. That list is the system’s real configuration.
A location ping is a fact. An arrival is an interpretation. One polygon cannot serve four masters. Billing needs tight timestamps at the gate. Safety needs exclusion zones. Customer notification needs lead time on the approach. Dispatch cares when the truck reaches the dock. If you draw a single fence around a legal property line, you build a machine for generating false positives. A distribution center sitting parallel to a major highway might have a geofence that bleeds into the right lane of the road. Every time a fleet vehicle drives past at highway speeds, the system logs an arrival, a dwell time of three seconds, and a departure. You have to separate the geofence fact from the business rule. The rule should be versioned, owned, and testable.
To make these events reliable, you need to engineer the transition from a raw ping to a business event. A single position just inside a polygon is a guess. A ping plus a gate RFID reader, a dock door sensor, or a driver mobile app check-in is evidence. Billing-grade events need two witnesses. The precedence order must be written down before the first dispute. A gate log beats a fence for arrival. A dock sensor beats a fence for departure. A driver punch beats a fence when the fence is missing.
To handle the GPS drift, the system needs hysteresis. Group pings into a track and compute the probability that the asset is inside the fence. Require a vehicle to remain inside the polygon for a sustained duration—say, three consecutive pings—before triggering an arrival. Make the exit threshold asymmetric. Require five consecutive pings outside the fence to trigger a departure. The asymmetry prevents a truck idling at the boundary from generating a stream of events. The cost is a few minutes of latency on departure, which matters for billing and must be documented.
Fences are code. They have versions, dependencies, tests, and change reviews. Most tools treat them as drawings, and most organizations treat them as one-time setup. When a new transportation manager asks who maintains the thousands of fences across the network, the answer is usually that they were drawn during onboarding by whoever was on the project. The person who drew most of them left two years ago. There is no change log. The tool has an edit button and no history tab.
Each fence needs an ID, a version, a geometry hash, an owner, and a review date. The event record must reference the fence version, not just the fence ID. If the fence changes, old events keep their old geometry for audit. Before deploying a fence change, run the last 90 days of GPS pings through the new geometry and the old geometry. Diff the events. If the change alters a large percentage of billing events, require a review. This is a continuous integration practice for geofences, and almost nobody does it.
The fence will be wrong. A tractor drops a trailer in a shared yard and leaves. The tractor GPS reports a departure. The load system marks the shipment departed, though the trailer remains on site. A device loses coverage inside a metal-sided facility and uploads several stored positions on the way out. An event processor using receipt time rather than device time produces a short, false visit.
The costly failure is not a missed event. It is a plausible but wrong arrival time that flows into an invoice, a customer scorecard, and a driver record without review. The exception queue is the product. Events that do not match the expected pattern—arrival without a matching appointment, dwell exceeding threshold, departure without a gate log entry—must go to a queue. The queue needs an owner, a service level agreement, and a disposition. Uncertain events get a disposition to corroborate, send for review, or leave unconfirmed. Do not silently promote every location hit into a billable event. An alert that nobody has time to investigate is not an exception process.
The contract language and the system logic should match. If the contract says “arrival at facility” and the system uses fence entry, the gap is the dispute. You are not mapping the earth; you are mapping the operational agreement. The polygon is cheap to draw and expensive to get wrong. The maintenance cost is real, but the cost of not maintaining it is larger and less visible until the first invoice gets rejected.
Take it with you
Takeaways
- Separate the geofence fact from the business rule, and version both.
- Use hysteresis and asymmetric thresholds to handle GPS drift at fence boundaries.
- Treat the exception queue as the product, not an afterthought.
- Match contract language to system logic before the first invoice dispute.
Asked and answered
Questions
Why do geofence-based arrival times disagree with gate logs?
They measure different things at different points with different clocks. A geofence triggers on GPS position relative to a polygon, while a gate log records a physical check-in. The contract may say 'arrival at facility,' but the system and the guard log are not measuring the same event.
How do you handle GPS drift causing false arrivals and departures?
Group pings into a track and require sustained presence inside the polygon—such as three consecutive pings—before triggering an arrival. Use an asymmetric exit threshold, like five consecutive pings outside, to prevent a truck idling at the boundary from generating a stream of events.
Who should maintain geofences across a large network?
Each fence needs an ID, a version, a geometry hash, an owner, and a review date. Before deploying a change, run the last 90 days of GPS pings through the new and old geometry and diff the events. If the change alters a large percentage of billing events, require a review.