Cloud-Based Attendance Software for Distributed Teams

Cloud-based attendance software is usually sold as the same product as the on-premise one, hosted somewhere else. That framing is why so many deployments disappoint. Moving the server does not change anything a distributed team cares about. What changes things is that the record no longer has a building attached to it, and almost every assumption inside a traditional attendance system is quietly built on there being one.

A fixed device answers three questions at once and you get two of them free. Who is this, is it really them, and where are they. Take the building away and the third question stops answering itself, the second gets harder, and the first is the only one the technology was ever really about. That is the whole difficulty, and it is a design problem rather than a hosting problem.

This piece is about running attendance for people who do not all arrive at the same place: field teams, multi-site operations, remote staff, hybrid offices, and the mixtures of all four that most Indian companies actually have. The broader case for running distributed teams on shared systems is in our piece on how HR software supports distributed teams. What to capture, what to do when the network is not there, what belongs in configuration rather than in a policy document, and where measuring more starts costing more than it returns.

One thing up front, because most of the recommendations follow from it. For a distributed workforce, attendance software does not record a fact. It creates one. When everybody came to an office, attendance was an observable event and the system wrote it down. When people work from homes, client sites, vehicles and three cities, the boundary of the working day is not observable, and whatever your system captures becomes the official version of it. That is a much larger responsibility than a punch clock ever had, and it means the important decisions are about what to capture rather than how accurately to capture it. Get that order wrong and you will build a precise record of the wrong thing.

What follows reflects the distributed deployments we run and the on-premise systems we regularly migrate off. Engage handles attendance for more than 40,000 employees across factories, retail chains, offices and field operations. Where something below is flagged as a common failure, that is what we see in real configurations rather than a guess about what might be in them.

This is general guidance for employers, current as at the date above. It is not legal advice. Indian labour rules under the Labour Codes are being notified state by state on different timetables, and several positions below will change as that happens.

What Cloud-Based Attendance Software Actually Changes

Cloud-based attendance software changes four things, and only the last two are worth choosing a product over.

You stop maintaining a server. Real, and the smallest of the four. It is the benefit vendors lead with because it is the easiest to explain.

Upgrades stop being projects. Also real, and more valuable than it sounds in a year when the law changed twice. On-premise attendance systems in India are routinely three or four versions behind, because upgrading is a project someone has to schedule, and a system that is three versions behind is currently computing overtime under rules that were repealed in November 2025.

Every site writes to one record. This is where the value starts. Multi-site on-premise deployments drift: each location ends up on a different version with its own shift master and its own holiday calendar, and producing a consolidated view becomes a manual merge that nobody trusts. One record removes an entire category of work rather than making it faster.

Capture stops requiring hardware. This is the one that actually matters, and it is the one that has nothing to do with hosting. If attendance can be captured from a phone, then the set of people you can include expands to everybody, and the question of what counts as attendance becomes a policy question rather than a coverage problem. Every section below is downstream of this.

What does not change, and this is worth saying because it is often implied: cloud does not make attendance more accurate, does not remove the need for identity verification, and does not by itself help with compliance. A cloud system with a badly configured shift master produces wrong numbers faster and from more locations. The architecture is an enabler; the attendance engine is still the product. That argument is worked through in our biometric attendance system buyer's guide, and it applies here unchanged.

The Four Kinds of Distributed Team

"Distributed" covers four situations with almost nothing in common, and the single most common configuration error is applying one policy to all of them. Most Indian companies of any size have at least three.

The third column decides everything else. The first three rows have a real purpose: somebody's pay or somebody's legal exposure depends on the record. The fourth row usually does not. A salaried knowledge worker's pay does not vary with the hours recorded, so the attendance record is not computing anything. It is being collected because the system can collect it.

Deploying wage-grade attendance capture on a workforce whose wages do not depend on it is the most common expensive mistake in this category. It costs trust, it generates data you then have to protect and retain, and in the specific case discussed in section 9 it can manufacture evidence of a compliance breach you would not otherwise have had. If the goal for hybrid staff is knowing how full the office will be on Wednesday, measure occupancy with a desk booking, a door badge or a self-marked in-office day, and do not build it out of a wage-computation system.

Capture When There Is No Door

Take away the fixed device and you have to replace three things it was doing at once. Getting one of the three and calling it attendance is where most field deployments fail.

Identity. On a phone, the app is on the person's own device, which proves possession of a phone rather than presence of a person. Mobile face capture with liveness detection is the workable answer, and liveness is doing more work here than on a fixed device because you control neither the camera nor the lighting. A PIN or a simple app tap proves only that the phone was unlocked, which is exactly the buddy-punching problem in a new form: forwarding a colleague's login is easier than lending them a card ever was.

Location. This is the part a fixed device gave you free. Options run from a geofence around a defined site, through a coordinate captured at the moment of punch, to continuous tracking through the day. The right choice is almost always the middle one and almost never the third, for reasons section 7 goes into. For a field engineer, the coordinate at check-in against the customer address is both the compliance record and the operational one, and it is proportionate. A geofence is better where staff visit a known set of locations, because it captures a yes-or-no rather than a coordinate, which is a genuinely smaller intrusion for the same result.

Time. On a fixed device the clock is yours. On a phone it belongs to the employee, and phone clocks can be changed. The system must timestamp on the server, or timestamp on the device and reconcile against server time at sync, flagging the difference. If a vendor has not thought about this, they have not built for field use, and it is a good question to ask early because the answer is quick and diagnostic.

Two things worth deciding before you deploy rather than after.

What happens when someone has no phone, a broken phone, or a phone that will not run the app. A field employee who cannot mark attendance is not absent; they are unrecorded, and the fallback is usually a supervisor marking them manually, which is fine as long as it is a recorded, attributable exception rather than a daily habit. If more than a small fraction of your field attendance is manual, the capture method is not working and the record has quietly reverted to a supervisor's word.

Whether personal phones are acceptable at all. Requiring an employee to install a company app on a personal device, and to enable location and camera permissions on it, is a real ask, and it is one many employers make without noticing they are making it. Either provide devices, or make the terms explicit and the app's behaviour narrow enough that the ask is reasonable. Section 8 covers what narrow means.

Our field tracking module is built around the middle option throughout: identity and location at the punch, not continuous observation between them.

Offline, Sync and the Network Reality

Every cloud attendance vendor claims offline support. The implementations differ enormously, and in Indian conditions this is not an edge case. A field engineer in a basement, a factory in an industrial area with poor coverage, a retail outlet on a bad day. If offline is not solid, your attendance record has holes exactly where the work is hardest.

What correct offline behaviour means, in order of how often it is got wrong:

Capture must complete offline, and the employee must know it worked. An app that spins and fails leaves the person standing there, and what they do next is call a supervisor, who marks them manually. We see the consequence on most field deployments we take over: a weak offline implementation converts part of the workforce back to manual attendance permanently, because once people stop trusting the app they stop trying. The reversion is quiet and it does not undo itself when the app is fixed. By then the habit is the supervisor, not the phone.

The timestamp must be the moment of capture, not the moment of sync. Obvious, frequently wrong, and catastrophic when wrong: it turns a 9am punch into an 11am punch and generates a late mark for someone who was on time. This one produces disputes that destroy confidence in the whole system.

Sync must be idempotent. If a sync half-completes and retries, you must get one punch, not two. Duplicate punches are worse than missing ones because they look like data and quietly corrupt an overtime calculation.

Buffer depth needs a number. Ask how many punches a device or app stores offline and what happens when the buffer fills. "It just works" is not an answer.

Test all four before you sign. Put the phone in airplane mode, punch, wait, reconnect, and check what arrived and with what timestamp. Do the same on a fixed device by pulling the cable. This takes ten minutes and it is the most informative ten minutes of any cloud attendance evaluation.

Design consequence worth stating plainly: an attendance system for Indian conditions should be offline-first rather than offline-tolerant. Those are different architectures. Offline-tolerant means the app degrades when the network drops. Offline-first means the app never depends on the network for the employee's action at all and treats sync as a background concern. You can tell which one you are looking at by whether the punch confirmation appears instantly with the network off.

Policy as Configuration, Not Documentation

The hardest part of distributed attendance is not capture. It is that a distributed workforce has more than one set of rules, and a policy document cannot apply itself.

A retail chain across four states has different weekly closure rules, different state holiday calendars, which we track as a state-wise holiday list, different Shops and Establishments hours, and different shift patterns per format of store. A services company has an office shift, a client-site shift, a night support roster and a field team, all under one HR function. None of that is unusual. All of it is impossible to run consistently as a document that managers are supposed to have read.

What has to live in configuration rather than in a PDF:

The last row is where this goes wrong most often. Where a system generates more exceptions than managers can genuinely review, approval tends to become a bulk action at month end, and at that point the approval step has stopped adding anything to the record.

The useful response is to find out which kind of exception you have before deciding what to do about it. Some exception volume is real: people do arrive late, field routes do change, and a workforce with genuinely irregular hours will generate genuinely irregular records. Some of it is configuration: a geofence radius drawn tighter than the site, a shift master that does not match the roster people actually work, a grace period set for a different population. The two look identical in a report and call for opposite responses, and the configuration kind is worth ruling out first, because no amount of chasing approvals will reduce it.

A reasonable check is to sample a week of exceptions and ask, for each one, whether a correctly configured system would have raised it at all. If most would not have, the queue is telling you about your setup. If most would have, it is telling you about the work, and the answer is a policy decision rather than a configuration change.

The multi-state version of this argument, and why a spreadsheet cannot hold it, is in replacing Excel with HR software.

Time Zones and the Problem Nobody Configures

Most Indian companies do not think they have a time zone problem, and most of them are right. Two situations change that, and both are increasingly common.

Staff working to overseas hours. A support team on US hours starts a shift at 7pm IST and finishes at 4am IST. That shift crosses midnight, which means it spans two calendar days, and the question of which day it belongs to determines the day's attendance, the weekly hours total, the overtime computation and the payroll period it falls into. Systems that store a date and a time rather than a shift instance get this wrong, and they get it wrong silently.

Genuinely distributed teams across countries. Here the rule is simple and frequently broken: store everything in UTC, display in the employee's local zone, and compute statutory limits in the zone of the applicable law. An Indian employee's daily eight-hour limit is an Indian-day limit regardless of where they were sitting.

Three things to test, because they are the ones that break:

A shift crossing midnight on the last day of the month. The hours should land in one wage period, consistently, and you should be able to say which. A shift crossing a daylight-saving transition in another country, if you have staff on overseas hours. The shift is an hour shorter or longer that day, and the system should reflect what actually happened rather than what was scheduled. And a weekly off for a night-shift worker, which is the case that reveals whether the system understands shifts or only dates: their "Sunday off" is not the Sunday calendar day.

None of this is exotic and all of it is routine in Indian services businesses. It is worth testing specifically because it is the class of defect that produces a small, persistent error that nobody can explain and everybody stops trusting the system over.

Where Monitoring Stops Paying

Cloud attendance systems can capture far more than attendance, and the modules are usually sold together: continuous location, screenshots, application usage, idle detection, keystroke activity. The question of how much to switch on is treated as a matter of company culture. It is better treated as a matter of data quality, because the returns turn negative before the ethics do.

The reasoning is straightforward. Attendance data is generated by people, and people respond to being measured. A record of when someone started and finished is not something they have much reason to game, and it is reliable. A measure of activity is something they have every reason to game, it is trivially gamed, and the moment it is gamed it stops measuring what it claims to and starts measuring willingness to perform activity. You have not gained visibility; you have added noise and paid for it in trust.

There is a practical line, and it holds up better than either extreme.

Capture the boundaries of the working day and the location that a wage or a compliance obligation depends on. Start, end, breaks, and where the person was at check-in if presence matters. This is proportionate, it is defensible to the employee, it supports every legal obligation you have, and none of it is worth gaming.

Do not capture continuous location, screen contents or activity for salaried staff whose pay does not vary with any of it. The data is unreliable for the reason above, it creates a genuine data protection burden, and it is the fastest way to convert an attendance rollout into an industrial relations problem.

The exception worth naming, because it is real: continuous location for lone workers in hazardous environments, or for high-value transport, is a safety and security control rather than an attendance one. That is a legitimate purpose. It should be run as a separate purpose, with its own notice, its own retention and its own justification, and not folded into the attendance system because it is technically convenient. Purpose limitation is not just a legal requirement here; it is what makes the safety case defensible.

If what you actually want to know is whether people are doing good work, that is a performance management question and attendance data will never answer it. The most useful question to ask about any monitoring feature before enabling it: what decision will change based on this data? If nobody can name one, you are collecting it because the checkbox exists, and that is the definition of the intrusion being unjustified. The wider discipline of running HR on numbers you have actually chosen is covered in data-driven HR.

Data Protection and Location Data

A distributed attendance system collects two categories that a fixed one does not: location, and, for mobile face capture, biometric data on a device you do not control. Both sit under the Digital Personal Data Protection Act, 2023 and the DPDP Rules notified in November 2025.

The obligations are the general ones: notice of what you collect and why, use confined to that purpose, security safeguards, and erasure when the purpose ends. Employment is among the recognised legitimate uses, which comfortably covers attendance data used to compute wages and to meet statutory record obligations. It does not stretch to cover whatever else the same app can capture.

Note in passing, because it is repeated widely and is wrong: the DPDP Act does not create a separate sensitive personal data category, and biometric data has no special status under it. That distinction belonged to the SPDI Rules, 2011 and was not carried forward.

Four configuration decisions carry most of the risk.

Capture location at the punch, not between punches. A coordinate at check-in and check-out supports the attendance record. A continuous track does not support it any further, and it is a materially larger collection with a materially harder justification. If the app collects location in the background, that is a separate purpose requiring separate notice, and most deployments have not given one.

Prefer a geofence result to a coordinate where you can. Recording "inside the assigned site: yes" rather than a precise position achieves the same compliance outcome with less data. This is data minimisation done as configuration, and it is one of the few places where the privacy-preserving option is also the operationally simpler one.

Retain location for as long as the attendance record it supports, and no longer. Section 9 covers the five-year retention on the attendance record itself; the coordinate that evidenced a single punch does not need the same life, and continuous tracks should not be retained at all.

Purge biometric templates on exit while keeping attendance records. Two different rules on two different data types, and almost no system separates them by default. The templates identify a person at the moment of a punch and have no purpose after they leave; the attendance record is a statutory obligation for five years.

Beyond the law, one practical point that decides whether a distributed rollout succeeds. Tell people exactly what the app collects and when. Employees assume a location-enabled work app tracks them continuously, because some do. If yours captures a coordinate twice a day, saying so plainly, and being able to show them their own record, removes most of the resistance you would otherwise spend months absorbing. The rollouts that go badly are almost never the ones that collected too much. They are the ones that did not say.

Compliance for People Who Never Attend

Indian labour law was written for people who arrive somewhere, and the obligation to record hours does not lift because they do not. This section is the short version; the full position is in our guide to attendance compliance in India under the Labour Codes.

Four points that specifically bite distributed employers.

The muster roll obligation applies to remote and field staff. You need a record showing daily attendance with in and out times for every person, for every day of the wage period, including absences and weekly offs. A weekly self-declared timesheet approved in bulk does not satisfy this in substance, and it is what a large share of field operations actually run. The filings that sit alongside these records are on our compliance page.

Overtime is tested daily as well as weekly. Beyond eight hours in a day or forty-eight in a week, whichever is crossed first, at twice the ordinary rate. A system configured to compute overtime weekly will miss the person who worked ten hours on Monday and took Friday off. This is a common defect in systems configured before the Labour Codes came into force in November 2025, and it is one of the more expensive ones.

Retention is five years from the last entry, up from three under the repealed rules, and this applies to the attendance record wherever the person was sitting when it was made.

Spread-over is the distributed employer's real exposure, and it is worth understanding properly. Spread-over is elapsed time from the start of work to the end of it, capped at twelve hours. A remote employee who joins a call at 8am and answers a message at 9pm has a thirteen-hour spread-over. Their total hours worked may be entirely unremarkable. If your systems can evidence both events, you have created a record of a breach that would not otherwise exist.

That last point is uncomfortable and it is not an argument for recording less, which would be both non-compliant and cowardly. It is an argument for deciding the boundary before you generate the data about it. If you expect people to be available across a thirteen-hour window, the problem is the expectation, and the attendance record has simply made it visible. Set the working window in policy, configure the system to it, and treat activity outside it as an exception that someone approves, which is what you would do with overtime in a factory. There is no principled reason to treat it differently because the work is done at a laptop.

The neighbouring leave and holiday obligations, which vary by state and complicate every multi-site calendar, are in leave policy requirements under Indian labour laws.

Migrating to Cloud Attendance Software

Most cloud attendance deployments in India are replacements rather than first systems, and the migration has a predictable shape.

Do not migrate historical punch data. Migrate historical registers. You need the statutory record for the retention period, which is the muster roll and wage register as they stood, not a raw punch archive from a system whose shift definitions you are about to change. Recomputing old punches under new rules produces numbers that match neither the old registers nor reality. Export the registers as records, archive them, and start the new system from a clean date.

Start the new system at the beginning of a wage period. Mid-month cutovers require running both systems for a partial period and merging the results, which is exactly the manual reconciliation the migration is supposed to eliminate.

Re-enrol biometrics rather than importing templates. Templates are usually not portable between vendors, and the attempt to convert them tends to produce a population of marginal enrolments that fail intermittently for months. Re-enrolment is a day of inconvenience against a year of intermittent failures, and it is also the natural moment to fix the enrolments that were poor on the old system.

Rebuild the shift and holiday masters rather than importing them. This is the unwelcome one. The old masters are usually the accumulated residue of years of exceptions, and importing them carries every historical mistake into the new system where it is much harder to find. Migration is the only realistic opportunity you get to rationalise them, and the effort is smaller than the year of unexplained variances that follows from skipping it.

Run parallel for one full wage period, and reconcile deliberately. Not to check that the new system works, but to find where the two disagree, because every disagreement is either a defect in the new configuration or a defect in the old one that you have been paying for. Both are worth knowing, and the second is often the larger finding.

Three defects in the outgoing system account for most of what we find. Shift timings configured wrong, so hours were being measured against a window nobody actually worked. Work duration computed or reported incorrectly, which is the same error one layer further on. And employees marked absent on days they were present.

The third one is different in kind. It is an underpayment, and it is invisible from the employer's side. The record says the person was not there, so there is nothing to investigate, no exception raised and no report showing anything unusual. If the employee queried it, they were told what the system said. It surfaces during a parallel run because the new system marks them present on a day the old one did not, and that single-day disagreement is the thread you pull.

This is the argument for a parallel run stated properly. It is not a check that your new system works, since you will find that out anyway. It is the only occasion on which anyone systematically re-computes what the old system was reporting, and therefore the only occasion on which a long-standing error has any way of surfacing. An error nobody re-checks does not correct itself; it just accrues.

The reconciliation between attendance and payroll after cutover is the moment the whole exercise pays off or does not. The handover of a person record between systems is the same problem the rest of the employee lifecycle has. If attendance and payroll read from the same record, the reconciliation is not a task. If they do not, you have moved the problem to a new host.

Questions People Ask

What is cloud-based attendance software?

Cloud-based attendance software records and processes employee attendance on a hosted platform rather than on a server inside your own network. Punches arrive from fixed devices, mobile apps or web check-ins and are written to one central record, so multiple sites and remote staff share a single source of truth, and upgrades happen continuously instead of as periodic projects. The more significant change for a distributed workforce is not the hosting but the capture: attendance can be recorded from a phone, which means coverage extends to people who never arrive at a company location.

How does attendance tracking work for remote employees?

Remote employees record start, end and break times themselves through a web or mobile app, with an approval path for exceptions. The choice that matters is how much verification to attach. For staff whose pay varies with hours, self-recording with manager approval is usually proportionate. For field staff visiting sites, mobile face capture with liveness detection plus a location check at the punch gives both an identity and a place. For salaried knowledge workers whose pay does not vary with hours, wage-grade capture is generally the wrong tool, and the underlying question is usually occupancy planning, which is better measured directly.

Does cloud attendance software work without internet?

Good implementations do. The app or device must capture the punch locally, confirm it to the employee immediately, timestamp it at the moment of capture rather than at sync, and upload it when connectivity returns without creating duplicates. This is the difference between offline-first and offline-tolerant architecture, and it matters in Indian conditions where basements, industrial areas and rural sites routinely lose coverage. Test it before buying: put the phone in airplane mode, punch, reconnect, and check that exactly one record arrived with the original timestamp.

Is GPS tracking of employees legal in India?

Location data is personal data under the Digital Personal Data Protection Act, 2023, so it requires notice of what is collected and why, use confined to that purpose, security safeguards and erasure once the purpose ends. Capturing a location at the moment of a check-in to verify presence for attendance is comfortably supportable where employees have been told about it. Continuous background tracking throughout the day is a materially larger collection serving a different purpose, and it needs its own justification and its own notice rather than riding on the attendance one. Recording a geofence result rather than a precise coordinate achieves the same attendance outcome with less data and is generally the better configuration.

How do you prevent attendance fraud in a distributed team?

The two realistic risks are someone else marking your attendance, and marking attendance from somewhere you are not. The first is addressed by face capture with liveness detection rather than a PIN or an app tap, since a shared login is easier to pass around than a card ever was. The second is addressed by capturing location or a geofence result at the punch. Beyond those, the highest-value control is not technical: limit who can regularise attendance and up to what threshold, and require every correction to record who changed what, when and on whose approval. Unlimited silent regularisation defeats any capture method you deploy.

What are the compliance requirements for attendance of remote workers in India?

The same obligations apply as for on-site staff. You need a muster roll showing daily attendance with in and out times for every person on every day of the wage period, overtime computed at twice the ordinary rate beyond eight hours in a day or forty-eight in a week with both tests applied independently, and registers preserved for five years from the date of the last entry under the Code on Wages (Central) Rules, 2026. The provision that catches distributed employers is spread-over: elapsed time from the start of work to the end of it is capped at twelve hours, and scattered early-morning and late-evening activity can breach it while total hours look unremarkable.

Should attendance be tracked for salaried hybrid employees?

Usually not with a wage-computation system. If pay does not vary with the hours recorded, the attendance record is not computing anything, and deploying punch-grade capture costs trust, creates data you must then protect and retain, and can generate evidence of a spread-over breach you would not otherwise have. Ask what decision the data will change. If the answer is office capacity planning, measure occupancy directly through desk booking or a self-marked in-office day. If the answer is leave and absence, that is a leave management question rather than an attendance one.

How do you migrate from an on-premise attendance system to the cloud?

Archive the historical statutory registers rather than migrating raw punch data, since recomputing old punches under new shift rules produces numbers matching neither the old registers nor reality. Cut over at the start of a wage period rather than mid-month. Re-enrol biometrics instead of importing templates, which are rarely portable between vendors and tend to produce marginal enrolments that fail intermittently. Rebuild the shift and holiday masters rather than importing years of accumulated exceptions. Then run parallel for one full wage period and investigate every disagreement between the two systems, because each one is a defect in either the new configuration or the old. The defects we most often find in the outgoing system are shift timings configured wrong, work duration computed or reported incorrectly, and employees marked absent on days they were present. The last of those is an underpayment that is invisible from the employer's side, since the record shows nothing to investigate.

Cloud or on-premise attendance software: which is better?

Cloud suits most employers now, and particularly anyone with more than one site or any field or remote staff, because every location writes to one consolidated record and upgrades happen continuously rather than as deferred projects. On-premise remains defensible for a single large site with a capable IT function and no distributed workforce, or where a contractual requirement demands the data stay inside your own infrastructure. The characteristic failure of multi-site on-premise deployments is drift: each site's server ends up on a different version with different shift and holiday masters, and consolidated reporting becomes a manual merge nobody trusts.

Where This Leaves You

Sort your workforce into the four types before you configure anything, because they need different things and the most expensive error in this category is applying one policy to all of them. Capture identity and location at the punch for the people whose wages or compliance depend on it. Leave the salaried hybrid population out of wage-grade capture and measure the thing you actually want to know. Then spend your evaluation effort on offline behaviour, shift handling across midnight, and who can regularise what, because those are the three that decide whether the record is trusted a year from now.

The order that works: decide what each population's attendance record is actually for, and write the answer down, because if you cannot name the decision it supports you should not be collecting it. Configure the rules that vary by site and state as configuration rather than as a document. Test offline capture with the network off before you sign anything. Run a midnight-crossing shift on the last day of a month through to a payroll figure. Set regularisation limits and an approval path before go-live rather than after the first month-end. And say plainly what the app collects, because the rollouts that fail are the ones that did not.

Most of this is a policy question rather than a technical one. The software will faithfully implement whatever boundary you set, including the boundary you never actually decided on, and the organisations that struggle here are almost never the ones that picked the wrong product.

The hardware and modality decisions, if fixed devices are part of your mix, are in our biometric attendance system buyer's guide. The statutory position that determines what your records must contain is in attendance compliance in India under the Labour Codes, and the wider obligations are in our labour law compliance checklist.

If you would rather one record covered your offices, your sites and your field team, with different rules applied per location and a payroll figure at the end of it that nobody has to reconcile, that is what our attendance management software is built to do. Book a free demo and bring your most awkward population rather than your simplest: the field team, or the site with the odd roster. That is the conversation worth having.