Gig Worker Compliance: The Aggregator's India Playbook

If your business runs on a fleet of delivery riders, drivers, beauticians, nurses, tutors or freelance creators, then gig worker compliance has quietly become one of the largest unbudgeted line items on your risk register. India's labour codes explicitly recognise "gig workers" and "platform workers" as categories that sit outside the traditional employer-employee relationship but still deserve social security. That single design decision changes how aggregators must register themselves, how they must onboard workers into a national database, how they budget for a welfare fund, and how they document every payout.

This guide is written for the people who actually have to make it work: HR managers, founders, operations leads, finance controllers and payroll teams. It is deliberately practical. It walks through classification, the registration mechanics, welfare fund accounting, the data engineering behind worker onboarding, contract design, grievance systems, audit readiness, and a 30/60/90 day roadmap you can hand to an ops team on Monday morning.

One important caveat up front, and it will be repeated: rules, notified rates, thresholds and deadlines in this space are still evolving at both the central and state level. Treat everything here as a framework for thinking, not as legal advice. Verify current requirements with official government sources, the relevant state labour department, and your own legal and tax advisors before you act.

Why gig worker compliance is suddenly an operations problem, not a legal footnote

For most of the last decade, Indian platforms treated their supply side as a commercial network of independent partners. Contracts were short, obligations were thin, and the main compliance conversation was about GST and TDS, not social security.

That has changed on three fronts at once. First, the Code on Social Security, 2020 created a statutory vocabulary for gig and platform workers and contemplated aggregator-funded welfare. Second, individual states — Rajasthan enacted a dedicated platform-based gig workers law in 2023, and Karnataka has moved on its own framework, with other states circulating drafts — have begun building their own registration and welfare-fee machinery. Third, worker-side awareness has risen sharply, which means grievances, deactivation disputes and misclassification claims are more likely to be raised and escalated.

The practical consequence is that gig worker compliance is no longer a document you sign once. It is a recurring operational process: register, onboard, verify, sync, contribute, reconcile, report, and repeat. That is much closer to running payroll than to filing an annual return.

There is also a commercial angle. Investors and acquirers running diligence on Indian platforms now routinely ask for the aggregator registration status, the proportion of active workers with a valid national registration number, and the accrual policy for welfare contributions. A messy answer becomes a valuation discount or an indemnity.

Who counts as a gig worker, a platform worker, an employee or a contractor

Classification is where almost every compliance failure begins. Get this wrong and everything downstream — contracts, tax treatment, benefits, terminations — is built on sand.

Gig worker

Broadly, a gig worker is someone who earns from a work arrangement that falls outside the conventional employer-employee relationship. The defining feature is the absence of a traditional employment contract, not the nature of the task. A person doing occasional catering work through informal referrals can be a gig worker even though no app is involved.

Platform worker

A platform worker is a narrower species of gig worker: someone who accesses organisations or individuals through an online platform to provide services in exchange for payment. The digital intermediary is the distinguishing element. Every platform worker is a gig worker; not every gig worker is a platform worker.

This matters because obligations attach to the aggregator — the digital intermediary that connects buyer and seller of a service. If your app matches a customer to a service provider and takes a commission, you are almost certainly in scope, regardless of whether you call the workers "partners", "associates", "fleet members" or "creators".

Employee

An employee works under a contract of service. The organisation controls not just what gets done but how, when and where. Employees attract the full stack of obligations: statutory minimum wages, provident fund and ESI where applicable, gratuity on qualifying tenure, paid leave, maternity benefit, bonus, notice and standard order discipline.

Fixed-term employee

A fixed-term employee is a genuine employee hired for a defined period. The contract ends on a stated date without it being a retrenchment, but during the term the person receives statutory benefits broadly on par with a permanent employee doing similar work — including pro-rated treatment of benefits that would otherwise depend on longer tenure. Fixed-term employment is often the honest answer when a business is tempted to call someone a "consultant" for a year-long, full-time, supervised role.

Independent contractor or consultant

An independent contractor works under a contract for service. They deliver a defined outcome, control their own method, typically serve multiple clients, invoice for their work, bear their own costs and carry commercial risk. A genuine consultant can decline work, subcontract, and set their own schedule.

Why misclassification is the core risk

Misclassification is not one risk; it is a bundle of them that all trigger together. A single adverse determination can produce retrospective provident fund and ESI liability with interest and damages, gratuity exposure, minimum wage and overtime claims, TDS re-characterisation from contractor sections to salary withholding, GST input credit disallowance, and reputational damage that reaches customers and investors.

The classification test in practice is substance over labels. No Indian authority is impressed by a contract that says "nothing in this agreement creates an employment relationship" if the day-to-day reality is a rostered shift, a supervisor, a uniform, a login requirement and a disciplinary process.

Think of it as a spectrum. A warehouse supervisor on a shift roster sits at the employee end; a freelance illustrator who takes two briefs a year from you and thirty from others sits at the other. Most platform arrangements fall in between, and your job is to push the arrangement honestly toward the end you claim it occupies — or reclassify.

Comparison table: employee vs fixed-term employee vs gig or platform worker vs consultant

The table below is a planning aid, not a legal test. Actual outcomes depend on facts, the specific statute in question and the state in which you operate.

Two practical readings of this table. If your "consultant" column entries keep drifting left into the employee column, reclassify before someone else does it for you. And if your gig column entries look identical to the employee column except for the payment mechanism, you have a misclassification problem dressed as a payout design.

What the social security code framework means for aggregators in practice

The most useful way to read the social security code gig workers framework is as three connected duties: register the business, register the people, and fund the benefits. Everything else is plumbing that supports those three.

Duty one: register the aggregator

Aggregators are expected to register themselves in the categories the framework recognises — ride-hailing, food and grocery delivery, logistics, e-marketplaces, professional and home services, healthcare, content and media services, and similar. A single company can fall into more than one category if it runs multiple business lines.

Practically, this means someone must own the registration: gather corporate documents (incorporation certificate, PAN, GST registrations, address proof, authorised signatory details), map each business line to a category, and maintain the registration certificate as a living record that gets updated when the business changes.

Where a group runs several entities — say a logistics arm and a quick-commerce arm under a holding company — decide early whether registration and reporting happens per entity or per brand. Mixing the two creates reconciliation chaos when turnover-linked contributions are computed.

Duty two: register the workers and maintain the national database

The national database for unorganised workers, accessed through eShram registration, is the backbone of the worker-side obligation. Every gig and platform worker engaged by the aggregator is expected to be registered with a unique identifier, using Aadhaar-based identification, so that benefits can be attached to a person rather than to a platform account.

Aggregators are generally expected to facilitate this — not to treat it as the worker's private homework. In practice this means building eShram registration prompts into onboarding, checking whether the worker already has a registration number, capturing and validating that number, and blocking a worker from going live until the field is populated or a documented exception applies.

The obligation does not end at onboarding. You are expected to keep records current, report when a worker stops being engaged, and periodically refresh details so the database does not fill with stale entries. Build these as scheduled jobs, not as ad-hoc clean-ups.

Duty three: contribute to the platform worker welfare fund

The framework contemplates aggregator contributions into a welfare fund that pays for schemes covering life and disability cover, accident insurance, health and maternity benefits, old age protection, and crèche support. The distinctive design choice is that the aggregator's contribution is computed with reference to turnover rather than to individual wages.

The Code contemplates a contribution expressed as a percentage of turnover, subject to a ceiling linked to the amounts the aggregator pays out to gig and platform workers. Discussion around the Code has referenced a low single-digit percentage band. Do not hard-code any number into your model until you have confirmed the notified rate, the base, the ceiling and the applicable period from official sources or your advisor, because the base definition matters as much as the rate.

Aggregator welfare fund contributions: budgeting, accrual and reconciliation

This section is where finance earns its keep. The turnover-linked model behaves very differently from a wage-linked model like provident fund, and that difference has real budgeting consequences.

How the percentage-of-turnover model works conceptually

In a wage-linked model, your liability scales with headcount and salary. In a turnover-linked model, your liability scales with the size of the business, with a ceiling that reconnects it to what you actually pay workers.

That produces two effects worth planning for. A high-growth platform sees the absolute contribution rise quickly even if worker count is flat, because turnover is the driver. And a platform with a high take rate and low payout share may hit the ceiling condition, which is precisely why the base definition — gross transaction value, net revenue, or something else — must be nailed down before you model anything.

Defining your base: the question that decides the number

Before rate, settle base. Write down, in one page, whether the base is gross order value including customer-paid delivery fees and taxes, or platform revenue net of amounts passed through to merchants and workers, or something in between. Then map that definition to actual ledger accounts.

Get finance, tax and legal in the same room for this, and record the rationale in a memo. If a later interpretation moves the base, you will want the paper trail showing the decision was reasoned rather than convenient.

A worked example (illustrative numbers only)

Consider a hypothetical Bengaluru-based home-services platform. All figures below are invented for illustration and are not benchmarks or rates.

Assume monthly gross transaction value of Rs 40 crore, of which Rs 28 crore is paid out to service professionals and Rs 12 crore is platform revenue. Assume, purely for modelling, a notified contribution of 1.5 percent computed on a defined base of Rs 40 crore, subject to a ceiling of 5 percent of amounts paid to workers.

The rate-based figure would be Rs 60 lakh for the month. The ceiling test would be 5 percent of Rs 28 crore, or Rs 1.4 crore. Since Rs 60 lakh is below the ceiling, the rate-based figure governs, and the monthly accrual is Rs 60 lakh.

Now flip the economics. If the same platform restructured so that only Rs 8 crore flowed to workers, the ceiling would fall to Rs 40 lakh, and the ceiling would become the binding constraint. That is why your model needs both computations every month, not just the headline rate.

Budgeting and accrual mechanics

Accrue monthly, even if remittance turns out to be quarterly or annual. A quarterly true-up on top of a monthly accrual is far less painful than discovering a four-quarter liability at year end.

Set up a dedicated general ledger account for the welfare contribution expense and a matching liability account. Do not bury it inside "statutory dues" alongside PF and ESI, because the computation base is entirely different and mixing them destroys your ability to reconcile.

Build the accrual as a formula driven from the same data warehouse table that produces your revenue reporting. If the accrual is computed from a separate spreadsheet that someone maintains manually, it will diverge from the books within two quarters.

Include the contribution in unit economics from day one. If your contribution margin per order does not carry this cost, your pricing and incentive design are optimistic by exactly the amount of the accrual.

Who signs off

Assign three named roles. A preparer in finance who runs the computation and assembles the working file. A reviewer — typically the financial controller — who checks the base, the rate, the ceiling test and the ledger posting. And an approver, usually the CFO or a director, who authorises the remittance and owns the external representation.

Add a fourth touchpoint: legal or the compliance lead confirms, at least quarterly, that the rate and base you are using still match the current notified position. Rates change; spreadsheets do not update themselves.

How to reconcile

Run a three-way reconciliation each month. Tie the turnover base in the contribution working to the revenue reported in the management accounts. Tie the worker payout figure to the sum of the payout ledger for the same period. And tie the remitted amount to the bank statement and the acknowledgement or challan.

Then run a fourth check across the year: cumulative accrual less cumulative remittance should equal the closing liability balance. Investigate any variance above a defined materiality threshold before closing the month, not at audit time.

Benefits that flow to registered workers, and how to explain them

The welfare framework is designed so that registered gig and platform workers become eligible for schemes covering health and maternity benefits, life and disability cover, accident insurance, old-age protection and crèche facilities. Eligibility for particular schemes is commonly conditioned on the worker having been engaged for a minimum number of days in a year across one or more platforms.

That last point deserves emphasis because it changes worker behaviour and your communication strategy. If eligibility depends on days of engagement aggregated across platforms, a worker who splits time between three apps needs an accurate record from each. Your data quality directly affects whether a real person gets a real benefit.

What good worker communication looks like

Explain benefits in the worker's language, in the app, at the moment it matters. A one-time onboarding PDF in English is not communication; it is documentation.

Use plain sentences. "If you complete work on at least the required number of days this year, you may be eligible for accident cover" is better than a paragraph quoting the statute. Then link to a detail page for those who want it.

Show the worker their own status. A simple in-app tile showing days of engagement recorded this year, registration status, and whether identity and bank details are verified, resolves most support tickets before they are raised.

Never over-promise. Say clearly that schemes are notified by government, that eligibility conditions apply, and that final determination rests with the scheme administrator. Overselling a benefit is a grievance generator and a reputational risk.

A note on voluntary top-ups

Many platforms run their own accident or health cover for active workers, above the statutory framework. This is genuinely valuable, but keep the two streams clearly separated in your communication and your accounting.

If workers cannot tell whether their cover comes from the government scheme or your commercial policy, they will blame you when a statutory claim is delayed and blame the government when your policy excludes something. Label each clearly.

The operational build: data, integration and verification

This is where compliance meets engineering. Aggregator compliance India conversations usually stall here because nobody owns the integration.

Required data fields

Start from the fields you need to register a worker, keep the record current and prove it later. The list below is a practical starting point; confirm the exact schema against the current portal or API specification.

Portal versus API integration

Most platforms start with bulk uploads through a portal and move to API integration once volume makes manual work untenable. Both are legitimate; the mistake is treating the portal phase as permanent and never building the reconciliation layer.

Whichever route you take, keep an internal system of record that you control. The portal is the destination, not your source of truth. Your own worker master must hold the authoritative record, including the registration number returned by the government system.

Design for idempotency. Every submission should carry a stable internal reference so that a retry after a timeout does not create a duplicate registration. This single design choice prevents the most common data-quality disaster in this area.

Identity and bank verification

Verify identity at onboarding using the permitted Aadhaar-based verification route available to your organisation, and store only what you are permitted to store. Where full Aadhaar numbers are not required for your purpose, prefer masked storage and a reference token.

Verify bank details with a penny-drop or equivalent name-match check before the first payout. A mismatch between the name on the bank account and the name on the identity document is both a payout failure and a fraud signal.

Re-verify on change. Any update to a bank account should trigger a fresh verification, a cooling-off window before large payouts, and an alert to the worker on their registered mobile.

Deduplication

Duplicates arise constantly: a rider who left in March and rejoined in September, a worker who signs up in two cities, a family sharing a mobile number, or an onboarding agent who creates a fresh profile because search failed.

Build a deduplication service that checks on at least three keys before creating a new worker record — the government registration number, a hashed identity reference, and the bank account plus mobile combination. Where a probable match is found, route to human review rather than auto-merging, and keep an audit trail of every merge.

Track a duplicate rate metric weekly. If it rises, something upstream changed — usually a new onboarding channel or a partner vendor.

Sync cadence: real time, daily or quarterly

Not everything needs the same cadence, and pretending it does will either blow up your costs or leave your data stale. A tiered model works better.

• Real time or near real time: new worker registration, bank account changes, and deactivations that stop payouts. These have immediate consequences.
• Daily batch: activity and days-of-engagement counters, status changes, contact detail updates, document expiry flags.
• Monthly: contribution computation inputs, worker register snapshot, exception report to the compliance lead.
• Quarterly: full refresh of worker details, dormancy review, and a reconciliation of your worker master against the government database.

The quarterly full refresh is the one most teams skip, and it is the one that catches silent drift.

Error handling and reconciliation dashboards

Every submission should land in one of four states: accepted, rejected with a code, pending, or timed out. Anything that stays pending beyond a defined window becomes an exception.

Build a single dashboard that shows, for the current period: total active workers, workers with a valid registration number, workers pending registration by age bucket, rejection reasons ranked by volume, bank verification failures, duplicate review queue depth, and exits reported versus exits recorded internally.

Assign an owner and a service level to each queue. "Registration rejections older than seven days" should have a name against it, not just a number.

Keep the rejection reason codes. When a regulator or auditor asks why 400 workers were unregistered in a quarter, "the portal rejected them for name mismatch and here is the remediation log" is a defensible answer. "We are not sure" is not.

A 30/60/90 day gig worker compliance roadmap

The roadmap below assumes a mid-sized aggregator starting from a low base. Compress or extend it to fit your reality, but keep the sequence.

Days 1 to 30: establish the truth and the owners

1. Appoint an accountable owner for gig worker compliance, with a named deputy. Compliance without a single throat to choke drifts.
2. Run a classification audit. List every category of person who works for the business and place each into employee, fixed-term employee, gig or platform worker, or independent consultant. Document the reasoning per category.
3. Inventory your worker data. Count active workers, and measure what percentage have a complete identity record, a verified bank account and a registration number.
4. Confirm the aggregator categories that apply to each business line and begin the aggregator registration process.
5. Get finance to define the turnover base and set up the ledger accounts for the welfare fund accrual, even before the first remittance is due.
6. Collect all current contracts and platform terms in one place, including regional variants and any partner or vendor agreements that supply labour indirectly.
7. Map applicable state-level requirements for every state you operate in, since state gig worker laws add their own registration and fee mechanics on top of the central framework.

Days 31 to 60: build the machine

1. Design the worker master data schema, including the field list above, and decide the system of record.
2. Build or configure the onboarding flow so that eShram registration status is captured, validated and blocking where appropriate.
3. Implement identity and bank verification with a penny-drop check and a name-match rule, plus re-verification on change.
4. Stand up the deduplication service and the human review queue.
5. Build the tiered sync jobs and the exception dashboard, with owners and service levels per queue.
6. Rewrite contracts and platform terms with counsel, addressing the misclassification red flags identified in the classification audit.
7. Draft the deactivation policy, the grievance policy and the appeals path, and get them translated into the major languages your workers use.
8. Run the first parallel contribution computation using live data, and reconcile it to the management accounts. Do not remit yet; just prove the model.

Days 61 to 90: operate, prove and harden

1. Go live with registration at scale, starting with a single city or category as a pilot and then expanding.
2. Publish the worker-facing benefits explainer in the app, with a status tile showing registration and verification state.
3. Launch the grievance channel with a ticketing backend, defined response times and an escalation matrix.
4. Run the first full monthly close on the welfare fund accrual, with preparer, reviewer and approver sign-offs recorded.
5. Complete a mock audit. Ask an internal or external reviewer to request the worker register, three random worker files, the contribution working, remittance proof, and the grievance log for the quarter.
6. Publish the monthly compliance calendar and put every recurring task into a system with reminders and owners.
7. Report to the board or leadership on coverage percentage, exception backlog, contribution accrual and open risks. Make this a standing quarterly item.

Payments and payouts: structuring, tax and earnings transparency

Payout design is where classification either holds up or falls apart, because money movement leaves the clearest trail.

Contract structuring

Structure the commercial relationship around output, not attendance. Payment per completed task, trip, order or consultation is consistent with a gig engagement; payment per hour of availability starts to look like wages.

Incentives are permitted and normal, but design them carefully. A bonus for completing a set number of tasks is output-linked. A penalty for not logging in during a mandated window is a control indicator.

Keep rate cards published and versioned. Workers should be able to see the applicable rate card and its effective date, and you should be able to reproduce which version applied to any historical payout.

Invoicing and self-billing

Many platforms operate a self-billing model, generating an invoice or payout statement on behalf of the worker. This is administratively sensible but requires the worker's documented authorisation and a clear statement of what the document represents.

Whatever you generate, it should show gross earnings, each deduction with a reason, taxes withheld, and net paid, for the specific period. A payout that arrives as a single unexplained number is a grievance waiting to happen.

TDS considerations at a general level

Payments to gig and platform workers are typically dealt with under contractor or professional-services withholding provisions rather than salary withholding, and the applicable section, rate and threshold depend on the nature of the service, the status of the payee and whether PAN is available. Some platform arrangements also attract e-commerce operator withholding where the platform facilitates supply by the worker to a customer.

The right approach is to obtain a written tax position for each payout stream, refresh it annually, and encode it in the payout engine as a rule rather than as tribal knowledge. Confirm applicable provisions, rates and thresholds with your tax advisor; they change and they differ by fact pattern.

Operationally, collect PAN at onboarding and validate it. Missing or invalid PAN generally triggers higher withholding, and explaining that to a worker after the fact is far harder than collecting it upfront.

Issue withholding certificates on time and make them retrievable in the app. A worker who cannot get a withholding certificate cannot file a return and cannot claim a refund, and that becomes your support burden.

GST and reverse charge awareness

Whether GST applies to a worker's supply depends on the nature of the service, the worker's registration status and turnover, and specific notifications that place the tax liability on the platform for certain categories of service supplied through an e-commerce operator.

Do not assume. For each service category you operate, get a written position covering who is liable, whether reverse charge applies, what documentation is required and how it flows into your returns. Then build that position into the payout engine so it is applied consistently.

Capture GST registration numbers where workers have them, validate them, and re-check status periodically. A worker who deregisters mid-year changes your treatment from that date.

Payout cycles and earnings statements

Choose a cycle and honour it. Weekly is common for delivery and ride-hailing; fortnightly or monthly suits professional services. Instant payout options are popular but should be an option with transparent fees, not a default that quietly reduces earnings.

Publish a payout calendar and stick to it, including how bank holidays shift dates. Unpredictable payouts are the single largest driver of supply-side churn and of grievance volume.

Make earnings statements downloadable, in a format a bank or a lender will accept. Workers increasingly need income proof for credit, rentals and government schemes, and providing it well is a genuine retention advantage.

Handle deductions with discipline. Every deduction — for a damaged item, a customer refund, an equipment charge, an advance recovery — should have a policy, a cap, a notification to the worker and a dispute route. Unexplained deductions are both a grievance risk and a control indicator that cuts against your classification position.

Misclassification red flags checklist

Use the five classic lenses — control, exclusivity, tools, integration and discipline — to stress-test your own arrangements. Score each honestly.

How to fix red flags without breaking operations

Start with the ones that are cheap to change and high in signal. Language is the cheapest: remove "employee", "salary", "leave", "resignation", "appraisal" and "termination for misconduct" from all worker-facing communication and replace with commercially accurate terms. Then update templates, macros and support scripts so the old language does not creep back.

Next, address exclusivity. If your terms restrict working for other platforms, ask whether the restriction is genuinely necessary. In most cases the legitimate concern is data confidentiality or safety during an active task, both of which can be addressed with narrower clauses.

Then look at mandatory scheduling. Replace mandatory shifts with incentive-based demand shaping: pay more during peak hours rather than requiring presence during peak hours.

Finally, accept that some roles will not survive the test. If a person works full-time, under supervision, in a core function, on a fixed monthly amount, the honest fix is to convert them to fixed-term or permanent employment. Converting proactively is dramatically cheaper than being told to convert retrospectively with interest.

Contracts and platform terms

What to include

• A clear statement of the commercial relationship, and a description of the actual arrangement that matches operational reality.
• Scope of services, service standards and how quality is measured, with published thresholds rather than discretionary judgement.
• The rate card, how it changes, and the notice period before a change takes effect.
• Payout cycle, deduction policy with caps, and the dispute route for payout disagreements.
• Tax responsibilities, including withholding, invoicing or self-billing authorisation, and GST position.
• Registration obligations and cooperation on database registration and refreshes.
• Data protection: what data is collected, why, how long it is retained, who it is shared with, and the worker's rights.
• Insurance and safety: what cover exists, what it excludes, and the incident reporting process.
• Deactivation policy, notice where feasible, reasons, and the appeals mechanism.
• Grievance redressal contact, response timelines and escalation path.
• Governing law, jurisdiction and dispute resolution, drafted to be practically accessible to an individual worker.

What to avoid

Avoid blanket exclusivity, mandatory hours, and any language that mirrors an employment handbook. Avoid clauses that let you change material terms unilaterally with immediate effect and no notice, which are both unfair and evidentially unhelpful.

Avoid indemnities that place unlimited liability on an individual worker; they are unlikely to be enforceable in a meaningful way and they read badly in any dispute. Avoid arbitration clauses that require a worker to travel across the country or fund a share of arbitrator fees they cannot afford.

Avoid burying the important terms. If your deactivation policy is in clause 24.7 of a scroll-to-accept document, assume nobody has read it and design a summary screen instead.

Deactivation policy fairness

Deactivation is the platform equivalent of dismissal in the worker's lived experience, even if it is legally a contractual step. Treat it with proportionate process.

Publish a graded framework: what conduct leads to a warning, what leads to temporary suspension, what leads to permanent deactivation. Distinguish safety and fraud matters, where immediate suspension is justified, from quality matters, where warnings should come first.

Give reasons. A deactivation notice that says only "violation of terms" produces an appeal, a social media post and sometimes a legal notice. A notice specifying the incident, the date and the policy clause resolves most cases at the first step.

Provide a real appeal reviewed by someone other than the original decision-maker, with a stated timeline. Record the outcome. If a substantial share of appeals succeed, your first-line decision rules need fixing.

Settle earnings promptly on exit. Withholding accrued earnings pending an investigation should be time-bound, communicated and rare.

Dispute resolution

Design a tiered path: in-app resolution, then a human review, then a formal grievance officer, then an external route. Most disputes should die at tier one if the earnings statement and policy are clear.

Keep the external route realistic. A worker earning per-task income cannot fund a commercial arbitration. Local jurisdiction, low-cost mediation and the statutory grievance mechanisms are more credible options.

Grievance redressal, safety and worker communication

A functioning grievance system is both a compliance expectation and the cheapest risk-reduction tool available. Most escalations exist because the first channel failed.

Appoint a named grievance officer, publish the contact details, and give the role real authority to reverse decisions. A grievance officer who can only forward tickets is decoration.

Offer multiple channels: in-app, a phone line with support in relevant regional languages, and email. Log every contact in one system with a ticket ID that the worker can see and reference.

Set and publish response times — acknowledgement within a short window, substantive response within a defined number of days — and report performance against them internally every month.

Categorise grievances so you can see patterns: payout disputes, deactivation appeals, safety incidents, harassment, app or technical issues, benefit or registration issues. When one category spikes, treat it as an operational defect rather than a support volume problem.

Safety

Safety obligations apply with particular force to workers who ride, drive, enter customers' homes or handle medical tasks. Build an in-app SOS, an emergency contact record, and a defined incident response runbook with named responders.

Take harassment seriously regardless of classification. Establish a clear reporting route for harassment by customers or by other workers, a route to blocklist offending customers, and support for affected workers. Confirm the applicability of workplace harassment law to your specific arrangements with counsel, and in any event build the process because it is right and because it protects workers and the business alike.

Track incidents, near-misses and vehicle accidents in a register. Review the register monthly and act on hotspots — a particular route, time of day, customer segment or task type.

Communication that actually reaches workers

Push notifications get dismissed. For anything important — a rate card change, a policy update, a benefit deadline — use a layered approach: in-app blocking screen requiring acknowledgement, SMS or WhatsApp, and briefing for field or hub staff who talk to workers in person.

Write in the languages your workers actually speak, and test the copy with a small group before pushing it to everyone. Ambiguous copy generates support volume at a scale that dwarfs the cost of the translation review.

Data privacy obligations when handling worker identity data

You are collecting Aadhaar-linked identity data, bank details, location traces, biometric or photographic verification, and sometimes health information. That is a serious data footprint and it comes with serious obligations under India's data protection framework and sector rules.

Collect only what you need for a stated purpose, and write down the purpose for each field. If nobody can articulate why you store a field, delete it.

Obtain clear, specific consent with a plain-language notice, and version the notice so you can prove what a worker agreed to on a given date. Provide an accessible way to withdraw consent and explain the consequences honestly.

Minimise sensitive identifiers. Prefer masked storage and reference tokens for Aadhaar-type identifiers, encrypt at rest and in transit, and restrict access by role with logging on every read of sensitive fields.

Set retention periods. Identity documents for a worker who left three years ago are a liability, not an asset, unless a specific legal requirement compels retention.

Control vendors. Onboarding agencies, verification providers, payout partners and analytics tools all touch worker data. Each needs a contract with data protection obligations, a defined purpose, security commitments and breach notification duties.

Have a breach plan. Know who decides, who notifies, within what timeline, and what you tell workers. Rehearse it once a year.

Handle location data with particular care. Track during active tasks for safety and service delivery; do not track when a worker is offline, and say so explicitly in the notice. Continuous off-duty tracking is both a privacy problem and a control indicator that undermines your classification position.

Audit readiness: registers, evidence and a monthly compliance calendar

Audit readiness means being able to produce evidence within a day, not within a scramble. The test is simple: if a regulator, auditor or acquirer asked today, could you pull it?

Registers and evidence to maintain

• Aggregator registration certificate and any category amendments.
• Worker register with registration numbers, engagement dates, categories and status.
• Engagement and exit log with reason codes and settlement status.
• Monthly contribution computation working, with base, rate, ceiling test and sign-offs.
• Remittance proofs, acknowledgements and bank statements.
• Grievance register with categories, timelines and outcomes.
• Deactivation and appeals log.
• Safety incident register.
• Contract and policy version history with effective dates.
• Consent and privacy notice versions.
• Vendor agreements for anyone touching worker data or onboarding.
• Tax working papers for withholding and indirect tax positions.

A monthly compliance calendar

Dates below are placeholders for internal rhythm, not statutory deadlines. Confirm every statutory due date with official sources, since they vary by obligation, state and period.

The three questions an auditor will ask

First: what percentage of your active workers have a valid registration in the national database, and what is your remediation plan for the rest? Have the number ready with a trend line.

Second: show me the contribution computation for a specific month, tied to the books, with sign-offs. Have the working file, not a rebuilt version.

Third: pick three workers at random and show me their complete file — onboarding, verification, contract acceptance, activity, payouts, tax documents and, if applicable, exit. If you can do this in ten minutes, you are ready.

Common mistakes in gig worker compliance

Treating registration as a one-time project. Coverage decays every month as new workers join and old ones leave. Without recurring jobs and an exception queue, a 95 percent coverage figure becomes 60 percent within two quarters.

Leaving the welfare fund out of unit economics. Teams that discover the cost at year end have already priced a year of orders wrong and set incentive budgets that assumed the money was available.

Copying an employment handbook into partner terms. The language leaks: "leave", "attendance", "resignation", "misconduct". Every leak is evidence against your own classification position.

Letting one team own everything. Compliance here spans legal, finance, tax, engineering, operations and support. A single owner without a cross-functional forum will fail quietly.

Ignoring state-level requirements. Central and state obligations coexist, and a platform operating in several states may face multiple registration and fee regimes with different formats and cadences. Map every state you operate in.

Forgetting indirect labour. If you use a manpower vendor, a franchise hub or a fleet partner who supplies riders, you may still carry exposure. Include vendors in your classification audit, insist on evidence of their own compliance, and build audit rights into the contract.

Under-investing in deduplication. Duplicate worker records inflate coverage numbers, distort days-of-engagement counts that drive benefit eligibility, and create payout fraud openings.

Building the dashboard but not the queue owners. Visibility without accountability produces very well-documented failure.

Over-promising benefits. Marketing language like "full insurance cover for all our partners" collides with real eligibility conditions and exclusions, and the collision happens at the worst possible moment — during a claim.

Not keeping a decision trail. When a rule is ambiguous, a documented, reasoned position taken in good faith is worth a great deal. An undocumented assumption is worth nothing.

Sector notes: how the picture shifts by business model

The core framework is the same everywhere, but the pressure point differs by model.

• Delivery and quick commerce: high churn makes registration decay and exit reporting the dominant challenge. Automate onboarding and offboarding aggressively.
• Ride-hailing: vehicle documents, licence validity and insurance expiry sit alongside worker registration. Put expiry monitoring on the same dashboard.
• Home and professional services: workers enter customers' homes, so background verification standards, safety tooling and incident response matter disproportionately.
• Healthcare at home: professional credentials and clinical governance are added layers. Verify at onboarding, re-verify on renewal, and keep clinical incident handling separate from commercial grievances.
• Logistics: engagement often runs through fleet owners or intermediaries, so the indirect-labour question is central. Establish whether the obligation attaches to you, the fleet owner, or both.
• Content and creator platforms: earnings are highly variable and worker sophistication ranges widely. Tax documentation and earnings transparency are usually the failure points.
• SMBs using gig labour indirectly through an agency, marketplace or staffing partner should not assume they are out of scope. Ask the supplier for evidence of registration and welfare compliance, keep copies, and build audit rights into the purchase contract.

How an HRMS like CozyHR supports gig worker compliance

Most of what this article describes is record-keeping under time pressure, which is exactly what a modern HRMS is built for. If you are running gig and platform workers on spreadsheets alongside your salaried payroll, the failure mode is predictable.

A worker master that handles non-employee populations lets you keep gig and platform workers in the same system as employees without paying them like employees. That means one place to look for identity data, registration numbers, verification status, activity history and exit records.

Document management with expiry tracking handles the recurring items — ID proofs, licences, vehicle papers, professional certifications, consent versions — and raises alerts before things lapse rather than after.

Payout runs designed for per-task earnings, with configurable deduction rules, withholding logic and downloadable earnings statements, remove the spreadsheet layer that causes most payout disputes.

Compliance calendars with owners, reminders and completion evidence turn the monthly rhythm in the table above into a system that survives people leaving the company.

Reporting and dashboards give you the coverage percentage, exception backlog and accrual position that leadership and auditors will ask for, without a data pull request each time.

CozyHR is built for Indian teams handling exactly this mix of salaried employees, contractual staff and gig or platform workers, with the document trails and reporting that Indian compliance conversations demand. It will not make the legal judgement calls for you — that is your counsel's job — but it will make sure that when you make them, the evidence is where you left it.

Frequently asked questions

Is a gig worker the same as an independent contractor under Indian law?

No. Gig worker is a defined category in the social security framework covering people who earn outside a conventional employer-employee relationship, and it carries specific registration and welfare consequences for aggregators. Independent contractor is a general commercial description of someone working under a contract for service. A person can be both descriptions at once, but the compliance obligations flow from the gig and platform worker framework, so classify on that basis and confirm the position for your fact pattern with counsel.

Does every company that hires freelancers need to register as an aggregator?

Generally, no. Aggregator obligations attach to digital intermediaries that connect buyers and sellers of services in the recognised categories. A company that hires a freelance designer directly is a client, not an aggregator. If you run a platform or marketplace that matches customers to service providers and monetises that matching, you should assume you are in scope and verify with your advisor.

What is eShram registration and who is responsible for doing it?

eShram is the national database for unorganised workers, and gig and platform workers are expected to be registered there with a unique identifier so that benefits attach to the person rather than to a platform account. In practice, aggregators are expected to facilitate registration during onboarding rather than leave it to the worker. Build it into your flow, capture and validate the number, and refresh details periodically.

How should we budget for the platform worker welfare fund?

Model it as a percentage of a clearly defined turnover base, subject to the ceiling linked to amounts paid to gig and platform workers, and compute both figures every month so you know which one binds. Accrue monthly into a dedicated ledger account even if remittance is less frequent, and build the contribution into unit economics from the start. Confirm the current rate, base definition and ceiling with official sources or your advisor before finalising the model.

What happens if we misclassify gig workers as contractors?

The exposure is cumulative rather than single-issue: retrospective social security contributions with interest and penalties, potential gratuity and leave claims, tax re-characterisation, and indirect tax consequences, alongside reputational and investor-diligence damage. The practical defence is substance, not paperwork — reduce control, exclusivity, equipment mandates, organisational integration and disciplinary machinery, and reclassify honestly where the arrangement is really employment.

Do state gig worker laws replace the central framework?

They generally sit alongside it rather than replacing it. Rajasthan enacted a dedicated platform gig workers law in 2023, Karnataka has advanced its own framework, and other states have drafts in circulation, each with its own registration and fee mechanics. Map every state you operate in, and check the current status of each with the relevant state labour department, since this area is moving quickly.

How often should we sync worker data with the national database?

Use a tiered cadence rather than a single rule. Push new registrations, bank changes and deactivations in near real time because they have immediate consequences, run activity and status updates in a daily batch, produce contribution inputs and register snapshots monthly, and do a full refresh and reconciliation quarterly. The quarterly full refresh is the step most teams skip and the one that catches silent data drift.

What is the single fastest improvement for aggregator compliance in India?

Build an exception dashboard with named owners. Most platforms already collect much of the required data but have no single view of which workers are unregistered, which bank verifications failed, which duplicates are pending review and which exits were never reported. Making that visible, with a name and a service level against each queue, typically moves coverage numbers faster than any other single intervention.

Conclusion: compliance as an operating discipline

Gig worker compliance in India rewards businesses that treat it as a repeatable operational process rather than a legal event. The framework is coherent once you see its shape: register the aggregator, register the people, fund the welfare, keep the records current, and be able to prove all of it on demand.

The hardest part is not understanding the rules. It is building the habits — the monthly accrual, the exception queue, the quarterly refresh, the grievance SLA review, the annual classification re-audit — and making them survive team changes and growth spurts.

Start with the classification audit and a coverage number. Those two facts will tell you more about your actual risk than any amount of policy drafting, and they will point directly at what to fix first.

And because rules, rates and deadlines in this area continue to evolve at both central and state level, make verification a standing item rather than a one-off. A quarterly conversation with your advisor is cheaper than a retrospective assessment.

If you would like the record-keeping side of this handled properly — worker master data, document expiry tracking, payout runs with earnings statements, compliance calendars and the reports auditors ask for — take CozyHR for a spin. Book a walkthrough with our team and see how your gig and platform worker operations would look with the evidence trail already in place.