IT-компании нередко привлекают внешних разработчиков на несколько месяцев: backend- и frontend-разработчиков, QA-инженеров, аналитиков, DevOps-специалистов. Сотрудники числятся в другой организации, но работают над проектом заказчика, участвуют в его встречах, получают задачи и используют его инфраструктуру.
На практике такую модель часто называют аутстаффингом. Но для договора, бухгалтерского учета и налогов важнее другое: что именно происходит между сторонами фактически.
Одна компания может самостоятельно выполнять разработку для другой. А может временно предоставить своих сотрудников, которыми в дальнейшем управляет заказчик. Внешне эти схемы похожи, но юридическая конструкция и требования к оформлению у них разные.
Короткий ответ
Если специалисты другой организации временно выполняют свои трудовые функции в интересах IT-компании, а компания сама ими управляет и контролирует работу, такая схема может относиться к предоставлению труда работников. При этом договор о предоставлении труда работников сам является договором возмездного оказания услуг. Поэтому его нужно отличать не от «услуг вообще», а от обычных IT-услуг, при которых исполнитель самостоятельно организует работу своей команды.
Что в IT обычно называют аутстаффингом разработчиков
Термин «аутстаффинг разработчиков» широко используется в бизнесе, но Трудовой кодекс использует другую конструкцию — предоставление труда работников (персонала).
В этой модели разработчик не переходит в штат заказчика. Его работодателем остается направляющая организация. Но сотрудник временно выполняет свою трудовую функцию в интересах другой компании — принимающей стороны — под ее управлением и контролем.
Например, разработчик официально работает в компании А, а на шесть месяцев направлен в компанию Б. Компания Б включает его в проектную команду, ставит рабочие задачи и контролирует выполнение.
Поэтому при проверке договора на аутстаффинг разработчиков недостаточно посмотреть его название. Нужно сопоставить текст договора с тем, как специалисты работают на практике.
Предоставление персонала, подряд и обычные IT-услуги: как различить модели
Одна из распространенных ошибок — считать любой договор на внешнюю команду аутстаффингом. На практике нужно разделять как минимум три модели.
Кто фактически управляет разработчиком
Это один из главных практических вопросов.
Представим две ситуации.
В первой заказчик передает компании-исполнителю задачу по доработке модуля. Исполнитель сам решает, какой специалист займется backend, кто будет тестировать релиз, как распределить время команды и кто заменит разработчика в случае его отсутствия. Заказчик взаимодействует с ответственным лицом исполнителя.
Такая модель больше похожа на самостоятельный подряд или оказание IT-услуг.
Во второй ситуации заказчик получает трех конкретных специалистов. Его тимлид ежедневно распределяет между ними задачи, определяет приоритеты, контролирует выполнение и включает сотрудников исполнителя в обычный рабочий процесс своей команды.
Здесь уже появляются характерные признаки предоставления труда работников: внешние сотрудники выполняют трудовые функции в интересах, под управлением и контролем принимающей стороны.
Сам по себе расчет по часам еще не определяет модель. Важна совокупность фактических обстоятельств.
Почему нельзя просто «передать разработчиков» другой компании
Трудовое законодательство устанавливает ограничения для заемного труда. Одновременно ТК РФ предусматривает специальную регулируемую конструкцию временного предоставления труда работников.
Поэтому схема вида «у нас есть сотрудники, мы просто передадим их заказчику, а он будет ими руководить» требует отдельной юридической проверки.
Кто вправе предоставлять труд работников
ТК РФ предусматривает такую возможность прежде всего для частных агентств занятости, прошедших аккредитацию.
Помимо аккредитованных ЧАЗ, ТК РФ предусматривает отдельные случаи направления работников между юридическими лицами, например при определенных отношениях аффилированности. Это специальная конструкция со своими условиями, а не общее право любой компании предоставлять персонал.
Поэтому перед заключением договора важно проверить не только его содержание, но и основание, на котором контрагент использует такую модель.
Когда частное агентство занятости может направить разработчиков
Для ЧАЗ закон предусматривает конкретные основания.
Например, работника можно временно направить для исполнения обязанностей отсутствующего сотрудника, за которым сохраняется место работы.
Другое основание — заведомо временное расширение производства или объема оказываемых услуг. Для этого случая установлен срок до 18 месяцев.
Важно
18 месяцев нельзя автоматически считать общим сроком любого аутстаффинга. Предел установлен именно для конкретного основания — временного расширения деятельности.
Для IT-компании такая ситуация может возникнуть, например, когда на определенный период резко увеличился объем разработки и требуется временно расширить команду. Но само наличие проекта на год еще не означает, что любую схему предоставления сотрудников можно оформить по этому основанию: нужно анализировать обстоятельства конкретной работы.
Зачем проверять аккредитацию частного агентства занятости
Если поставщик предлагает «аутстаффинг IT-разработчиков», первое, что стоит проверить, — на каком основании он предоставляет персонал.
Для частного агентства занятости право осуществлять такую деятельность связано с аккредитацией.
До подписания договора заказчику имеет смысл установить:
- кто является работодателем разработчиков;
- вправе ли контрагент применять выбранную модель;
- на каком основании сотрудники направляются к заказчику;
- на какой срок;
- действует ли аккредитация ЧАЗ, если она требуется.
Маркетинговой фразы «предоставляем разработчиков в вашу команду» на сайте поставщика для этого недостаточно.
Что должно быть в договоре на предоставление разработчиков
Хороший договор должен описывать не абстрактные «IT-услуги», а фактическую схему взаимодействия сторон.
Предмет договора
В договоре о предоставлении труда работников определяются условия, порядок и срок предоставления персонала, перечень должностей и численность направляемых сотрудников.
Также важно, чтобы из договора и связанных с ним документов было понятно, какие функции фактически выполняют специалисты и кто является принимающей стороной.
Отдельно для такой модели имеет значение обязанность принимающей стороны обеспечивать безопасные условия и охрану труда.
Проверьте формулировку договора
Если в документе написано только «Исполнитель оказывает услуги по разработке программного обеспечения», а фактически заказчик получает пять конкретных разработчиков и сам управляет каждым из них, договорная конструкция требует проверки.
Срок и порядок предоставления команды
Полезно заранее определить, когда специалист подключается к проекту, на какой период, как происходит его замена и как стороны оформляют изменение состава команды.
Если один backend-разработчик заменяется другим, это не должно оставаться только в переписке менеджеров.
Кто управляет разработчиками
В договоре и приложениях должна быть отражена реальная модель.
Если предполагается предоставление труда работников, нужно понимать, какие рабочие указания вправе давать принимающая сторона и в пределах какой трудовой функции.
Если же исполнитель по договору должен самостоятельно оказывать IT-услугу, но фактически каждый разработчик напрямую встроен в структуру заказчика, появляется расхождение между договором и реальными отношениями.
Стоимость и расчеты
Порядок расчета должен позволять проверить итоговую сумму.
- стоимость одного часа специалиста × подтвержденное количество часов за месяц;
- фиксированная стоимость предоставления определенного состава команды за отчетный период.
Чем сложнее формула цены, тем важнее связать ее с документами за период.
Какие документы нужны при предоставлении разработчиков
Один договор между двумя организациями не описывает всю модель. Документы условно можно разделить на кадровые и расчетные.
Документы, связанные с направлением работника
Для направляемого работника соответствующая модель должна быть отражена в трудовом договоре.
При направлении сотрудника частным агентством занятости к конкретной принимающей стороне оформляется дополнительное соглашение, в котором фиксируется информация о принимающей стороне и договоре о предоставлении персонала.
Для заказчика это означает простой практический вывод: наличие коммерческого договора между компаниями еще не подтверждает, что кадровая сторона модели оформлена корректно.
Задания и информация о работе команды
Задания могут использоваться для подтверждения того, над каким проектом и в каком периоде работали специалисты.
Например, документ или информационная система может связывать специалиста, проект, период и выполняемую задачу.
Но отдельный документ с названием «задание разработчику» не является универсально обязательным для каждой схемы. Комплект подтверждающих документов зависит от условий договора и реального порядка работы.
Таймшиты разработчиков
Таймшит особенно полезен, когда стоимость услуг зависит от количества фактически учтенных часов.
Обычно в нем отражают специалиста, проект, отчетный период, количество часов и краткое содержание выполненной работы.
При этом законодательство не устанавливает для аутстаффинга универсальную обязательную форму первичного документа именно под названием «таймшит».
Поэтому важнее не название, а его функция: документ должен помогать подтвердить объем, на основании которого рассчитана стоимость.
Если стороны используют таймшиты разработчиков, форму, периодичность и порядок согласования лучше закрепить в договоре или приложении.
Акт или другой первичный документ
То же относится к акту.
Для бухгалтерского учета важен не документ с конкретным названием, а корректно оформленный первичный документ, отражающий факт хозяйственной жизни.
Такой документ должен содержать обязательные реквизиты, установленные Законом о бухгалтерском учете, в том числе:
- наименование документа;
- дату составления;
- наименование экономического субъекта;
- содержание факта хозяйственной жизни;
- натуральный и/или денежный измеритель;
- сведения об ответственных лицах;
- их подписи или иные предусмотренные реквизиты идентификации.
Поэтому схема может завершаться актом за месяц или другим предусмотренным документооборотом сторон первичным документом.
Главный ориентир
Из комплекта документов должно быть понятно: за какой период возникла операция, какой объем предоставлен и как получилась сумма к оплате
Как связать договор, таймшиты и первичные документы
Удобнее всего проверять документооборот как единую цепочку:
Документальная цепочка
Договор → заявка или приложение → состав специалистов → учет объема или времени → первичный документ → сумма к оплате.
Например, компания получила трех специалистов.
В договоре определены должности и порядок расчета. В приложении указан состав команды. В таймшитах за сентябрь отражены часы. В первичном документе указана стоимость услуг за тот же период.
В такой ситуации бухгалтер может проследить расчет.
Риск выше, когда документы существуют отдельно друг от друга: в договоре — «разработка ПО»; в счете — «услуги за сентябрь»; в акте — одна строка без расшифровки; в реальности — пять разработчиков, стоимость которых рассчитана по индивидуальным часовым ставкам.
Чем сложнее операция, тем подробнее должна быть доказуемая связь между условиями договора и расчетом.
Как учитывать расходы на предоставление разработчиков
Налог на прибыль
Для налога на прибыль НК РФ отдельно называет расходы на услуги по предоставлению труда работников сторонними организациями для участия в производственной деятельности, управлении производством и выполнении других функций, связанных с производством или реализацией.
Но наличие такой нормы не означает, что любую сумму по договору с названием «аутстаффинг» можно автоматически включить в расходы.
Сохраняются общие требования к признанию расходов: они должны быть экономически обоснованы и документально подтверждены.
Для IT-компании важно показать, зачем привлекалась команда и какими документами подтверждается операция.
Например, привлечение дополнительных разработчиков для коммерческого проекта обычно легче объяснить, если из договора и первички видно, какие специалисты работали в соответствующий период и как рассчитана стоимость.
УСН «доходы минус расходы»
Здесь особенно важно использовать актуальные правила 2026 года.
С 2026 года статья 346.16 НК РФ позволяет учитывать также иные расходы, определяемые в порядке главы 25 НК РФ.
Поэтому старый подход «расхода нет в закрытом перечне УСН — значит учитывать его нельзя» уже нельзя механически применять без проверки действующей редакции НК РФ.
При этом нужно проверить не только соответствие расхода правилам главы 25 НК РФ и требованиям к его документальному подтверждению, но и порядок признания затрат при УСН.
В общем случае расходы при УСН признаются после их фактической оплаты.
Поэтому для конкретной операции нужно одновременно проверить:
- может ли расход учитываться по правилам главы 25 НК РФ;
- подтвержден ли он документами;
- связан ли с деятельностью, направленной на получение дохода;
- выполнены ли условия признания расхода для УСН.
То есть ответ «расходы на аутстаффинг всегда принимаются при УСН» будет таким же неправильным, как и универсальный ответ «никогда не принимаются».
Какие документы подтверждают расходы
Для налогового учета лучше не ограничиваться только договором, счетом и платежным поручением.
Комплект документов должен объяснять реальную операцию: кто предоставил специалистов, на каком основании, в какой период они работали, как определялся объем услуг и каким образом рассчитана стоимость.
Рассмотрим пример.
В договоре предмет сформулирован как «разработка программного продукта».
В актах ежемесячно появляется одна строка: «IT-услуги».
При этом в таск-трекере видно, что три сотрудника исполнителя ежедневно получают персональные задачи от руководителя заказчика, а стоимость рассчитывается как количество часов каждого разработчика, умноженное на его ставку.
Такая ситуация не означает автоматически, что расходы будут исключены из налоговой базы. Но она показывает явное расхождение между документами и фактической моделью работы. Именно его стоит устранить до проверки, а не объяснять задним числом.
Основные риски аутстаффинга IT-команды
Удобно разделить их на три группы.
Трудовой риск
Первый вопрос — вправе ли контрагент вообще предоставлять сотрудников по выбранной модели.
Далее проверяются основание направления, срок, кадровые документы и соответствие фактически выполняемой работы трудовой функции.
Договорный риск
Типичный пример: договор описывает самостоятельную разработку силами подрядчика, а в реальности подрядчик лишь предоставляет отдельных специалистов, которыми руководит заказчик.
Название «договор разработки» не отменяет реальный порядок взаимодействия.
Налоговый риск
Он возникает не из-за самого слова «аутстаффинг».
Для налоговой оценки имеет значение совокупность обстоятельств.
Само по себе неудачное название договора или отдельный недостаток документа не означает автоматического отказа в расходах. Но существенное расхождение между документами и реальной операцией повышает риск претензий.
Особенно важно, чтобы компания могла:
- подтвердить реальность операции;
- объяснить расчет цены;
- связать первичные документы с договором;
- показать деловую цель расходов;
- подтвердить, что сведения об операции не искажены.
Поэтому проверять нужно не отдельный акт или формулировку договора, а всю фактическую картину.
Ответственность принимающей стороны: о чем часто забывают заказчики
Аутстаффинг нельзя воспринимать только как покупку часов внешних разработчиков.
При модели предоставления труда работников закон распределяет отдельные обязанности и риски между направляющей и принимающей сторонами.
Например, ТК РФ предусматривает специальные обязанности принимающей стороны, связанные с организацией работы направленных сотрудников и безопасными условиями труда.
В отдельных случаях принимающая сторона также несет субсидиарную ответственность по обязательствам работодателя перед направленными работниками, в том числе по заработной плате и другим причитающимся выплатам
Важно для заказчика
Перед подключением команды стоит проверять не только стоимость специалиста, но и юридическую конструкцию в целом.
Пример: как определить модель работы команды
Допустим, компании на шесть месяцев нужны backend-разработчик, frontend-разработчик и QA-инженер.
Вариант 1. Исполнитель сам управляет командой
Заказчик ставит задачу ответственному менеджеру исполнителя.
Исполнитель самостоятельно распределяет задачи, определяет загрузку специалистов, организует их взаимодействие и контролирует выполнение.
Заказчик получает предусмотренную договором услугу или результат.
В такой ситуации отношения больше похожи на самостоятельный подряд или обычные IT-услуги.
Вариант 2. Специалисты встроены в команду заказчика
Те же три специалиста получают задачи непосредственно от тимлида заказчика.
Они участвуют в ежедневных встречах его команды, заказчик определяет приоритеты и контролирует работу каждого разработчика.
При этом внешний подрядчик фактически отвечает прежде всего за предоставление специалистов.
Такую модель уже необходимо проверять с точки зрения правил о предоставлении труда работников.
Главное отличие
Разница между примерами — не в технологии разработки и не в способе оплаты. Важно, кто реально организует и контролирует труд специалистов.
Чек-лист перед подписанием договора
- Кто является работодателем разработчиков?
- Кто ежедневно ставит специалистам задачи?
- Кто контролирует их выполнение?
- Компания покупает самостоятельную IT-услугу или получает труд конкретных работников?
- Вправе ли поставщик предоставлять персонал по выбранной модели?
- Нужна ли ему аккредитация ЧАЗ и действует ли она?
- На каком основании и на какой срок направляются сотрудники?
- Совпадают ли должности и трудовые функции с реальными задачами?
- Понятно ли из договора, как рассчитывается стоимость?
- Какими документами подтверждается объем услуг?
- Можно ли связать договор, приложение, таймшит и первичный документ?
- Соответствует ли оформленная договорная модель реальной работе команды?
Если на несколько вопросов нет однозначного ответа, модель лучше проверить до подписания договора.
Когда договорную модель стоит проверить заранее
Проверка особенно полезна, если поставщик предлагает не абстрактную услугу разработки, а конкретных специалистов или выделенную команду.
Например, разработчики должны полностью войти в процессы заказчика, получать задания от его руководителей, работать по его приоритетам, а стоимость рассчитывается по времени каждого человека.
Еще один сигнал — документы не совпадают с реальностью: в договоре указана разработка продукта, фактически предоставляется персонал, а бухгалтеру передают только общий ежемесячный акт.
Чем раньше выявлено такое расхождение, тем проще привести в соответствие договор, кадровую часть и первичные документы.
Следующий шаг
Специалисты «Контакт Плюс» могут проверить, соответствует ли договор фактической схеме работы IT-команды, как распределены функции сторон, какими документами подтверждается операция и где возникают юридические и налоговые риски.
Проверить договорную модель
Частые вопросы
Можно ли оформить аутстаффинг разработчиков обычным договором оказания услуг?
Договор о предоставлении труда работников сам относится к договорам возмездного оказания услуг. Но к нему применяются специальные правила трудового законодательства. Поэтому просто назвать документ «договором оказания услуг» недостаточно: нужно проверить его содержание и фактическую модель взаимодействия сторон.
Всегда ли компании, предоставляющей разработчиков, нужна аккредитация ЧАЗ?
Нет. ТК РФ предусматривает отдельные специальные случаи, когда работников могут направлять и другие юридические лица. Но это не означает, что любая компания может свободно предоставлять своих сотрудников третьему лицу. Необходимо определить конкретное правовое основание модели.
Кто должен ставить задачи разработчикам при предоставлении персонала?
Сама конструкция предоставления труда предполагает выполнение трудовых функций в интересах, под управлением и контролем принимающей стороны. При этом рабочие задания должны находиться в пределах трудовой функции работника.
Обязательны ли таймшиты разработчиков?
Универсальной обязательной формы документа именно с названием «таймшит» для такой модели нет. Но если стоимость зависит от количества часов, таймшит или аналогичный документ помогает подтвердить объем и расчет стоимости.
Обязательно ли оформлять ежемесячный акт?
Не обязательно исходить именно из названия «акт». Для бухгалтерского учета важно корректно оформить первичный документ, содержащий обязательные реквизиты и позволяющий подтвердить содержание хозяйственной операции. Конкретный документооборот зависит от условий договора.
Можно ли учесть расходы на предоставление разработчиков при УСН?
С 2026 года статья 346.16 НК РФ позволяет учитывать также иные расходы, определяемые в порядке главы 25 НК РФ. Но возможность признать конкретные затраты нужно оценивать с учетом действующих налоговых требований, документального подтверждения и порядка признания расходов при УСН. В общем случае такие расходы учитываются после фактической оплаты.
Что опаснее: неправильное название договора или несоответствие документов реальной работе?
Обычно больший риск создает именно расхождение между документами и фактической моделью. Если договор описывает самостоятельную услугу исполнителя, а на практике заказчик получает отдельных работников и непосредственно ими управляет, само название договора проблему не решает. Поэтому нужно проверять всю цепочку: кто управляет командой → на каком основании она предоставлена → как оформлены отношения → чем подтверждается операция → как учитываются расходы.
