GPS attendance for field employees is the one part of workforce management where the technology is genuinely good and the implementations are routinely bad. The capability works: a phone can establish, well enough for most purposes, that a person was at a place at a time. What goes wrong is everything around that, and it goes wrong in a small number of predictable ways.
The geofence is drawn too tight, so people who are standing in the right place cannot mark attendance, and the system loses its authority within a fortnight. Or the geofence is drawn too loose, so it certifies nothing and everyone knows it. Or live tracking is switched on because it was available, without anybody deciding what question it is answering. Or the whole thing is deployed to establish trust and immediately becomes the proof that trust is absent.
This piece is about what actually works for field teams: sales staff who never see an office, service engineers moving between sites, delivery and logistics crews, merchandisers, site supervisors, and anybody whose day happens away from a fixed device. It covers what the technology can and cannot establish, the numbers that decide whether an implementation succeeds, and where the line sits between attendance capture and surveillance.
The intended reader is whoever is deploying this: an HR head rolling out attendance for a field force, a sales operations manager who owns the app people actually use, or a founder who has just discovered that nobody can say with confidence who worked yesterday.
Nothing here is legal advice. Location data about identifiable people is personal data, and its handling is governed by the Digital Personal Data Protection Act, 2023 as well as by the constitutional position on privacy set out in the Puttaswamy judgment. The attendance obligations themselves sit under the Labour Codes, in force since 21 November 2025, and under the state Act your establishment is registered under. Have the deployment reviewed against all three rather than against a vendor's datasheet.
What GPS Attendance Actually Is, and What Geofencing Adds
Strip away the product language and there are two separate things here. GPS attendance records what the phone says about itself at the moment the employee marks attendance: a coordinate, a timestamp and an accuracy figure. Geofencing adds a rule on top of that record, accepting or rejecting the mark according to whether the coordinate falls inside a defined radius around a location. The first is a measurement with a known margin of error. The second is a decision taken from it, and most of what goes wrong in these deployments comes from treating the decision as more certain than the measurement it rests on.
GPS attendance means the employee marks attendance on a phone and the device's location is recorded at that moment. What you get is a coordinate, a timestamp and an accuracy figure. That is it. The coordinate is not proof of anything on its own; it is a claim the device is making about itself, and section 4 is about how much weight it will bear.
Geofencing adds a rule. You define an area, and the system either permits or refuses the attendance action depending on whether the reported position falls inside it. That is the whole mechanism. Everything a vendor calls geofencing is some version of a point, a radius and a comparison.
The distinction matters because they fail differently. GPS attendance fails softly: you get a location that is imprecise, and you decide afterwards what to do about it. Geofencing fails hard: a person standing in the right place is refused, and cannot mark attendance at all. That difference is the reason most field attendance implementations that fail, fail on the geofence and not on the GPS.
A third thing usually sits alongside these and is worth naming separately, because it is frequently bought under the same heading. Live location tracking, meaning the device reports its position at intervals through the day rather than only at the moment of an attendance action, is not attendance capture. It answers a different question: where a team is now, what route they took, whether a visit happened where it was supposed to. That is a real requirement for a lot of field operations, and it is what conveyance reimbursement on actual distance and deviation alerts are built on. It is simply not the same question as whether somebody worked today, and the two are worth configuring separately even when you buy them together.
We build both. Field tracking covers live location, route maps and visit verification, and attendance capture is a separate action with its own record. Live tracking is off by default and is enabled team by team instead of across the whole company, which is the configuration we would recommend to anybody regardless of whose software they buy: switch it on where somebody can say what they will do with it, and leave it off elsewhere.
The Accuracy Problem Nobody Puts in the Brochure
Every product page says GPS attendance is accurate. None of them say to what, and the answer is the single most useful thing to understand before you configure anything.
A phone does not have one location technology, it has several, and it blends them. Satellite positioning is the most precise outdoors with a clear view of the sky. Wi-fi positioning, which infers location from nearby network identifiers, works indoors and in dense urban areas where satellites are obstructed. Mobile network positioning, which infers location from cell towers, is the fallback and is the least precise by a wide margin. What the phone reports is a fused estimate, together with an accuracy radius that says, in effect, "the true position is probably within this many metres".
| Positioning method | When the phone relies on it | How precise it is |
|---|---|---|
| Satellite | Outdoors with a clear view of the sky | The most precise of the three |
| Wi-fi, inferred from nearby network identifiers | Indoors and in dense urban areas where satellites are obstructed | Between the other two |
| Mobile network, inferred from cell towers | The fallback when neither of the above is available | The least precise by a wide margin |
Three consequences follow, and they are all operational, not technical.
Accuracy is not constant. Outdoors in the open, a modern phone is usually good to within a handful of metres. Inside a building, in a basement, in a covered market, between tall buildings, or in a vehicle with a metallised windscreen, that degrades substantially, and it degrades exactly where a lot of field work happens. A geofence configured for the good case will reject people in the bad case.
The first fix takes time. A device that has been indoors or switched off needs time to acquire a position, and the first reading after opening an app is frequently the worst one of the day. An employee who opens the app and marks attendance in three seconds gets a worse location than one who waits fifteen. Nobody waits fifteen seconds.
The accuracy figure is available and is usually ignored. Every platform can read the reported accuracy radius alongside the coordinate. A system that records it, shows it, and uses it in the geofence decision is doing something meaningfully better than one that stores a bare coordinate. Ask whether the accuracy figure is captured, whether it is visible on the attendance record, and whether it affects the decision. Most systems do not, and it is the cheapest available improvement.
Geofence Radius: The Number That Decides Everything
A geofence is a point and a radius. The radius has to be larger than the location error you expect at that place, or the system will reject people who are genuinely there. That sounds obvious and is violated constantly, because the radius is usually set by somebody looking at a map on a laptop, where fifty metres looks enormous, and not by somebody standing in the location holding a phone.
The rule of thumb that survives contact with reality is that the radius should be at least the worst reasonable accuracy at that location, plus the size of the place itself. A geofence around a customer's factory has to contain the factory, not just the gate coordinate. A geofence around a retail outlet in a mall has to allow for the fact that the phone cannot see a satellite anywhere inside the mall.
The failure mode is worth spelling out, because it is not gradual. When a geofence is too tight, the employee who is standing exactly where they should be gets refused. They try again. They walk outside. They call their manager. The manager tells them to mark it manually, or approves an exception, and within two weeks a norm has been established that attendance exceptions are routine. After that the geofence is not enforcing anything, it is generating work. The system did not fail loudly; it was quietly abandoned, and the reports it produces still look fine.
Two configuration choices avoid most of this. Allow the attendance to be recorded outside the fence rather than refusing it, and flag it, with the distance and the reported accuracy attached, for a manager to see. A refusal produces a phone call; a flag produces a record. And set radii per location instead of one global number, because a rural site with an open sky and an urban mall unit genuinely need different values, and a single number will be wrong for one of them by design.
| Situation | What the phone reports | Sensible geofence approach |
|---|---|---|
| Open outdoor site, clear sky | Good precision, small accuracy radius | A radius that covers the site itself, plus a modest margin |
| Urban street between tall buildings | Degraded precision from reflected signals | A larger radius, and record the accuracy figure with the punch |
| Inside a building, mall unit or basement | Wi-fi or cell positioning, substantially worse | A large radius, or capture at the entrance rather than at the counter |
| Vehicle or on the move | Variable, often good outdoors and poor in tunnels or covered areas | Do not fence at all; record location with the punch and review |
| Employee's own home, hybrid arrangement | Adequate, but the question is whether you should be fencing at all | Do not fence a home. Record the working day, not the place |
The last row is a policy statement, not a technical one, and it is deliberate.
Spoofing, and What Actually Stops It
Any honest treatment of GPS attendance has to deal with this, because it is the first thing a sceptical manager asks and the last thing a datasheet mentions.
A phone's reported location can be faked. Mock location facilities exist on mobile platforms for legitimate development purposes, and applications that use them to report a false position are widely available. Rooted or jailbroken devices extend what is possible further. An employee who wants to mark attendance from somewhere they are not can usually find a way to do it, and treating GPS alone as proof is a mistake.
What follows from that is not that the technology is useless. It is that you should be clear about what you are buying. Location capture raises the effort required to falsify attendance from zero to something non-trivial, and it produces a record. For the large majority of a field workforce, that is sufficient, because most people were not falsifying attendance anyway and the ones considering it are deterred by the record existing.
Four things genuinely raise the bar, in rough order of value.
Mock location detection. The operating system exposes whether a reported position came from a mock provider. A system that checks this and flags the attendance is doing the single most effective thing available. Ask specifically whether it is checked, and what happens when it fires: whether the punch is blocked or flagged.
A selfie with the punch. A photograph taken at the moment of marking attendance, tied to that record, is harder to fake than a coordinate and much harder to fake repeatedly. Face matching against an enrolled image raises it further, and it is the same biometric enrolment you would use at a fixed device, which matters if some of your people pass both. This is why selfie-with-geotag has become the default pattern for Indian field attendance rather than location alone.
Device binding. Tying an employee's attendance to a registered device makes marking on somebody else's phone visible, which addresses buddy punching, a much more common problem than technical spoofing.
Pattern review rather than punch review. Falsification shows up in patterns, not in individual records: the same coordinate to five decimal places every day, punches that arrive at a location without any plausible travel between them, accuracy figures that never vary. A system that surfaces those is more useful than one that tries to adjudicate each punch.
What does not work is treating a single flagged punch as proof of misconduct. The false positive rate is high enough that a company which starts disciplinary action on one flag will be wrong often enough to lose the room. Use flags to look, not to conclude.
Decide the process for a flag before you switch detection on, because deciding it after the first one arrives means deciding it about a particular person. A workable sequence is that a flag does not block the punch, does not notify anybody automatically, and appears on a monthly review alongside the employee's other records. Somebody looks at the pattern. If it is isolated, it is noise, and a rooted phone or an unusual handset will produce noise indefinitely. If it recurs, the conversation is with the employee before it is with anybody else, and the opening question is what device they are using, not an accusation. Companies that skip this end up in one of two failure states: they act on the first flag and get it wrong publicly, or they collect flags for a year, act on none of them, and have created a record that says they knew and did nothing.
Worth separating from all of this: buddy punching is a much more common problem than technical spoofing and has a much simpler answer. A colleague marking attendance for somebody who is not there requires no technical sophistication at all, and device binding plus a selfie deals with almost all of it. If you are choosing where to spend configuration effort, spend it there first.
Offline, Battery and the Realities of a Field Day
Three practical constraints decide whether a field attendance deployment survives its first month. The network fails at the places field work actually happens, which means attendance has to be capturable offline, with the location and timestamp taken at the moment of the action rather than at the moment of sync. Battery is what field staff will complain about within a week of rollout, and the answer depends on the handsets your people actually carry, which no data sheet will predict. And the handset itself has to be decided before rollout: whose phone it is, how old it is, who pays for the data, and what happens to the employee who has no smartphone at all.
Connectivity fails, and it fails at the worst places. Basements, lifts, rural routes, industrial sites, and the interiors of large buildings. If the app requires a network to record attendance, the employee at a site with no signal cannot mark it and will report it later from somewhere else, which destroys the location record you deployed the system for. The app has to capture attendance offline, with the location and timestamp taken at the moment of the action rather than at the moment of sync, and then upload when a network appears.
The sync has to be honest about what it is. A record created offline at 09:12 and uploaded at 14:30 should show both times and should not silently present the upload time as the attendance time. Ask to see an offline punch in the record. If the interface shows one timestamp, ask which one it is, and consider what that means for a shift boundary or an overtime calculation.
Battery is the constraint that quietly determines adoption, and it is the complaint field staff will raise within a week of rollout. An employee whose phone dies at four in the afternoon has a real problem that has nothing to do with attendance, and an app blamed for it gets closed. This is not worth arguing about in the abstract, because the answer depends on the handsets your people actually carry, and no vendor can tell you what those will do. Measure it in the pilot in section 8, on the oldest phones in the team, and you will know instead of guessing.
Then there is the device question, which is unglamorous and decides more than anything above. Whose phone is it, what happens on an old handset with an outdated operating system, what happens when somebody has no smartphone at all, and who pays for the data. A rollout plan without an answer for the employee with a five-year-old phone will produce an exception process that becomes permanent. Decide it before rollout, not after.
The Privacy Position, and Why It Is Also an Adoption Problem
Location data about an identifiable employee is personal data, and it is among the more sensitive categories in practical terms because it reveals patterns rather than facts.
The Digital Personal Data Protection Act, 2023 sets the framework in India, with the Rules notified in November 2025 on a phased timeline. Processing personal data for employment purposes falls within the legitimate uses the Act recognises, which means an employer is not always dependent on consent as the basis for processing. That is a narrower permission than it sounds, and it is frequently over-read. It does not remove the obligations that matter here: that the purpose be specified, that the data collected be what the purpose requires rather than what the sensor can produce, that it be retained no longer than needed, and that the employee be told what is happening. The practical consequence is that each kind of collection has to be justified by the purpose it serves, and not by the fact that one app happens to do both. Attendance is established by the check-in. Route and visit data serve a separate purpose and should be turned on where that purpose exists, which is also why enabling live tracking per team rather than across the company is the sensible default.
Underneath that sits the constitutional position from the Puttaswamy judgment, which established privacy as a fundamental right and set out the proportionality test that measures for intrusion are assessed against. The practical translation for an employer is a question worth asking in plain terms before deployment: is what we are collecting the least that would achieve what we actually need. If the answer is no, you have both a legal exposure and, more immediately, an adoption problem.
Three things to do, none of them expensive.
Write the purpose down in the attendance policy, in the document, not in a training slide. Say what is captured, when it is captured, when it is not captured, what it is used for and how long it is kept. A clause of five lines does more for adoption than any amount of explanation after rollout. Our piece on writing an attendance policy has a field schedule drafted for exactly this.
Bound the collection in the system, not in the policy. Whatever the document promises about what is and is not recorded, the configuration has to match it, because if the software can quietly break the promise, you will eventually be shown to have broken it. In practice that means deciding which teams have live tracking enabled and which do not, instead of enabling it everywhere and relying on nobody looking. Ask your vendor what the switch is, what it covers, and who can change it.
Show employees their own data. Employee self-service that lets a field employee see exactly what was recorded about them removes most of the suspicion that otherwise attaches to these systems, because the fear is almost always about what is being collected invisibly. It also surfaces errors in week one rather than in a grievance.
None of this is about being nice. A field attendance system that the field team resents produces bad data, because there are a dozen ways for a person who does not want to be tracked to make the record useless, and they will find one.
What This Has to Produce for Payroll
A field attendance system that does not feed payroll cleanly has just moved the problem somewhere else. Four things have to come out of it.
A day with a defined start and end. Whatever happens in between, payroll needs to know the employee worked that day and between which times. That means a close action, not just an open one, and it means a rule for the day somebody forgets to close. Decide the rule in advance: auto-close at a stated time, or leave it open and flag it. Either is defensible; not deciding is not.
Hours that support an overtime calculation where one is due. Field roles are frequently assumed to be outside overtime, and that assumption is frequently wrong. If overtime is payable, the base and the divisor matter more than the capture method, which is the part of payroll calculation that field deployments most often skip, and our overtime piece sets out the arithmetic.
Regularisation with a window and an approver. Missed and failed punches are more common in field work than anywhere else, so attendance regularisation is not an edge case here, it is a monthly volume. It needs a named approver, an enforced deadline before the payroll cut-off, and a record of who approved what.
A record that stands up as a register. The muster roll obligation does not disappear because the workforce is mobile. Whatever the app collects has to become a register in the prescribed form. Our piece on attendance compliance under the Labour Codes sets out what has to be kept.
There is a fifth output that is not attendance but travels with it, and it is usually the one field employees care about most: conveyance. Where reimbursement is paid on distance travelled rather than as a flat monthly allowance, the route data is the basis for the claim, and the reason to care about it here is that it changes the incentive around the whole deployment. A system that only takes data from field staff is resented. A system that also settles their travel claim without them assembling it from memory at month end is not, and the difference in adoption is larger than anything you will achieve by explaining the system better. If you are running route capture anyway, connect it to the claim. What that means for the payroll treatment, since a distance-based reimbursement and a fixed conveyance allowance are handled differently, is in our piece on reimbursements and flexible benefits.
The reason to have attendance and payroll on one record rather than joined by an integration is entirely this: field attendance generates more corrections than any other kind, and every correction has to reach payroll before the cut-off. Two systems joined by an interface means somebody reconciling them under time pressure every month.
What to Ask on a Demo, and How to Pilot
Six things to ask, and every one of them is something to see, not something to be told. They cover the accuracy figure on a record, what happens to a mark thirty metres outside the fence, an offline punch with both timestamps, the mock location flag, exactly what is captured between check-in and check-out, and the register the system generates. Then pilot for four weeks with the team that has the hardest locations, enforcing nothing, before you set a single radius.
Show me the accuracy figure on an attendance record. If it is not captured, the system is storing a coordinate without knowing how much to trust it.
Show me what happens when somebody marks attendance thirty metres outside a geofence. Blocked, or recorded and flagged with the distance. Ask which, and ask whether you can choose.
Show me an offline punch, with both timestamps. The time of the action and the time of the sync, distinctly.
Show me a mock location flag. Ask whether it is detected at all, and what happens when it fires.
Show me exactly what is captured between check-in and check-out, and who controls it. Ask directly whether any position is recorded between events, whether that is on or off by default, and who can change it.
Show me the register the system produces, generated rather than exported and formatted by hand.
Then pilot properly, because a demo cannot tell you about the places your people actually work. Take one team, twenty to thirty people, for four weeks. Choose the team with the hardest locations, not the easiest one: the ones who work in basements, in malls, in industrial estates and in areas with poor coverage. A pilot at easy locations proves nothing you needed to know.
For those four weeks, do not enforce anything. Record everything, block nothing, and look at what comes back: how often the accuracy figure is poor and where, how often punches land outside the fence and by how far, how many arrive from offline sync, and which locations generate the exceptions. Then set the radii from that data, per location, and only then switch on enforcement. Configuring the geofence before the pilot is the mistake that section 3 describes, made in advance.
Tell the pilot team what the data is for and what it is not for, at the start. The pilot is also a rehearsal of the conversation you will have with the whole field force, and it is cheaper to get that wrong with thirty people than with three hundred. Our comparison of attendance platforms covers who is scoped for field capture, and for teams that also pass fixed devices, the biometric buyer's guide covers the hardware side.
Questions People Ask
How accurate is GPS attendance on a mobile phone?
It depends on where the phone is, and any single number quoted without that qualification should be treated as marketing. Outdoors with a clear view of the sky, a modern phone is usually good to within a handful of metres. Indoors, in a basement, inside a mall, between tall buildings or in a vehicle, positioning falls back to wi-fi or cell tower inference and degrades substantially, which is unfortunate because that is where a great deal of field work happens. The useful thing is not the headline accuracy but the accuracy radius the phone reports with every reading, which tells you how much to trust that particular punch. Ask whether your system records it, shows it on the attendance record and uses it in the geofence decision. Most do not, and it is the cheapest improvement available.
What radius should a geofence be?
Larger than you think, set per location instead of globally, and derived from a pilot rather than from a map. The radius has to exceed the worst reasonable location error at that place and also contain the place itself, so a fence around a customer's plant has to cover the whole site, gate to far wall. A fence that is too tight fails hard: the employee who is standing in exactly the right place is refused, calls their manager, gets a manual exception, and within a fortnight exceptions are routine and the geofence is enforcing nothing. Recording an out-of-fence punch and flagging it with the distance, rather than blocking it, avoids almost all of that while keeping the information you wanted.
Can employees fake GPS attendance?
Yes. Mock location facilities exist on mobile platforms for legitimate development purposes, and applications that abuse them are easy to find, so treating a coordinate as proof is a mistake. What location capture actually buys you is that falsification stops being free and starts leaving a record, which is enough to deter almost everybody who was not going to falsify anyway. The things that genuinely raise the bar are mock location detection, a selfie taken at the moment of the punch and ideally matched against an enrolled image, binding attendance to a registered device so marking on a colleague's phone is visible, and reviewing patterns instead of individual punches. What does not work is treating one flagged punch as proof of misconduct, because the false positive rate is high enough to lose you the argument and the room.
Is GPS tracking of employees legal in India?
Capturing location in connection with employment is not prohibited, but it is not unconstrained either. Location about an identifiable person is personal data under the Digital Personal Data Protection Act, 2023, and while processing for employment purposes falls within the legitimate uses the Act recognises, that does not remove the obligations that matter in practice: specify the purpose, collect only what the purpose requires, retain it no longer than needed and tell employees what is happening. Underneath that sits the proportionality test from the Puttaswamy judgment. The practical question to ask before deployment is whether what you are collecting is the least that would achieve what you actually need, and a continuous location trail collected to establish attendance is hard to defend on that test when a check-in at the visit establishes the same thing. Have your own deployment reviewed rather than relying on a vendor's assurance.
Does geofencing work indoors?
Poorly, and this is the constraint that catches most deployments. Satellite positioning needs a view of the sky, so inside a building the phone falls back to wi-fi and cell tower inference, which is substantially less precise. A geofence sized for outdoor accuracy will reject people who are correctly inside a mall unit, a basement office or a large factory shed. Two workable responses: size the fence generously for those locations specifically, which is the argument for per-location radii, or capture attendance at the entrance instead of at the workspace and accept that as the record. Either is better than the common third option, which is discovering the problem after rollout and approving exceptions until nobody believes the system.
What happens when there is no network?
The app must capture attendance offline, with the location and timestamp taken at the moment of the action, and sync when connectivity returns. Anything else pushes the employee into marking attendance later from wherever they happen to have signal, which destroys the location record the system was bought for. The part to check on a demo is how the synced record presents itself: a punch created offline at 09:12 and uploaded at 14:30 should show both times distinctly, and a system that displays only one should be asked which one it is. That distinction matters at a shift boundary and matters more if overtime is payable.
Do we need a separate policy for field attendance?
Not a separate policy, but a separate schedule inside the attendance policy. Field work differs enough from office work that a single rule applied to both produces informal exceptions, which is the most reliable way to make a policy unenforceable against anyone. The field schedule should state how attendance is marked, what location is captured and at which moments, whether any position is recorded between check-in and check-out, what the data is used for and how long it is kept. Five lines in the document does more for adoption than any amount of explanation after rollout, and it is also the record you would want if the deployment were ever questioned.
How long should we pilot before rolling out?
Four weeks with one team of twenty to thirty, and pick the team whose locations are worst, even if they are the least cooperative. Run it in observation mode: record everything, block nothing, enforce nothing. What you are collecting is the data that lets you set the geofence radii per location, which is the single decision that determines whether the rollout succeeds, and you cannot get it from a map or a demo. At the end you will know where accuracy is poor, how far outside the fence legitimate punches land, how many arrive from offline sync and which locations need special treatment. Only then switch on enforcement. Setting the radii before the pilot just bakes the section 3 error in from the start.
Where This Leaves You
Do these in order.
Separate the two questions before you look at any product. Attendance asks whether somebody worked today. Live tracking asks where the team is and what route they took. Both can be legitimate, they are bought together, and the mistake is letting one configuration decision cover both. If somebody wants a live view, ask what they would do differently with it, and ask that before the rollout rather than after.
Then write the field schedule of your attendance policy. What is captured, at which moments, what is recorded in between, what it is for and how long it is kept. Do it before deployment, not after the first complaint.
Then pilot for four weeks with the hardest locations, in observation mode, with nothing enforced.
Then set your geofence radii per location from what the pilot actually produced, and choose flagging over blocking wherever you can live with it.
Then check the payroll join. A field attendance system that generates corrections faster than they can reach the payroll cut-off is a monthly problem, not a solved one.
If you want to run that against us, field tracking covers live location, route maps and visit verification, with live tracking off by default and enabled team by team instead of across the company, attendance is a separate action on the same record as payroll so field corrections do not need a monthly reconciliation, leave is in the same place, and the pricing is published rather than quoted. Bring your worst location. That is the demo worth having.
Related reading: attendance policy for employees in India, attendance for distributed teams, attendance compliance under the Labour Codes, and the best attendance management software in India.
Sources
- Digital Personal Data Protection Act, 2023, enacted text on India Code. The framework for processing personal data in India, including the legitimate uses on which an employer may rely for employment purposes, and the obligations of purpose specification, data minimisation, retention limitation and notice.
- Justice K. S. Puttaswamy (Retd.) v. Union of India, Supreme Court of India, 2017. Privacy as a fundamental right, and the proportionality test applied to measures that intrude on it.
- Occupational Safety, Health and Working Conditions Code, 2020, enacted text on India Code. Record keeping obligations, including registers of attendance and overtime, for covered establishments.
- Code on Wages, 2019, enacted text on India Code. Section 14 on overtime at not less than twice the ordinary rate of wages, and the definition of wages in section 2(y) on which the ordinary rate is computed.
- Ministry of Labour and Employment, labour.gov.in. Commencement of the four Labour Codes on 21 November 2025.
Nothing above is legal advice, and nothing above describes any particular vendor's product except where it describes ours. The six demonstrations in section 9 are written to be asked of every vendor equally, including us.
