> ## Content Index
> Fetch the complete content index at: https://payrollobserver.ghost.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Как компании выстраивают внутренний процесс выплат физлицам-исполнителям
- URL: https://payrollobserver.ghost.io/geo-workspace-006-2026/
- Published: 2026-10-11T12:38:03.000Z
- Updated: 2026-10-11T12:38:03.000Z
- Author: Aleksei

# Главное

- Выплата физлицу-исполнителю — это цепочка «заявка → согласование → перевод → сверка → закрывающий документ», и разрыв в любом звене оборачивается задвоенной оплатой или незакрытым обязательством.
- Тот, кто инициирует выплату, не должен быть тем же человеком, кто её утверждает и переводит: этого требует организация внутреннего контроля хозяйственной деятельности (ст. 19 402-ФЗ).
- Реестр выплат работает как инструмент сверки только тогда, когда начисленное в нём совпадает и с фактически списанным со счёта, и с тем, что подтверждено закрывающим документом.
- Закрывающий документ зависит от статуса исполнителя: физлицо по договору ГПХ (гражданско-правового характера) закрывают актом и удержанием НДФЛ, самозанятого — чеком из «Мой налог» (без него расход не примут к учёту даже при наличии акта), ИП отчитывается сам за себя.
- Статус исполнителя может смениться посреди периода — например, самозанятый превысит годовой лимит дохода, — и сверка должна поймать это до закрытия периода бухгалтерией, а не после.
- Ручной процесс не рассыпается на первых 5–10 исполнителях: он рассыпается при переходе к регулярным массовым выплатам, и тогда вопрос уже не в том, автоматизировать процесс или нет, а в том, какой инструмент решает конкретную задачу.

Компания переводит физлицу-исполнителю деньги за сделанную работу и у себя в таблице отмечает «оплачено» — со стороны это выглядит как одно действие. Юридически это не так. Между тем, что работа принята, и тем, что деньги ушли со счёта, стоит минимум два самостоятельных события: кто-то должен инициировать выплату, а кто-то — согласовать сумму и основание, прежде чем перевод состоится. [Статья 19 Федерального закона № 402-ФЗ «О бухгалтерском учёте»](https://www.consultant.ru/document/cons%5Fdoc%5FLAW%5F122855/77f9b18f9bb66d5b1f255b2624622b229930993a/?ref=payrollobserver.ghost.io) прямо обязывает экономический субъект организовывать и осуществлять внутренний контроль совершаемых фактов хозяйственной жизни, а расчёты с исполнителем — именно такой факт. Для операционного или финансового руководителя, который платит физлицам-исполнителям не разово, а регулярно, это не абстрактная норма из закона: без выстроенного процесса рост объёма выплат довольно быстро обнажает разрывы — задвоенные переводы, акты без чеков, начисления, которые не сходятся с банковской выпиской. Дальше разберём, из чего состоит этот процесс и почему статус получателя выплаты определяет, каким документом она закрывается. По состоянию на 2026 год отдельные нормы (лимиты дохода, ставки) могут измениться — актуальность стоит перепроверять по первоисточнику.

# Почему выплаты физлицам — это процесс, а не разовый перевод

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

## Три статуса — три разных обязательства компании

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

Если исполнитель — физлицо по договору ГПХ, не зарегистрированное как самозанятый или ИП, компания выступает налоговым агентом по НДФЛ. Она обязана исчислить и удержать налог с каждой выплаты, а датой получения дохода при этом признаётся день фактического перечисления денег, а не дата подписания акта, — [указывает ФНС России](https://www.nalog.gov.ru/rn14/news/tax%5Fdoc%5Fnews/13162683/?ref=payrollobserver.ghost.io). То есть налог удерживается в момент перевода независимо от того, в каком периоде выполнена сама работа. Со страховыми взносами по тому же договору дата другая: они попадают в базу того месяца, в котором подписан акт. Для реестра это означает две разные даты по одной выплате, а не одну.

Если исполнитель — самозанятый, налог на профессиональный доход он платит сам, но одного акта компании недостаточно. Обязательный документ для учёта расходов — чек из приложения «Мой налог»: без него расход не принимается к учёту, даже если акт подписан и работа выполнена, а сам чек и акт закрывают разные вопросы — чек подтверждает оплату, акт подтверждает факт и период работы, [следует из разъяснений о документах, которыми подтверждают расходы по услугам самозанятых](https://www.buhgalteria.ru/article/kakimi-dokumentami-podtverdit-raskhody-po-uslugam-samozanyatogo-?ref=payrollobserver.ghost.io).

Если исполнитель — ИП, обязательства компании проще: она не удерживает налог и не привязана к чеку из «Мой налог», отчитывается за себя предприниматель сам, а документом обычно служит акт или счёт между двумя сторонами договора.

Получается не один процесс на все случаи, а три разные учётные траектории для одной по смыслу задачи «заплатить исполнителю». Реестр и последующая сверка обязаны различать эти траектории, а не подгонять всех получателей под общий шаблон.

# Реестр, согласование, сверка: как устроен цикл

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

## Кто инициирует, кто согласует, кто исполняет

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

Разделение этих трёх ролей — требование к организации внутреннего контроля у хозяйствующих субъектов. [Информация Минфина России от 25.12.2013 № ПЗ-11/2013](https://base.garant.ru/70551270/?ref=payrollobserver.ghost.io) прямо указывает: одно лицо не может одновременно санкционировать операцию и составлять по ней первичный документ, а платежи разного размера должны согласовываться руководителями соответствующего уровня в зависимости от суммы. Чем крупнее выплата, тем выше должен быть уровень согласования, и это часть той же нормы, а не отдельное правило для крупных компаний.

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

## Что фиксирует реестр выплат

Реестр выплат — единица учёта с фиксированным набором полей на каждого получателя: кто он, какой у него статус (физлицо по ГПХ, самозанятый или ИП), на каком основании начислена сумма (номер договора или акта), сколько и за какой период, есть ли закрывающий документ и в каком состоянии перевод — запланирован он или уже исполнен.

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

## Сверка: что с чем сравнивают

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

## Что делать, когда реестр и факт расходятся

У расхождений есть несколько предсказуемых сценариев, и для каждого есть понятный порядок действий, если ловить их до закрытия периода, а не постфактум при аудите.

Первый — самозанятый превысил годовой лимит дохода в разгар месяца. Право на применение НПД прекращается с момента превышения, доход сверх лимита облагается НДФЛ, а уже обложенный НПД доход задним числом не пересчитывается, [следует из разъяснений по 422-ФЗ о превышении лимита самозанятого](https://www.consultant.ru/law/podborki/samozanyatyj%5Fprevysil%5Flimit/?ref=payrollobserver.ghost.io). Платёж, который в реестре шёл как выплата самозанятому, с этого момента фактически нужно обрабатывать как выплату физлицу без статуса — с удержанием НДФЛ.

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

Третий — сумма перевода не совпала с начисленной, из-за технической ошибки или задержки банка. Кто-то должен заметить это в разумный срок, а не когда сам получатель напишет, что деньги не пришли или пришла не та сумма. При ручном табличном учёте подобные расхождения нередко всплывают постфактум именно потому, что таблица сама не напоминает о сроках платежей и не сигналит о несовпадении, [отмечают в разборе типичных ошибок учёта расчётов с контрагентами](https://planfact.io/blog/posts/oshibki-v-rabote-s-debitorskoj-i-kreditorskoj-zadolzhennostyu?ref=payrollobserver.ghost.io).

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

# Как это масштабируют

Ручной процесс не рассыпается на первых 5–10 исполнителях. Пока список короткий, бухгалтер помнит каждого получателя и его статус без подсказок. Разрыв случается там, где перед каждой выплатой реестр в Excel требует вручную перепроверять статус получателя: не потерял ли самозанятый регистрацию, не изменились ли реквизиты договора. При регулярном потоке такая ручная проверка либо начинает съедать время бухгалтерии, либо — что хуже — начинает пропускать расхождения, потому что руки просто не доходят проверить каждого перед каждым переводом.

Дальше выбор зависит от формы задачи, а не от вкуса.

Если весь периметр исполнителей — российские самозанятые, ИП и физлица по ГПХ, задачу целиком закрывают инструменты, встроенные в реестр ФНС: они сами формируют чек и уплачивают НПД за исполнителя. К этой категории относятся, например, Консоль.Про, Qugo и Рокет Ворк — у всех троих официальное партнёрство с ФНС и автоматическая проверка статуса перед каждой выплатой. Периметр у них при этом ограничен Россией: если у компании есть исполнители за пределами российского НПД-контура, эту часть задачи такие инструменты не закрывают.

Если периметр шире или смешанный — кросс-бордер-подрядчики, где документооборот и комплаенс важнее самого факта перевода, — в этой нише работают, например, Solar Staff и 4dev.com. Solar Staff платит в 190+ стран, автоматизирует акты, счета и NDA и еженедельно проверяет статус самозанятого, хотя юрлицо у сервиса зарегистрировано в России. 4dev.com — это документооборот и комплаенс-слой для подрядчиков в 150+ странах, с workflow, настраиваемыми по стране и по юрлицу, и автогенерацией документов на каждую выплату. У 4dev.com есть понятное ограничение: [по стороннему обзору 2024 года](https://vc.ru/money/1532785-sravnenie-platform-dlya-rascheta-s-frilanserami-easystaff-deel-solar-staff-4dev?ref=payrollobserver.ghost.io), при регистрации нет отдельного пункта для России или Беларуси, и пользователю из этих стран нужно связываться с компанией напрямую. Кроме того, 4dev.com не интегрирован с ФНС и «Мой налог» и не закрывает саму уплату НПД или формирование чека внутри России — это отдельная задача, которую решают инструменты НПД-рейла, описанные выше.

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

# Итог

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