Turnover or Payout: The Gig Levy Formula That Swings an Aggregator's Contribution From 0.8% to 143%

The aggregator contribution to the gig workers' Social Security Fund has a settled legal basis and an unsettled arithmetic. Section 114(4) of the Code on Social Security, 2020 fixes the contribution at not less than one per cent and not more than two per cent of an aggregator's annual turnover, subject to a ceiling: the amount cannot exceed five per cent of the sum paid or payable by the aggregator to its gig workers and platform workers. The Ministry of Labour and Employment is separately weighing a different construction, in which the payout figure becomes the base rather than the ceiling, at a rate of up to five per cent of amounts paid to workers. Business Standard, carrying PTI, reported the deliberation on 6 September 2026.

The worked examples that accompanied the report are the reason this is not a drafting footnote. A food-delivery platform running 30 lakh orders a day at an average payout of Rs 30 per order, on turnover of Rs 20,000 crore, lands at roughly Rs 164.25 crore a year under the five per cent payout formula, about 0.82 per cent of turnover. A ride-hailing platform running 60 lakh trips a day across average ticket sizes of Rs 75, Rs 125 and Rs 300 lands at roughly Rs 1,428.1 crore against turnover of Rs 1,000 crore, or about 142.8 per cent of turnover.

Same rate. Same statute. Same category of worker. A gap of 142 percentage points between two businesses that both call themselves aggregators. For a chief financial officer building next year's budget, and for the broker placing that platform's group personal accident cover for gig platforms, the operative fact is that the liability cannot be estimated within an order of magnitude until the base is settled.

The current provision carries two numbers that do different jobs. The one to two per cent band applies to annual turnover and sets the charge. The five per cent of worker payouts applies as a ceiling and sets the maximum. Read together, an aggregator pays the lower of the two.

That structure has a predictable consequence that nobody notices until the numbers are run. Whether the ceiling ever operates depends entirely on the ratio between what a platform books as revenue and what it pays out to workers, and the arithmetic sets the threshold precisely. Five per cent of payouts falls below one per cent of turnover whenever annual worker payouts are less than a fifth of turnover, and below two per cent of turnover whenever payouts are less than two fifths of it.

So the same provision already behaves as two different levies depending on the platform:

• Where annual worker payouts run below about a fifth of turnover, the ceiling sits under both ends of the turnover band, binds whatever rate is notified, and Section 114(4) is in practice already a five per cent payout levy.
• Where payouts run above about two fifths of turnover, the ceiling sits above both ends of the band and can never operate, so the provision is a turnover levy with a cap that is decorative.
• Between those two points the answer depends on the rate the Centre notifies inside the one to two per cent range, which is the only band where the notified rate changes the bill.

Food delivery sits in the first group. Ride-hailing sits a long way inside the second.

Take the food-delivery example as reported. Thirty lakh orders a day at an average payout of Rs 30 per order is Rs 9 crore of worker payouts a day, or about Rs 3,285 crore a year. Five per cent of that is Rs 164.25 crore, which is the figure in the worked example and about 0.82 per cent of the Rs 20,000 crore turnover.

Now run the same platform through Section 114(4) as it stands. One per cent of Rs 20,000 crore is Rs 200 crore. Two per cent is Rs 400 crore. The ceiling of five per cent of payouts is Rs 164.25 crore. The ceiling is below both ends of the turnover band, so it binds, and the platform pays Rs 164.25 crore whatever rate the Centre notifies inside the one to two per cent range.

The conclusion is worth stating plainly. For this profile, a switch from the turnover base to a five per cent payout base changes nothing. The platform already pays five per cent of payouts, because the existing ceiling has quietly converted its turnover levy into a payout levy. What the change removes is the option value of a lower notified rate, since a notification at one per cent and a notification at two per cent currently produce the same bill.

The one variable that moves this

Average payout per order is the whole calculation. A shift from Rs 30 to Rs 40 in average delivery-partner payout, at constant order volume, takes annual payouts from Rs 3,285 crore to Rs 4,380 crore and the five per cent charge from Rs 164.25 crore to Rs 219 crore, which is now above the one per cent turnover figure of Rs 200 crore. At that point the ceiling stops binding and the base matters again. Payout inflation, not order growth, is what flips this platform from one regime to the other.

The ride-hailing example moves in the opposite direction. Sixty lakh trips a day across average ticket sizes of Rs 75, Rs 125 and Rs 300 generate a worker payout pool large enough that five per cent of it is Rs 1,428.1 crore a year, implying annual driver payouts in the region of Rs 28,500 crore. Recognised turnover in the example is Rs 1,000 crore. The charge is therefore about 142.8 per cent of turnover.

Under Section 114(4) as drafted, that same platform pays one to two per cent of Rs 1,000 crore, which is Rs 10 crore to Rs 20 crore. The ceiling of Rs 1,428.1 crore is more than seventy times the maximum turnover charge and can never operate. Move the payout figure to the base and the liability multiplies by a factor of roughly 71 at the two per cent reading and 143 at the one per cent reading.

A levy that exceeds a company's entire recognised revenue by 42 per cent is not a cost line to be absorbed. It is either passed to riders through fares, deducted from driver earnings, or it closes the model. Any of the three has second-order consequences for the insurance programme sitting on top of the platform, which the later sections take up.

Neither platform in these examples is more or less generous to its workers. The divergence comes from how each recognises revenue, and it is worth being precise about the mechanism because it determines who lobbies for which base.

Ride-hailing platforms in India generally recognise revenue on a net basis. The platform treats itself as an agent arranging a ride between a driver-partner and a rider, so the fare collected on the rider's behalf is a pass-through and only the commission or take rate reaches the income statement. A platform intermediating Rs 30,000 crore of gross bookings can therefore report turnover in the hundreds or low thousands of crore.

Food-delivery platforms recognise a larger share of the transaction. Commission on the restaurant order, platform fees and delivery charges all sit in revenue, while the payment to the delivery partner is a cost of Rs 30 or so on an order whose booked revenue is materially higher. Payouts as a share of recognised revenue are therefore small.

The result is that turnover and worker payouts are simply not comparable denominators across the two models:

• On a turnover base, the platform that books revenue net is undercharged relative to the number of workers it engages, because most of the money it handles never enters its turnover.
• On a payout base, that same platform is charged a multiple of everything it earns, because the pass-through it never recognised as revenue is now the tax base.
• Neither base tracks the thing the fund is meant to be sized against, which is the number of workers engaged and the benefits owed to them.

A per-worker or per-transaction levy would sidestep the accounting question entirely, but neither is what Section 114(4) contemplates, and neither is what is currently under consideration.

In practice, platform welfare spend comes out of one pot. The statutory levy is not negotiable once notified. Everything voluntary competes for what is left, and that voluntary layer is where the insurance sits: group personal accident cover for delivery and driver partners, group health top-ups, term life, hospital cash, income-protection riders and, on the liability side, the platform's own third-party programme.

When the statutory line can move from Rs 20 crore to Rs 1,428 crore on an administrative decision, three things follow for anyone underwriting or placing that account.

1. Voluntary cover is the first casualty. Discretionary GPA and health top-ups bought to demonstrate responsibility are the easiest line to cut, and they get cut before headcount does. An insurer holding a three-year rate guarantee on an aggregator account is carrying an unpriced budget risk that has nothing to do with claims experience.
2. Volume commitments should be treated as soft. Minimum-life or minimum-premium commitments negotiated on the assumption of a stable welfare budget are worth less than the paper on the day the payout base is notified. Declaration-based rating on actual monthly active workers is the safer construction for both sides.
3. The levy still is not insurance. Contributions fund benefits administered through the fund. They do not indemnify the platform against a vicarious liability claim from an injured pillion passenger, a motor third-party award, or a claim arising from a delivery partner's road accident. That distinction is set out in more detail in the comparison of the gig social security fund against commercial cover, and it survives whichever base the Centre picks.

Brokers renewing aggregator accounts in the current cycle should be building the mid-term flexibility in now rather than arguing for it after a notification. A policy rated on declared active workers with a quarterly declaration, rather than a fixed sum insured on a fixed headcount, absorbs a budget shock without producing a coverage dispute about who was actually on cover on the date of loss.

No obligation crystallises until the Centre notifies a rate and a base, so there is nothing yet to provide for in the strict accounting sense. That is not the same as having nothing to disclose.

A range running from roughly 0.8 per cent of turnover to roughly 143 per cent of turnover is a sensitivity, and a sensitivity of that width belongs in three places: the board's risk register, the management discussion of the annual report, and any offer document or investor communication that touches regulatory cost. A platform that tells the market the gig levy is immaterial on the strength of the turnover reading, and then finds the payout base notified, has a disclosure problem before it has a cash problem, and its directors have a claim notification to make under the directors and officers liability programme.

The practical accounting position for a ride-hailing profile is straightforward to state and uncomfortable to hold:

• Model both bases and both ends of the notified rate range, and carry all four numbers in the budget pack.
• Disclose the range as a contingency rather than quoting a single point estimate that flatters the turnover reading.
• Keep the worker payout ledger reconciled monthly, because the payout figure is the base under one construction and the ceiling under the other. It is load-bearing either way.
• Do not net off state-level obligations. The Karnataka platform-based gig workers welfare fee is a separate charge on a separate base, as covered in the Karnataka gig welfare fee analysis, and a central levy does not extinguish it.

The payout ledger deserves particular attention. It is the single dataset that feeds the levy calculation, the state welfare fee computations, the e-Shram registration counts and the exposure declaration on the group personal accident placement. Platforms that maintain it to audit standard have one number to defend across four processes. Platforms that reconstruct it each time have four numbers that will not agree.

The window between a reported deliberation and a notified rule is the only period in which any of this is cheap to prepare for.

1. Run both formulas on your own numbers. Compute one and two per cent of turnover, and five per cent of annual worker payouts. Whichever is smaller is today's liability; the payout figure is tomorrow's worst case. If those two numbers are within a factor of two, the change is a budget item. If they are seventy times apart, it is a board matter.
2. Identify whether the ceiling currently binds. If it does, a move to a payout base is neutral for you, and the argument to make in consultation is about rate rather than base. If it does not, you are the party the change is aimed at.
3. Ring-fence the voluntary insurance budget in writing. A welfare budget line that is explicitly separate from the statutory contribution line survives a reforecast better than one that is not.
4. Add a regulatory-change clause to multi-year insurance arrangements. Both sides need an exit or a re-rate if the platform's welfare spend is re-based by statute during the policy term.
5. Reconcile the payout ledger to audit standard now. The number will be examined, whichever base is chosen.
6. File a considered submission. The arithmetic in the reported examples is the strongest argument available to any platform that recognises revenue net, and it is arithmetic rather than pleading.

The deliberation reported on 6 September 2026 is not a settled outcome, and the Centre may yet retain the turnover base with the payout ceiling intact. Planning on that assumption is a choice, not a default, and it should be a choice the board has actually made.