Time & Attendance Capture with Geofencing

Field crews, site teams and shift workers rarely sit next to the biometric reader at head office. Hours arrive as a photographed paper register, a WhatsApp message, or a supervisor's recollection at the end of the week. Someone then retypes them into a payroll sheet. Because the hours never touch NetSuite as structured data, project costing runs on estimates, overtime is argued about after the fact, and the only evidence that a technician was on site at 07:00 is that they say they were.

Adding a second biometric device does not solve it, because the workforce is not at a gate. What is needed is capture at the point of work, with enough context — time, location, and who — that the record can be trusted, and a path from that capture into the same NetSuite Time Entry records your project and payroll reporting already depends on.

ECOSIRE builds that capture layer inside your own NetSuite account.

Mobile capture

The clock-in interface is a responsive web app served by Suitelets, designed for a phone browser so there is nothing to install from an app store and nothing to update on hundreds of handsets. It authenticates through NetSuite and posts punches to RESTlets, so all validation happens server-side in SuiteScript 2.1.

The screen is deliberately short: who you are, where you are, what you are clocking on to, and one large button. Where your operation requires it, the punch can also capture a job or project selection, a work order or task, a cost centre, a note, and an optional photo taken at the moment of the punch and filed to a restricted File Cabinet folder.

Critically, the punch timestamp is taken from the NetSuite server at the moment the RESTlet receives the record, not from the device clock. A phone clock can be changed; the server clock cannot be changed by the employee. When a punch is submitted from an offline queue, both the queued device time and the server receipt time are stored, and the gap is shown as an exception for review rather than silently accepted.

Geofencing and site records

Sites are custom records holding a name, a centre coordinate, a radius, an active date range and the subsidiary and department they belong to. A punch captures latitude, longitude and the accuracy radius reported by the browser geolocation API, and the server evaluates it against the sites the employee is assigned to.

The outcome is one of three states, all configurable: inside the fence and accepted, outside the fence and flagged for supervisor review, or outside the fence and rejected outright. We generally recommend flag-and-review rather than hard rejection, because a genuine worker standing in a basement with poor GPS accuracy should not be locked out of clocking in. The accuracy radius is stored with every punch, so a supervisor reviewing an exception can see whether the device was confident about the reading or not.

Be clear about what geofencing can and cannot do. Browser geolocation requires HTTPS and the employee granting location permission, and its accuracy varies with device, indoor or outdoor position, and network conditions. Determined device-level location spoofing cannot be fully prevented from a web app. What the build gives you is a durable, reviewable record — server timestamp, coordinates, accuracy, device fingerprint and optional photo — so patterns that look wrong become visible and can be dealt with as a management matter.

Shifts, rosters and rules

Shift patterns are custom records defining start and end times, break rules, grace periods for late arrival and early departure, and the rounding convention you use. A roster assigns employees to shifts and sites for a date range, so the system knows what was expected and can compare it to what happened.

Derived from that comparison: late arrivals, early departures, missed punches, short shifts, absence against roster, and overtime beyond the scheduled hours. Overtime rules are configured to your policy — daily threshold, weekly threshold, rest-day and public-holiday multipliers — and calculated by script rather than left to a supervisor's judgement. Where your rules distinguish approved from unapproved overtime, unapproved hours are captured and reported but held out of the payroll export until they are approved.

From punches to NetSuite hours

Raw punches are not timesheets. A scheduled Map/Reduce script pairs punches into worked sessions, applies break deductions, grace and rounding, resolves the applicable rate category, and creates native NetSuite Time Entry records against the customer, project, task and service item the punch was booked to. Because these are standard Time Entry records, your existing project profitability, billing and utilisation reporting picks them up with no change.

Unpairable punches — a clock-in with no clock-out, a duplicate punch, an overnight shift crossing midnight — are not silently discarded. They are written to an exception queue with the reason, and a Suitelet gives supervisors a review screen to correct, pair or reject them, with every correction stamped with actor, timestamp and original value.

Approval, export and dashboards

Supervisor approval runs through SuiteFlow against the supervisor field on the Employee record, at the level your process requires: per punch, per day or per pay period. Approved hours are locked against further edits.

The payroll export is a scheduled script producing the file layout your payroll provider or process accepts, as CSV or fixed width, with an export log so you can prove which periods were sent and when. Where hours need to leave NetSuite to another system, SuiteTalk REST is available as an alternative to file transfer.

Saved-search dashboards give supervisors and HR live visibility: who is currently clocked in and where, attendance against roster today, exceptions ageing, overtime accumulating against threshold, and hours by project or cost centre for the period to date.

Who it is for

This is built for construction, facilities, logistics, engineering services and manufacturing operations already running NetSuite, where staff work across multiple sites or on client premises, where hours drive both project cost and payroll, and where attendance disputes and unverifiable overtime are a recurring cost.

How delivery works

Nothing is pre-built and there is no instant download. We begin with a scoping call covering your sites, shift patterns, break and rounding rules, overtime policy, approval hierarchy, and the payroll format hours must land in. You receive a fixed quote and a written scope document listing every record, script, screen and export in the build, plus what is out of scope.

The build runs as an SDF project against your sandbox account. We install there first and run a pilot with a real crew on real sites, because geofence radii and grace periods almost always need tuning against actual conditions rather than a map. Once the pilot is clean, we install into production, run supervisor and employee training, and support the first full pay period end to end. A defect-fix support window follows go-live.

Typical lead time from signed quote to sandbox installation is two to four weeks, depending on the complexity of your shift and overtime rules.

What you own

The SDF project and full SuiteScript source are handed over. The bundle is unmanaged and installed in your account, with no runtime licence check and no per-device or per-employee subscription for the code. Sites, shifts and rules are configuration you maintain yourself.