Налоговый режим покупки программного обеспечения определяется не тем, российский продукт или иностранный, а тремя вещами: что именно вы приобретаете по договору — право пользования, экземпляр или услугу; включён ли продукт в реестр отечественного ПО; и насколько подробно расписаны закрывающие документы. Все три задаются до подписания и после исполнения договора почти не меняются. Поэтому вопрос «попадаем ли мы под льготный режим» надо задавать бухгалтеру на стадии коммерческого предложения, а не в декабре при закрытии года.
Вторая половина ответа менее приятная. В типовом проекте автоматизации на льготный режим по продукту из реестра претендует меньшая часть суммы — та, которая относится к передаче прав на программу. Всё остальное — работы по внедрению, доработка под ваши процессы, обучение, поддержка — это услуги, и правила у них свои. В модельном расчёте ниже это 19,5 % бюджета против 80,5 %. Понимание этой пропорции сразу снимает половину ожиданий и экономит недели переговоров о том, как бы записать весь проект лицензией.
Границы компетенции обозначим сразу. Мы подрядчик по автоматизации, а не налоговый консультант. Что мы можем — собрать договор и акт так, чтобы бухгалтеру было с чем работать: разделить статьи, показать цепочку прав, приложить подтверждение статуса продукта. Чего мы не делаем — не называем ставки, не толкуем нормы и не обещаем режим. Ставки, действующие редакции и применимость к вашей системе налогообложения — это к вашему бухгалтеру, на дату операции.
Три переключателя, от которых зависит режим
Полезно представлять налоговую сторону проекта как пульт с тремя тумблерами. Каждый ставится один раз — в момент, когда стороны договариваются о предмете договора и о том, как будут закрываться работы. Дальше пульт опечатывается: переставить тумблер задним числом можно только с согласия второй стороны и с новыми документами.
| Что решает режим | Варианты | Почему это трудно поправить потом |
|---|---|---|
| Предмет договора | Право пользования по лицензионному или сублицензионному договору · экземпляр или товар по договору поставки · работы и услуги по договору подряда либо возмездного оказания услуг | Предмет — существенное условие договора. Изменить его после исполнения можно только новым соглашением сторон, а вторая сторона не обязана его подписывать |
| Статус продукта | Включён в реестр отечественного ПО · не включён · правообладатель в реестре, а нужная редакция или модуль — отдельный продукт | Запись проверяется на дату сделки. Если между подписанием и оплатой в реестре что-то изменилось, вопрос перестаёт быть техническим и уходит к бухгалтеру |
| Детализация закрывающих документов | Одна строка «услуги по автоматизации» на всю сумму · разбивка по статьям с суммами и ссылками на пункты договора | Акт подписан обеими сторонами и лежит в бухгалтериях обеих. Переподписание — отдельные переговоры, и подрядчик на них идёт по доброй воле |
Есть и четвёртая вещь, которая всплывает реже, но ломает всё разом, — цепочка передачи прав. Если лицензию вы покупаете не у правообладателя, а у партнёра, в документах должна быть видна непрерывная цепочка: правообладатель дал право партнёру, партнёр передал его вам, объём переданных прав и срок совпадают. Разрыв в этой цепочке обнаруживается обычно не бухгалтерией, а много позже и в неудобный момент.
Схема-пульт с тремя переключателями, расположенными вертикально. Первый — «Предмет договора» с тремя положениями: «право пользования», «экземпляр», «работы и услуги». Второй — «Статус продукта» с двумя положениями: «в реестре», «не в реестре». Третий — «Документы» с двумя положениями: «одна строка на всю сумму», «разбивка по статьям». От пульта вправо идёт стрелка к блоку «Налоговый режим проекта», подпись на стрелке: «решает бухгалтер по действующей редакции». Слева вертикальная линия времени с двумя метками: «до подписания — тумблеры свободны» и «после акта — опечатано». Чертёжный стиль, подписи по-русски.
Один продукт, два договора, разный результат
Возьмём одну и ту же покупку — CRM на 25 пользователей с настройкой под отдел продаж и обменом с 1С:УТ. Сумма в обоих случаях одинаковая. Различается только то, как она оформлена.
- 1Вариант А: три предмета, три документа
Лицензионный договор с правообладателем на 285 000 ₽ — право пользования на 25 рабочих мест сроком на год. Договор на внедрение с подрядчиком на 875 000 ₽ — настройка, доработка обмена, обучение, с приложением-сметой по статьям. Договор поддержки на 300 000 ₽ — 12 месяцев по 25 000 ₽. У бухгалтера три разных объекта с разной природой, и к каждому он применяет свои правила, не выясняя ничего дополнительно.
- 2Вариант Б: один договор, одна строка
Единый договор «на комплексные услуги по автоматизации» на 1 460 000 ₽ и акт с одной строкой на всю сумму. Формально всё закрыто. Фактически бухгалтер видит одну услугу, не видит ни передачи прав, ни срока лицензии, ни состава работ — и вынужден либо запрашивать расшифровку, либо признавать всю сумму как одну услугу, теряя всё, что можно было применить к лицензионной части.
Разница между вариантами не в хитрости, а в дисциплине. Вариант А не стоит подрядчику ничего, если он заложен в договор с самого начала: смету мы всё равно считаем по статьям — именно так устроены наши бюджеты проектов. Вариант Б возникает не из злого умысла, а из желания «не усложнять» на этапе подписания. Усложнение просто переносится на полгода вперёд и достаётся вашей бухгалтерии.
Смета проекта по статьям: где здесь лицензия
Ниже модельный расчёт для компании на 60 человек: CRM на 25 пользователей, перенос базы клиентов, обмен заказами и остатками с 1С:УТ, обучение и год поддержки. Цифры взяты как типовые для проекта такого размера, а не как прайс.
Доля лицензий около пятой части — не исключение, а норма для проекта, где систему не просто ставят, а связывают с учётом. Чем больше в проекте интеграций и доработок, тем ниже эта доля: на проектах с двумя-тремя обменами она опускается до десяти процентов и ниже. Отсюда практический вывод, который экономит больше всего времени: спорить о структуре имеет смысл ради лицензионной части, а не ради всей сметы, и выигрыш ограничен сверху этими 285 000 ₽.
Горизонтальная составная полоса общей длиной 1 460 000 ₽, разбитая на пять сегментов с подписанными суммами: «Лицензии — 285 000 ₽», «Внедрение — 540 000 ₽», «Доработка — 260 000 ₽», «Обучение — 75 000 ₽», «Поддержка 12 мес. — 300 000 ₽». Сегмент лицензий выделен контуром и подписан снизу «19,5 % бюджета». Остальные четыре сегмента охвачены общей скобкой с подписью «1 175 000 ₽ — работы и услуги». Ось в рублях, единицы подписаны. Чертёжный стиль, подписи по-русски.
Как выглядит акт, к которому нет вопросов
Акт — это документ, который проживёт дольше, чем память всех участников проекта. Через два года на него будет смотреть человек, не присутствовавший ни на одной встрече. Хороший акт объясняет себя сам.
| Формулировка в акте | Что видит бухгалтер | Что ему придётся делать |
|---|---|---|
| «Услуги по автоматизации бизнес-процессов — 1 460 000 ₽» | Одну услугу на всю сумму, без состава и без сроков | Запрашивать расшифровку у подрядчика, сверять её с договором, писать бухгалтерскую справку — и всё равно объяснять состав, если состав спросят |
| Пять строк с суммами и ссылками на пункты договора и приложения | Пять объектов с разной природой и понятной суммой у каждого | Разнести по регистрам и приложить документы, которые уже лежат в том же комплекте |
| «Лицензия — 285 000 ₽» без указания срока и числа рабочих мест | Сумму без периода и без объёма прав | Уточнять срок и количество пользователей отдельным письмом и надеяться, что письмо найдётся через два года |
Со стороны подрядчика детализация не стоит ничего, если она заложена в договор с самого начала: состав работ мы всё равно считаем построчно, чтобы назвать цену. Она стоит денег только тогда, когда её требуют задним числом по закрытому проекту.
Цена вопроса, заданного поздно
Типичная ситуация: проект сдан весной, документы подписаны одной строкой, в декабре бухгалтерия закрывает год и просит расшифровку. Дальше начинается работа, которой могло не быть.
Тот же самый вопрос, заданный до подписания, стоит сорока минут разговора: вы пересылаете бухгалтеру проект договора и смету, он отвечает, что хочет видеть в акте. Разница между сорока минутами и 26 400 ₽ — это и есть вся практическая ценность темы. Дальше добавляется риск, который деньгами не измеряется: подрядчик может уже не работать с вами, может отказаться менять закрытые документы, а может согласиться, но не найти людей, которые помнят детали проекта.
Горизонтальная лента времени с четырьмя отметками слева направо и растущей вверх ступенчатой линией цены. Отметка 1 — «На стадии коммерческого предложения», подпись «0 ₽, 40 минут разговора». Отметка 2 — «До подписания договора», подпись «0 ₽, правка в приложении». Отметка 3 — «При закрытии года», подпись «26 400 ₽, 22 часа, 2–3 недели». Отметка 4 — «При налоговой проверке», подпись «дороже и не всегда решаемо». Между отметками 2 и 3 вертикальная черта с надписью «акт подписан обеими сторонами». Чертёжный стиль, подписи по-русски.
Шесть вопросов бухгалтеру до подписания
Все шесть — про формулировки, а не про ставки. Ставки бухгалтер знает и без вас; формулировки задаёте вы, и только вы. Отправьте ему проект договора со сметой и задайте эти вопросы одним письмом.
- 1Под какой предмет мы покупаем: право пользования, экземпляр или услугу — и какой вариант удобнее для нашей системы налогообложения? Это определяет вид договора, а не наоборот.
- 2Продукт есть в реестре отечественного ПО. Меняет ли это что-то в нашем случае и что именно ты хочешь увидеть в договоре, чтобы это применить?
- 3Как разделить в договоре лицензию, внедрение, доработку, обучение и поддержку, чтобы тебе не пришлось потом писать справку на каждую цифру?
- 4Годовая лицензия оплачена одной суммой. Как показать в акте период действия прав и число рабочих мест — отдельными полями или текстом?
- 5Доработку под нас мы получаем как результат работ. Право на этот результат переходит к нам или остаётся у подрядчика — и что из этого следует для учёта?
- 6Какой комплект документов ты считаешь полным, чтобы принять расход без дополнительных запросов: договор с приложениями, акт, лицензионное соглашение, счёт, платёжное поручение — чего в этом списке не хватает?
Права на результат доработки — это развилка, которая тянется дальше учёта: она определяет, сможете ли вы через два года передать систему другому подрядчику и что произойдёт при смене команды. Мы разбираем её отдельно в материалах о договоре на разработку и о постановке системы на учёт. Задать этот вопрос дешевле всего до подписания, а обнаружить ответ — дороже всего в момент расставания с подрядчиком.
Комплект документов и цепочка прав
Ниже — что стоит собрать в одну папку сразу, а не искать через год. Это не бухгалтерская инструкция, а список того, что должно физически существовать по итогам проекта. Отсутствие любого пункта обнаруживается всегда в один и тот же момент — когда документ срочно понадобился.
- Договор со всеми приложениями, включая смету по статьям и техническое задание. Смета в приложении важнее, чем кажется: именно она объясняет, откуда взялись суммы в акте.
- Лицензионное или сублицензионное соглашение с видимым объёмом прав: сколько рабочих мест, на какой срок, какие ограничения по использованию.
- Подтверждение статуса продукта на дату сделки: номер записи в реестре отечественного ПО и дата, на которую вы её проверяли. Скриншот карточки с датой — минимальный вариант, письмо правообладателя — надёжный.
- Акт с детализацией по тем же статьям, что и смета, с одинаковыми формулировками. Расхождение названий между сметой и актом — самая частая причина запроса расшифровки.
- Счета и платёжные поручения, в которых назначение платежа совпадает с предметом договора. Платёжка «за услуги» по лицензионному договору создаёт вопрос на ровном месте.
- Если лицензия куплена через партнёра — документы, подтверждающие его право передавать вам это право дальше. Цепочка должна читаться без устных пояснений.
Карта связей из трёх узлов в ряд: «Правообладатель», «Партнёр (сублицензиар)», «Ваша компания». Между первым и вторым стрелка с подписью «лицензионный договор: объём прав, срок»; между вторым и третьим — стрелка с подписью «сублицензионный договор: тот же объём, срок не длиннее». Под третьим узлом гроздь из пяти карточек-документов: «договор с приложениями», «лицензионное соглашение», «акт с детализацией», «счёт и платёжка», «выписка из реестра с датой». Отдельным пунктиром показан четвёртый узел «Подрядчик по внедрению» со стрелкой к вашей компании и подписью «работы и услуги — отдельный договор». Чертёжный стиль, подписи по-русски.
Что проверить на дату чтения
Всё, что касается ставок и норм, в этой статье отсутствует намеренно. Правила налогообложения операций с программным обеспечением пересматривались, и за время, пока текст лежит в журнале, они успеют измениться ещё раз. Ниже маршрут, который занимает меньше часа и не устаревает.
- 1Найдите карточку продукта в реестре отечественного ПО и запишите номер записи и дату проверки. Проверять надо конкретную редакцию, а не название вендора: у правообладателя может быть в реестре один продукт, а вам продают соседний.
- 2Попросите у поставщика письменное подтверждение статуса продукта на дату сделки. Ссылка на сайт — не документ, а письмо с подписью — документ.
- 3Уточните у бухгалтера действующую редакцию нормы, на которую он опирается, и дату, на которую он её смотрел. Ответ «там льгота» без даты через год не поможет.
- 4Запишите дату проверки в файл решения по проекту вместе с фамилией того, кто её делал. Через полгода вы не вспомните, актуальны ли выводы, и будете проверять всё заново.
Мы описываем состав документов и структуру договора — то, что относится к нашей работе как подрядчика. Вопрос о применимости конкретного режима к вашей сделке решает ваш бухгалтер или налоговый консультант по действующей редакции на дату операции. Подрядчик по автоматизации, который между делом обещает вам налоговую экономию, выходит за пределы своей компетенции, и отвечать за последствия будете вы, а не он. По состоянию на сентябрь 2026 года это единственный честный порядок.
Когда структура договора не стоит переговоров
Обратная сторона темы, о которой не пишут: возня со структурой договора сама по себе стоит времени, и на небольших суммах она не окупается. Ниже четыре ситуации, в которых правильный ответ — не оптимизировать, а подписать типовой договор и заняться проектом.
- 1Лицензионная часть меньше 100 000 ₽
Согласование структуры договора — это 6–8 часов с двух сторон вместе с юристами, то есть 7 200–9 600 ₽ по той же модельной ставке 1 200 ₽/час. На лицензии в 60–80 тысяч рублей разница режимов измеряется величиной того же порядка, что и переговоры о ней. Порог, с которого разговор точно окупается, — примерно 300 000 ₽ лицензионной части.
- 2Расходы не влияют на ваш налог
На отдельных режимах налогообложения состав расходов на итоговый налог не влияет вовсе. Уточните это у бухгалтера одним вопросом до того, как втягиваться в разбор: ответ может закрыть тему за две минуты. Детализация акта при этом всё равно полезна — но уже для управленческого учёта, а не для налога.
- 3Продукта в реестре нет и альтернативы нет
Если нужная система в реестр не включена, а замены под вашу задачу не существует, обсуждать нечего: выбор делается по функциональности. Что означает отсутствие продукта в реестре для закупки и для выбора системы, разобрано отдельно — для частной компании без госзаказчиков это чаще всего не значит ничего.
- 4Проект — заказная разработка под вас
Система, написанная под ваши процессы, в реестре отечественного ПО не появится: заявителем выступает правообладатель продукта, распространяемого на рынке. Вопрос о льготном режиме по реестру здесь снимается сам, зато становится важнее другой — кому принадлежит результат и как он ставится на учёт.
И обратный случай, ради честности. Если вы покупаете лицензий на несколько миллионов рублей, работаете на общей системе налогообложения и в компании есть бухгалтер, который держит учёт в порядке, — структура договора стоит отдельного разговора и отдельной недели. В этом случае разговор надо начинать не с подрядчика, а с бухгалтера: он скажет, что хочет увидеть в документах, а мы это напишем.
Налоговый режим проекта задаётся в тот момент, когда стороны договариваются о предмете договора. Всё остальное — оформление уже принятого решения.
