Как цифровой платформе считать 60 часов работы самозанятого в месяц

Технический разбор критерия из постановления № 760: события, идентификация заказчика, параллельные заказы и хранение доказательств

С 1 октября 2026 года операторы посреднических цифровых платформ обязаны технически ограничивать систематическое и продолжительное выполнение работ самозанятым в пользу одного заказчика [1]. Правительство утвердило соответствующий критерий постановлением, которое вступает в силу одновременно с законом о платформенной экономике [14]: более 60 часов в месяц на одного заказчика в течение 6 месяцев подряд, но только в 14 сферах деятельности заказчика — от строительства и торговли до IT и образования [2][3][15]. Если хотя бы в одном из шести месяцев нагрузка на заказчика упадёт до 60 часов и ниже, отсчёт полугодия начинается заново [4]. Разовое превышение лимита в отдельном месяце само по себе не запускает никаких последствий — критерий срабатывает только на длинной дистанции.

Дальше — не про смысл закона, а про то, как это лечь в код: какое событие считать началом и концом работы, что делать с пересекающимися заказами, как опознать одного заказчика за разными юрлицами и филиалами, как обрабатывать правки задним числом и что хранить на случай спора.

Почему это не разовая доработка, а новый учётный контур

До 1 октября 2026 года для большинства платформ продолжительность работы исполнителя была витринной метрикой: она влияла на рейтинг, статистику, иногда на тарификацию, но не на юридическую квалификацию отношений. Теперь она приобретает регуляторный статус: превышение критерия обязывает оператора технически исключить возможность заключения новых договоров между конкретным самозанятым и конкретным заказчиком [4]. Это уже не аналитика, а управляющий сигнал, от которого зависит, может ли пользователь оформить следующий заказ.

Важно, что закон адресует обязанность именно оператору платформы, а не заказчику или самому самозанятому. Пункт 5 части 1 статьи 17 федерального закона № 289-ФЗ прямо возлагает на оператора обязанность установить на техническом уровне ограничения систематического и продолжительного выполнения работ, оказания услуг партнёром-исполнителем, применяющим налог на профессиональный доход, в интересах одного пользователя-заказчика [5]. Значит, спор о превышении лимита будет опираться в первую очередь на данные самой платформы — логи заданий, факты принятия и завершения заказов, время активности, маршрутные и иные цифровые следы, если они предусмотрены сервисом [6]. Это меняет требования к архитектуре учёта часов: она должна быть не просто точной, а объяснимой и защищаемой перед налоговым органом и в суде.

Что именно измеряет критерий

Формулировка постановления Правительства РФ от 19.06.2026 № 760 звучит так: критерием является количество часов выполнения работ (оказания услуг) для одного пользователя-заказчика с использованием технической возможности платформы за каждый месяц, которое в течение 6 месяцев подряд составляет более 60 часов [3]. Здесь заложены три технических следствия, которые легко упустить при поверхностном чтении:

1. Порог применяется помесячно, а не нарастающим итогом. Считать нужно 6 отдельных месячных значений, а не скользящую сумму часов за полгода.
2. Критерий выполняется только тогда, когда каждый из шести подряд идущих месяцев превысил 60 часов. Если хотя бы один месяц из шести оказался в пределах нормы, вся серия обнуляется, и отсчёт полугодия начинается заново [4].
3. Ограничение действует не универсально, а по конкретным видам деятельности заказчика — строительство, складское хозяйство и вспомогательный транспорт, оптовая и розничная торговля (кроме автотранспорта), обслуживание зданий и территорий, производство пищевых продуктов, общепит, операции с недвижимостью, образование, разработка ПО и сопутствующие консультационные услуги, деятельность по подбору персонала, IT-услуги, реклама и исследование рынка, сухопутный и трубопроводный транспорт, спорт и развлечения [2]. Это коды 41, 42, 43, 52, 46, 47, 81, 10, 56, 68, 85, 62, 78, 63, 73, 49 и 93 по ОКВЭД в привязке к деятельности именно заказчика, а не платформы или исполнителя.

Отдельно стоит развести субъектный состав: сам критерий и обязанность его отслеживать сформулированы применительно к самозанятым — плательщикам НПД. Индивидуальные предприниматели, работающие через ту же платформу, под это конкретное ограничение по продолжительности формально не подпадают — но риск переквалификации гражданско-правового договора в трудовой для них сохраняется по общим основаниям, независимо от часового лимита [7].

Какое событие считать началом и окончанием работы

Закон не определяет техническую единицу учёта времени — это решение platформы, но оно должно быть воспроизводимым и обосновываемым. На практике встречаются три модели, и они дают разные цифры для одного и того же исполнителя:

• Модель "жизненный цикл заказа": начало — статус «заказ принят исполнителем» или «работа начата» в системе, конец — статус «работа завершена» или «заказ закрыт заказчиком». Проста в реализации, но плохо отражает реальные трудозатраты, если исполнитель не отмечает паузы.
• Модель "фактическая активность": события старт/стоп таймера, GPS-трек, взаимодействие с приложением или API конкретного заказа. Точнее отражает реальное время, но требует, чтобы исполнитель дисциплинированно нажимал старт/стоп, а платформа умела отличать активность от простоя.
• Модель "расчётная продолжительность": платформа не измеряет время напрямую, а вычисляет его из типа задания и нормативов (например, «доставка = 40 минут», «урок = 60 минут»). Такой подход годится там, где нет технической возможности замерять фактическое время, но он самый уязвимый для спора: оппонент всегда может утверждать, что реальная выработка была другой.

Для целей 60-часового критерия разумно фиксировать оба конца интервала как отдельные, неизменяемые события с меткой времени, источником (кто и как инициировал событие — исполнитель, заказчик, автоматика по таймауту) и ссылкой на конкретный заказ и конкретного заказчика. Начисленная продолжительность — это производная величина, которую в дальнейшем можно пересчитать из первичных событий, а не самостоятельная сущность, которую можно молча отредактировать.

Как учитывать неполные часы

Постановление говорит о «часах», но не объясняет, что делать с 45 минутами. Здесь у платформы есть свобода выбора метода округления, но выбор должен быть закреплён во внутреннем регламенте и применяться единообразно, потому что именно правило округления определит, в какую сторону сработает погрешность на границе лимита:

• Округление вниз (в пользу исполнителя и заказчика) снижает риск ложного срабатывания ограничения, но может занизить реальную нагрузку при систематическом округлении множества коротких заказов.
• Округление вверх консервативнее с точки зрения соответствия духу нормы (не пропустить превышение), но чаще будет закрывать заказчику доступ к исполнителю.
• Учёт в минутах с переводом в часы только на этапе агрегации — самый нейтральный вариант: копится точная сумма минут за месяц, а сравнение с порогом 60 часов происходит один раз, в конце периода, по фактической сумме без промежуточных округлений.

Третий вариант предпочтителен технически: он исключает накопленную ошибку округления и упрощает объяснение методики при проверке — есть единственная точка перевода единиц измерения, и она документирована.

Что делать с параллельными заказами

Если исполнитель одновременно числится «в работе» по двум заказам одного заказчика — это почти всегда следствие того, что он не закрыл предыдущий статус, работал по модели "жизненный цикл заказа" с широким интервалом или физически совмещал два небольших задания. Наивное суммирование продолжительности каждого заказа задвоит часы и создаст ложное превышение лимита.

Практический принцип: единицей учёта для критерия должно быть астрономическое время, в течение которого исполнитель был занят в интересах данного заказчика, а не сумма продолжительностей отдельных заказов. Технически это означает:

1. Собрать все интервалы «начало–конец» по заказам одного заказчика за месяц.
2. Объединить (merge) пересекающиеся и смежные интервалы в непрерывные отрезки.
3. Просуммировать длительность полученных отрезков — это и есть месячный показатель для сравнения с порогом в 60 часов.

Отдельно нужно решить, что делать с параллельными заказами разных заказчиков: они не пересекаются для целей 60-часового критерия (он считается по каждому заказчику отдельно), но одновременная занятость у нескольких заказчиков — это самостоятельный содержательный сигнал (физическая невозможность одновременно оказывать личные услуги двум сторонам), который стоит логировать отдельно как индикатор потенциально недостоверных данных о времени.

Как опознать одного заказчика при нескольких договорах и филиалах

Закон оперирует понятием «пользователь-заказчик» — это участник платформы, зарегистрированный как сторона заказа [5]. Технически логично использовать в качестве первичного идентификатора заказчика реквизит, однозначно определяющий юридическое лицо или ИП — ИНН, а не внутренний ID личного кабинета, номер филиала или бренд. Причины:

• Один заказчик может вести на платформе несколько кабинетов (по регионам, брендам, юридическим лицам холдинга).
• Один ИНН может стоять за несколькими фактическими адресами оказания услуг (филиалами, магазинами, точками).
• Смена реквизитов кабинета (переименование, реорганизация) не должна обнулять накопленную историю часов, если ИНН заказчика не изменился.

Открытый вопрос, по которому в изученных источниках нет прямого нормативного ответа: должна ли платформа агрегировать часы по группе аффилированных юридических лиц (например, по признакам группы лиц из статьи 9 закона № 135-ФЗ «О защите конкуренции») [8], если самозанятый работает формально на разные ИНН, входящие в один холдинг. Буквальное прочтение критерия говорит о «пользователе-заказчике» в единственном числе и не содержит отсылки к аффилированности [3][5]. Подтверждённых разъяснений о том, что регулятор намерен требовать сквозной агрегации по группе компаний, найти не удалось — это открытая зона риска, а не установленное требование. Разумная защитная позиция для платформы — реализовать точный учёт по ИНН заказчика в строгом соответствии с буквой постановления, но параллельно вести (не обязательно публично) риск-индикатор по аффилированным группам как основание для собственной, более осторожной политики допуска к заказам — отдельно от механики технического блокирования, прямо предписанного законом.

Как обрабатывать исправления задним числом

Отмена заказа, корректировка времени по жалобе, технический сбой трекера, судебное решение о пересчёте — всё это требует правки уже учтённых данных, когда решение о допуске или блокировке заказчика к новому заказу, возможно, уже принято на основе старых цифр. Здесь стоит придерживаться нескольких принципов:

• Исходные события не удаляются и не перезаписываются. Любая корректировка — это новая запись со ссылкой на исправляемое событие, причиной изменения и указанием, кто и когда внёс правку. Это делает всю историю пересчёта прозрачной и предъявляемой по запросу.
• Агрегаты за месяц пересчитываются, но хранится и предыдущая версия расчёта. Платформа должна уметь показать, каким было решение «на момент принятия» и каким стало «после исправления», отдельно.
• Разграничить эффект исправления во времени. Если правка уменьшает нагрузку и приводит к тому, что месяц, ранее превышавший 60 часов, задним числом опускается ниже порога, — нужно явно решить, влияет ли это на уже наступившую блокировку (снимать её или нет) и как это соотносится с фактически поданными заказчику уведомлениями. Однозначного нормативного ответа на этот процедурный вопрос в изученных источниках нет; практика по нему, вероятно, сложится после начала правоприменения с 1 октября 2026 года.
• Хранить исправления не менее срока, за который может быть предъявлена претензия по НДФЛ и страховым взносам при переквалификации договора — то есть с запасом на глубину налоговой проверки, а не только на срок действия постановления.

Когда предупреждать платформу, исполнителя и заказчика о приближении к порогу

Ни закон № 289-ФЗ, ни постановление № 760 не содержат обязательного требования заранее предупреждать стороны о приближении к 60-часовому порогу — это исключительно операционное решение платформы, а не нормативное предписание [3][5]. Тем не менее с точки зрения снижения споров и предсказуемости для бизнеса есть смысл в многоступенчатой системе оповещений:

• Информационный порог (например, 70–80% от 60 часов в текущем месяце) — уведомление заказчику и исполнителю в личном кабинете без каких-либо ограничений функциональности.
• Порог риска (превышение 60 часов в текущем месяце) — фиксация факта превышения месяца в счётчике полугодия, уведомление о том, что это первый (второй, третий…) месяц подряд с превышением, и о том, что произойдёт при достижении шестого месяца подряд.
• Порог блокировки (шестой месяц подряд с превышением 60 часов) — техническое ограничение возможности заключения новых договоров между этим самозанятым и этим заказчиком [4], с объяснением причины в интерфейсе обеих сторон и указанием, что именно нужно изменить (сменить исполнителя, оформить отношения иначе), чтобы возобновить работу.

Такая ступенчатая логика не следует напрямую из текста нормативных актов, но соответствует их цели — не создавать сюрприз в последний момент, а дать сторонам время скорректировать модель сотрудничества.

Какие расчёты и исходные события хранить для спора

Поскольку бремя объяснения цифр в споре ляжет на данные платформы [6], набор для хранения должен обеспечивать полную реконструкцию расчёта, а не только итоговое число часов. Разумный минимум:

• идентификаторы исполнителя (включая статус плательщика НПД на момент оказания услуги — этот статус может измениться) и заказчика (ИНН как первичный ключ, история смены реквизитов кабинета);
• идентификатор заказа и вид деятельности, к которому он отнесён по ОКВЭД заказчика — именно этот код определяет, применяется ли вообще критерий [2];
• необработанные события начала и окончания работы с таймстампами, источником события и способом фиксации (ручной ввод, автоматический таймер, геотрек, API-вызов);
• результат объединения пересекающихся интервалов (шаг с параллельными заказами) как отдельно сохранённая производная величина;
• помесячный агрегат часов по связке «исполнитель — заказчик» и признак, превышен ли порог в этом месяце;
• состояние счётчика «месяцев подряд с превышением» на конец каждого месяца и дата его обнуления, если оно происходило;
• журнал всех исправлений задним числом с указанием причины, автора правки и версий агрегата до и после;
• журнал уведомлений, отправленных заказчику и исполнителю, и факт технического ограничения (когда и по какой связке оно было применено).

Такой набор позволяет не просто предъявить итоговую цифру, а показать, из каких первичных фактов она получена, и выдержать проверку логики шаг за шагом — что особенно важно, если дело дойдёт до переквалификации договора и доначисления НДФЛ и страховых взносов, а также привлечения заказчика к ответственности по части 4 статьи 5.27 КоАП РФ за ненадлежащее оформление трудовых отношений [9].

Нужно ли автоматически ограничивать новые задания после достижения критерия

Да, и это прямо следует из закона: при достижении критерия оператор обязан на техническом уровне ограничить систематическое и продолжительное выполнение работ — то есть исключить возможность заключения новых договоров между конкретным самозанятым и конкретным заказчиком по достижении шестого месяца подряд с превышением 60 часов [4][5]. При этом:

• ограничение действует применительно к конкретной связке «исполнитель — заказчик», а не к аккаунту исполнителя на платформе в целом — с другими заказчиками он может продолжать работать без ограничений;
• закон не регламентирует, на какой срок вводится ограничение и при каких условиях оно может быть снято — этот процедурный вопрос остаётся на усмотрение платформы, и его тоже придётся закрепить во внутреннем регламенте;
• техническое ограничение — это не автоматическая переквалификация уже действующих отношений в трудовые: это отдельный вопрос, который решают налоговый орган и суд, оценивая совокупность признаков (подчинение внутреннему распорядку, обеспечение условий труда со стороны заказчика, отсутствие у исполнителя других источников дохода, регулярность выплат) [7], а часовой лимит — лишь один из таких признаков.

Российская специфика и куда смотреть до 1 октября 2026 года

Всё описанное регулирование — сугубо российская конструкция: закон № 289-ФЗ вводит новые для отечественного права понятия «платформенная экономика» и «посредническая цифровая платформа» [10], а сам механизм 60-часового лимита без аналогов встроен в существующий режим налога на профессиональный доход. Международных стандартов подсчёта «часов на одного заказчика» для целей налоговой квалификации самозанятости в этом виде не существует — это специфическая мера именно российского регулирования платформенной занятости.

Платформам, которые уже строят похожую логику, дополнительно стоит держать в поле зрения:

• изменения реестра посреднических цифровых платформ и критерии попадания в него — от этого зависит, распространяется ли на конкретный сервис весь пакет обязанностей вообще [11];
• обязанность передавать в ФНС сведения о доходах, сделках и заказах партнёров — это отдельный, более широкий канал отчётности, который логично проектировать в одной инфраструктуре со счётчиком часов, а не отдельно [12];
• долю самозанятых, уже работающих через цифровые платформы (по недавним оценкам — большинство активных плательщиков НПД), которая показывает, что для многих платформ это не нишевая доработка, а изменение основного процесса приёма заказов [13].

Подтверждённые данные о правоприменительной практике по критерию 60 часов в открытых источниках на сегодня отсутствуют — постановление № 760 вступает в силу только с 1 октября 2026 года, и то, как именно будут разрешаться спорные ситуации (частичные месяцы, агрегация по группам компаний, снятие блокировки после исправления данных), покажет практика первых месяцев действия нормы.

Как может помочь «Пятый фактор»

Задача, описанная выше, — это не одна фича, а изменение учётного контура платформы: нужно спроектировать модель событий, правила агрегации пересекающихся интервалов, идентификацию заказчика по ИНН независимо от количества кабинетов и филиалов, неизменяемый журнал корректировок и интеграцию с уведомлениями и механизмом технической блокировки заказов. Команда «Пятого фактора» может изучить текущую модель данных платформы, предложить архитектуру учёта часов и хранения доказательной базы и помочь с разработкой или доработкой соответствующих модулей — от событийного журнала до отчётов, которые можно будет предъявить при налоговой проверке. Если для конкретной платформы функциональность уже частично реализована штатными средствами используемой CRM или ERP-системы, разумнее не переписывать её с нуля, а точечно донастроить существующий процесс — и это тоже стоит обсудить до начала разработки.

Вывод

Технически 60-часовой критерий — это не разовая проверка «превышен лимит или нет», а помесячный конечный автомат с состоянием («сколько месяцев подряд превышение длится»), точной идентификацией заказчика, объединением пересекающихся интервалов и неизменяемым журналом событий, который выдержит и налоговую проверку, и судебный спор. Разработать это правильно с первого раза дешевле, чем потом объяснять регулятору, почему цифры платформы нельзя проверить.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] consultant.ru — Постановление Правительства РФ от 19.06.2026 N 760 — https://www.consultant.ru/document/cons_doc_LAW_537516/

[2] consultant.ru — Постановление Правительства РФ от 19.06.2026 N 760 (перечень сфер деятельности, пункт 2) — https://www.consultant.ru/document/cons_doc_LAW_537516/

[3] pravo.gov.ru — Постановление Правительства Российской Федерации от 19.06.2026 № 760 — http://publication.pravo.gov.ru/document/0001202606240002

[4] buh.ru — Ограничения на работу с самозанятыми с 1 октября 2026 года — https://buh.ru/articles/ogranicheniya-na-rabotu-s-samozanyatymi-s-1-oktyabrya-2026-goda.html

[5] normativ.kontur.ru — Федеральный закон от 31.07.2025 N 289-ФЗ (редакция от 31.07.2025) — https://normativ.kontur.ru/document?documentId=500750&moduleId=1

[6] ap-group.ru — Закон о платформенной экономике с 1 октября 2026 года: вопросы-ответы — https://www.ap-group.ru/press-centre/journal/zakon-o-platformennoy-ekonomike-s-1-oktyabrya-2026-goda-voprosy-otvety-chto-nuzhno-znat-predprinimat/

[7] buh.ru — Ограничения на работу с самозанятыми с 1 октября 2026 года (признаки трудовых отношений, письмо Минфина от 12.08.2025 № 03-11-11/78228) — https://buh.ru/articles/ogranicheniya-na-rabotu-s-samozanyatymi-s-1-oktyabrya-2026-goda.html

[8] vc.ru — Фактическая и юридическая аффилированность — https://vc.ru/ask/1904841-affilirovannost-fakticheskaya-i-yuridicheskaya

[9] buh.ru — Ограничения на работу с самозанятыми с 1 октября 2026 года (ответственность по ч.4 ст.5.27 КоАП РФ) — https://buh.ru/articles/ogranicheniya-na-rabotu-s-samozanyatymi-s-1-oktyabrya-2026-goda.html

[10] kremlin.ru — Федеральный закон от 31.07.2025 г. № 289-ФЗ — http://www.kremlin.ru/acts/bank/52331

[11] probusiness.news — Новые критерии платформенной занятости для ограничения работы с самозанятыми с октября 2026 года — https://probusiness.news/pro-biznes/samozanyatiy/novye-kriterii-platformennoy-zanyatosti-dlya-ogranicheniya-raboty-s

[12] klerk.ru — Новые правила платформенной занятости: что изменится с 2026 года — https://www.klerk.ru/blogs/jumpfinance/668718/

[13] rambler.ru — Платформенная занятость: что ждёт самозанятых через два месяца — https://www.rambler.ru/pro/trud/56820173-platformennaya-zanyatost-chto-zhdet-samozanyatyh-cherez-dva-mesyatsa/

[14] kommersant.ru — Правительство РФ утвердило критерии платформенной занятости для исполнителей — https://www.kommersant.ru/doc/8764026

[15] runews24.ru — Лимит в 60 часов: правительство определило критерии платформенной занятости — https://runews24.ru/society/25/06/2026/limit-v-60-chasov-pravitelstvo-opredelilo-kriterii-platformennoj-zanyatosti