Коротко: процесс выплат одним взглядом

• Выплаты исполнителям — это не разовая операция перевода, а процесс из четырёх стадий: реестр исполнителей с их статусами, проверка налогового статуса, оформление закрывающих документов и сверка с учётной системой. Пока подрядчиков единицы, стадии проходятся вручную и незаметно. На десятках и сотнях исполнителей каждая превращается в отдельную зону ответственности.
• Для самозанятых главная сложность возникает на проверке налогового статуса, а не на самом переводе. Годовой лимит дохода на НПД (налоге на профессиональный доход) составляет 2,4 млн ₽, отсчёт идёт по календарному году; при его превышении статус в текущем году перестаёт применяться, и это меняет налоговый режим выплаты прямо в середине месяца.
• Проверять статус самозанятого нужно близко к моменту выплаты, а не один раз при добавлении исполнителя в базу: между этими точками он может сняться с учёта, и оформленный по устаревшему статусу документ придётся переделывать.
• Выплаты российским самозанятым и работа с распределённой или зарубежной командой — две разные операционные задачи, и закрываются они разными инструментами. Один сервис, который одинаково хорошо делает и то и другое, встречается редко.
• Выстраивание процесса сводится к нескольким управленческим решениям: провести ревизию текущих потоков, выбрать модель (разовые выплаты, выплаты по реестру или их сочетание), закрыть сверку и передачу данных в учётную систему и только потом подключать инструмент.

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

Ниже — разбор этого процесса с точки зрения того, кто за него отвечает: из каких стадий он складывается, в каких местах ломается при росте объёма и какими инструментами закрывается каждая задача. Сервисы здесь приводятся как примеры под конкретный сценарий, а не как подборка с призовыми местами. У разных задач подходящие инструменты разные, и ранжировать их без привязки к задаче бессмысленно.

Из каких стадий складывается процесс выплат

Выплата конкретному исполнителю проходит четыре стадии, и каждая — это чей-то участок ответственности, а не строчка в платёжке. Разберём их по порядку.

Реестр исполнителей и их статусов. Основа всего — актуальный список тех, с кем компания работает, и статус каждого: самозанятый на НПД, индивидуальный предприниматель, физлицо без специального статуса, нерезидент. От статуса зависит весь дальнейший путь выплаты: какой документ нужно оформить и нужно ли удерживать НДФЛ. Пока список ведётся в таблице, за его актуальность отвечает конкретный человек — и именно здесь чаще всего накапливаются устаревшие данные.

Проверка налогового статуса. Перед выплатой самозанятому важно убедиться, что статус НПД действует именно сейчас, а не действовал в момент, когда исполнителя завели в базу. Это не формальность: если статус утрачен, а компания провела выплату как самозанятому, налоговые последствия лягут на неё.

Оформление закрывающих документов. Чек НПД, акт, УПД (универсальный передаточный документ) — конкретный вид зависит от статуса исполнителя. Логика «какой статус — такой документ» должна быть частью процесса, а не задачей, которую бухгалтер решает вручную после каждой выплаты.

Сверка с учётной системой. Данные о выплате и документе должны попасть в 1С или её аналог без ручного переноса. Если этого нет, рост числа выплат напрямую превращается в рост ручной работы: кто-то в бухгалтерии переносит суммы из одной системы в другую, и процесс упирается в его пропускную способность.

Здесь важно не смешивать две разные вещи. Речь про выплаты внештатным исполнителям-подрядчикам, а не про зарплату штатным сотрудникам. Основания разные — гражданско-правовой договор (ГПХ) вместо трудового, — а значит, разные документы и, как правило, разные системы. Зарплатный модуль не заточен под логику проверки статуса НПД, а инструмент для расчётов с подрядчиками обычно не считает отпускные и больничные. Попытка вести и то и другое в одном контуре обычно заканчивается тем, что часть операций всё равно ведётся руками.

Где процесс ломается при росте объёма

На небольших объёмах слабые места процесса незаметны. Они проявляются, когда исполнителей и выплат становится много, и почти всегда неожиданно для того, кто выстраивал схему с запасом, но проверял её на десятке подрядчиков.

Статус устаревает быстрее, чем его успевают перепроверить. Прямого открытого API «Мой налог» для бизнеса не существует: доступ к данным о статусе самозанятого дают только через статус партнёра ФНС — по такой модели к системе подключаются, например, платёжные сервисы, работающие с самозанятыми. На практике это значит, что проверку статуса компания либо получает как встроенную функцию сервиса-партнёра, либо выстраивает обходными путями, которые ненадёжны. И в любом случае проверять статус нужно максимально близко к моменту фактической выплаты: если реестр сформирован заранее, а деньги уходят через несколько дней, статус, зафиксированный при формировании списка, может уже не соответствовать действительности.

Годовой лимит НПД пересекается в середине месяца. Годовой лимит дохода для плательщика НПД — 2,4 млн ₽, отсчёт по календарному году. При превышении статус НПД в текущем году перестаёт применяться, а доходы сверх лимита облагаются НДФЛ на общих основаниях; при этом уже полученные ранее доходы задним числом не пересчитываются. Для процесса это означает вот что: если у исполнителя лимит заканчивается на середине месячного реестра, отменить уже оформленные по нему документы нельзя. Значит, остаток лимита нужно знать до отправки выплат, а не выяснять постфактум, когда часть денег уже ушла с неверным налоговым режимом. Для крупного постоянного подрядчика это не редкий пограничный случай, а предсказуемое событие, которое наступит в определённый момент года.

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

Ручные точки не масштабируются. Любой участок, где данные переносятся руками — бухгалтер копирует суммы между таблицами, менеджер проверяет статус самозанятого перед переводом, — работает, пока операций десятки. На сотнях он становится либо узким горлышком, либо источником ошибок. Именно эти точки, а не выбор конкретного сервиса, определяют, где автоматизация окупится быстрее всего.

Инструменты под разные задачи

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

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

Выплаты российским самозанятым

Здесь работают сервисы, оформленные как партнёры ФНС, — это и даёт встроенную проверку налогового статуса в том же контуре, где идёт выплата.

Консоль.Про описывает себя как официального партнёра ФНС по работе с самозанятыми и публикует открытый Tasks API вместе с модулем синхронизации с 1С — выгрузкой платёжных операций и актов в 1С Бухгалтерию, автосозданием профилей исполнителей в 1С ЗУП. Сервис закрывает сценарий, где выплата — финальный шаг в цепочке «задание → акт → выплата», выполняемый в одном контуре с постановкой и приёмкой самого задания. По описанию сервиса, работает он только внутри РФ, а публичной страницы с фиксированным тарифом нет — ставку уточняют напрямую.

Qugo тоже позиционируется как партнёр ФНС, проводит выплаты через СБП (Систему быстрых платежей) и добавляет автоматическую проверку статуса самозанятости перед каждой выплатой: если статус не подтверждён, платёж не проходит — то есть несовпадение отлавливается до того, как деньги ушли, а не постфактум. Чек НПД формируется автоматически в момент оплаты. Для массовых расчётов есть пакетный режим по реестру и отдельная интеграция с 1С. По данным сервиса, комиссия — 1–4,5% от оборота, ставка индивидуальная; кросс-бордер, как и у других РУ-рейлов, он не закрывает.

Рокет Ворк делает акцент на автоматизации налоговой части: по описанию сервиса, после расчёта с самозанятым он сам декларирует его доход в ФНС, выдаёт чек и переводит сумму налога НПД без ручного участия бухгалтерии. Интеграция с 1С ЗУП включает выгрузку банковских выписок, автосоздание актов и отчёта агента. Стандартная комиссия публично не раскрыта — на сайте указан промо-тариф первого месяца. Отдельный продукт сервиса для входящих трансграничных переводов решает другую задачу и выплаты зарубежным исполнителям не заменяет.

Solar Staff стоит особняком: он ориентирован на исполнителей в разных странах (по заявлению сервиса — 190+ стран) и вывод в разные платёжные инструменты — карты, SEPA/SWIFT, WebMoney, USDT, — плюс публикует документированное API с тестовым окружением. Но рублёвая часть выплат у него подчиняется тем же российским правилам: вывод на карты РФ ограничен суммой 600 000 ₽ в месяц, а с начала 2025 года сервис удерживает НДФЛ по прогрессивной ставке 13–22% при выводе на российские карты для исполнителей без статуса самозанятого или ИП. То есть даже с широкой международной географией домашние выплаты остаются в том же периметре, что и у трёх предыдущих сервисов.

Распределённая и зарубежная команда

Как только в реестре появляются исполнители за пределами российского налогового периметра, проверка статуса НПД становится неприменима, и задача меняется. Теперь на первом плане другое: оформить отношения с исполнителем и подготовить документы до того, как дело дойдёт до денег — договор, приёмку, комплаенс-документацию под юрисдикцию исполнителя. Это отдельный класс инструментов, и с РУ-рейлами он напрямую не конкурирует: они закрывают разные участки.

Один из инструментов этого класса — 4dev.com: по собственному описанию, это платформа для операционной работы с подрядчиками — оформление отношений, документы, верификация и workflow для контракторов в 150+ странах, с отчётностью, пригодной для аудита. Тарификация публикуется как процент от объёма (3% или ниже), без подписки и платы за аккаунт. Существенно понимать её границы: это не выплатной сервис, не EOR и не HRIS-система — сам перевод денег и его локальный налоговый режим остаются задачей другого слоя. И для сценария выплат российским самозанятым внутри периметра НПД сервис неприменим: заявленной интеграции с ФНС или «Мой налог» у него нет, в отличие от РУ-рейлов выше. К тому же публичные страницы не раскрывают конкретный список API-эндпоинтов, поэтому оценить глубину интеграционного слоя так же детально, как у сервисов с открытой документацией, не получится. Это честный компромисс: инструмент закрывает оформление и документооборот по распределённой части команды, но не заменяет платёжный контур.

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

Сводка по задачам

Как выстроить процесс: практический порядок

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

Шаг 1. Ревизия текущих потоков и статусов

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

Шаг 2. Выбор модели: разовые выплаты, реестр или сочетание

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

Шаг 3. Контроль дублей и сверка

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

Шаг 4. Передача данных в учётную систему

Здесь вопрос приоритета: что автоматизировать первым — оформление закрывающих документов или занесение данных в 1С. Если акты и чеки уже формируются нормально, а проводки заносят руками, начинать логичнее с проводок — эффект виден сразу. Если узкое место сами документы, приоритет обратный. Попытка закрыть оба участка одновременно на старте обычно означает, что ни один не доходит до рабочего состояния в разумный срок.

Шаг 5. Тестовый прогон и контрольные точки

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

Чек-лист

• Список исполнителей выгружен, статус каждого зафиксирован
• Найдены точки, где данные переносятся вручную
• Выбрана модель — разовые выплаты, реестр или сочетание
• Определено, как процесс защищён от двойных выплат
• Настроена сверка выплат с банковской выпиской
• Определён приоритет интеграции с учётной системой — документы или проводки
• Заданы контрольные точки: просроченный статус, остаток лимита, неподтверждённая выплата
• Разведены задачи по РУ-самозанятым и по зарубежным подрядчикам — под каждую свой инструмент

Частые вопросы

С чего начать, если выплаты исполнителям пока идут вручную?

Не с выбора сервиса, а с ревизии. Нужно понять, сколько исполнителей и в каких статусах, где данные переносятся руками и где статус проверяют на глаз. Эти точки и покажут, что автоматизировать в первую очередь. Инструмент, подключённый до ревизии, просто ускорит существующие ошибки.

Как проверяется налоговый статус самозанятого перед выплатой?

Прямого открытого API «Мой налог» для бизнеса нет — доступ к данным о статусе дают только через партнёрский статус ФНС, по модели, по которой подключаются платёжные сервисы, работающие с самозанятыми. На практике это значит, что встроенную проверку статуса компания получает вместе с сервисом-партнёром ФНС, а не строит сама. Проверять статус важно близко к моменту выплаты: между добавлением в базу и переводом исполнитель может сняться с учёта.

Что происходит, если исполнитель превышает лимит 2,4 млн ₽ в середине месяца?

Статус НПД в текущем году перестаёт применяться, а доход сверх лимита облагается НДФЛ; уже проведённые до этого момента выплаты задним числом не пересчитываются. Практическое следствие: остаток лимита нужно контролировать до отправки выплат, а не после. Для крупного постоянного подрядчика это предсказуемое событие, а не редкий пограничный случай.

Точечные выплаты или выплаты по реестру — что выбрать?

Ориентир — объём и регулярность. Для нескольких нерегулярных выплат в месяц проще точечный режим. Как только счёт идёт на сотни получателей за период, точечный режим упирается в лимиты и обходится дороже в поддержке, чем пакетный реестр. У большинства компаний в итоге сосуществуют оба.

Можно ли платить исполнителям в разных странах через один инструмент?

Как правило, нет — это две разные задачи. Выплаты российским самозанятым живут внутри периметра НПД, а для распределённой команды нужен отдельный слой оформления и документов, который готовит отношения с исполнителем до самой выплаты. Единого инструмента, одинаково хорошо закрывающего оба случая, среди распространённых на рынке нет, и наличие двух разных инструментов под две задачи — рабочая норма.

Как передавать данные о выплатах в 1С без ручной выгрузки?

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

Чем работа с внештатными исполнителями отличается от зарплаты штатным сотрудникам?

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