The short answer
A raw GPS coordinate proves nothing about where a phone actually is, because GPS location on a phone is just a value an app reads from the operating system — and that value can be faked. Verifying field-employee location reliably requires several independent layers working together, not a single geofence check.
Why a geofence alone doesn't hold up
The common approach to field attendance is: draw a geofence around the work site, check that the employee's reported GPS coordinate falls inside it, mark them present. This fails for a simple reason — a mock-location app can report any coordinate the user chooses, including one that sits neatly inside the geofence, without the phone physically being there. On Android, enabling a mock-location provider is a few taps in developer settings. Free apps exist for exactly this purpose. A geofence check that trusts the coordinate it's given will pass every time, spoofed or not.
The layers that actually catch it
Mock-location detection. The device can be asked whether the location it's reporting came from a mock provider — Android's location API exposes this directly, and a well-built client checks it before ever transmitting a coordinate. This catches the most common, least sophisticated spoofing attempts, but a determined user can work around detection that lives entirely on the device they control.
Device attestation. Rather than trusting the app's self-report, attestation checks whether the device itself is in a known-good state — not rooted, not running in an emulator, not manipulated at the OS level. This closes a real gap: mock-location detection that runs inside the app can be tampered with on a compromised device; attestation checks the device's integrity independently of the app.
Server-side trajectory checks. Coordinates that look individually plausible can still be impossible together. If a check-in comes from one location and, twelve minutes later, another comes from a location forty kilometers away, no real movement explains it — the server, not the device, is what catches this, because a compromised client can't lie to a check it never gets to see. This is one of the more reliable layers precisely because it runs somewhere the spoofer has no access to.
Identity binding. Location verification and identity verification are separate problems, and solving one doesn't solve the other — a correctly-located device can still be in someone else's hands. Binding a check-in to a biometric or device-bound credential closes the classic "buddy punching" gap, where a colleague carries a phone to false-checkin on someone else's behalf. Location without identity just tells you a phone was in the right place.
Why no single layer is enough on its own
Each layer defeats a different attack, and each has a gap the next layer closes: mock-location detection lives on a device the user controls, so it can be defeated by a sufficiently determined attacker; attestation raises that bar but doesn't verify identity; trajectory checks catch impossible movement but only after the fact; identity binding stops impersonation but says nothing about whether the location itself was real. Defense-in-depth here means exactly what it means in any other security context — no single check is trusted alone, because every single check has a known way around it.
What this means for building field-force software
Attendance and field-verification software that stops at "check the coordinate against a geofence" isn't actually verifying anything an even mildly motivated user can't defeat in a few minutes with a free app. Software that holds up combines device-side signals with independent server-side checks, and treats location and identity as two separate problems that both need solving — not one problem with a single geofence-shaped answer.