Разберем ситуацию по шагам и подготовим понятный алгоритм заполнения формы «Персонифицированные сведения о физических лицах» (КНД 1151162) за 2026 год, когда по директору (единоличному исполнительному органу коммерческой организации) возникает обязанность исчислять страховые взносы не ниже федерального МРОТ даже при отсутствии реальной зарплаты.
Основная сложность — понять, что именно означает строка 070 «Сведения о сумме выплат и иных вознаграждений, начисленных в пользу физического лица»: это фактические начисления (зарплата/вознаграждения) или это минимальная база для взносов, «доначисленная» до МРОТ по правилам НК РФ. На практике встречаются оба подхода: часть бухгалтеров ставит «0», часть — «МРОТ». Посмотрим, откуда берутся оба решения, чем они отличаются, и как выбрать вариант осознанно.
С 2026 года в НК РФ закрепили правило минимальной базы по страховым взносам в отношении физлица, которое является единоличным исполнительным органом коммерческой организации. Упрощенно логика такая:
Если за месяц директору начислено меньше федерального МРОТ (или вообще не начислено ничего), то для целей исчисления страховых взносов база за этот месяц принимается равной МРОТ.
Это правило относится именно к определению базы по взносам (то есть к расчету РСВ и к уплате взносов), а не напрямую к «зарплатному учету» и не всегда напрямую к «персонифицированным сведениям».
Отсюда и появляется развилка:
Если понимать ПСВ как отчет «про начисленные выплаты», то при отсутствии начислений по директору в строке 070 логично поставить 0.
Если понимать ПСВ как отчет, который должен «синхронизироваться» с расчетом взносов, а раз по взносам база дотягивается до МРОТ, то в строке 070 предлагают ставить МРОТ.
Чтобы принять решение, давайте разберем нормативную логику заполнения строки 070 и затем отдельно — прикладную логику «как это реализуют в программах» и «как минимизируют риски на практике».
В порядке заполнения ПСВ сказано ключевое: по строке 070 указывают сумму выплат и иных вознаграждений, начисленных плательщиком в пользу физического лица за отчетный месяц.
Это важное слово — начисленных. Оно обычно трактуется бухгалтерски: начисление появляется, когда у нас есть документ/операция начисления (зарплата, премия, вознаграждение по договору и т. п.). Если начисления не было — то в классическом смысле сумма начисленных выплат равна нулю.
Теперь сопоставим с «минимальной базой». Норма НК РФ о МРОТ говорит, что для целей определения базы по страховым взносам сумма выплат «принимается равной МРОТ», если она меньше МРОТ. Здесь легко спутать термины:
Объект / выплаты — то, что реально начислено физлицу.
База по взносам — величина, с которой считаются взносы. В общем случае база «следует» за выплатами, но в 2026 году для директора появляется специальное правило «минимальной базы».
«Принимается равной МРОТ» — формулировка для расчета взносов. Это не всегда означает, что организация реально начислила директору доход на МРОТ как зарплату.
И вот здесь появляется принципиальный вопрос: строка 070 — это «выплаты/начисления» или «база для взносов»?
Если строго держаться определения строки 070 как «начисленные выплаты», то при отсутствии начислений ставим 0. Если же считать, что ПСВ должно отражать «сумму, участвующую в расчете взносов» (то есть минимальную базу), то получаем МРОТ.
В обсуждениях бухгалтеров часто подчеркивают: в ПСВ нет отдельной строки «минимальная база» — есть строка «сумма выплат». Из-за этого часть специалистов считает, что «подменять выплаты базой» методологически неверно, даже если взносы платим с МРОТ.
Вопрос про «код категории застрахованного лица» возникает регулярно, потому что многие мыслят по аналогии с разделом 3 РСВ. Важно: в электронных форматах и в детализации элементов формы ПСВ действительно встречается поле «Месяц / Код категории застрахованного лица / Сумма выплат» (в ряде интерфейсов оно может быть скрыто или подставляться автоматически).
Логика выбора кода категории обычно такая же, как в РСВ: код зависит от тарифа страховых взносов и статуса физлица (гражданство/резидентность по правилам кодов).
В типовом случае директор — гражданин РФ, организация платит взносы по основному тарифу. Тогда чаще всего применяется код категории: НР.
Если директор — иностранный гражданин, выбор будет иным (например, временно пребывающий/временно проживающий), и код категории нужно подбирать по справочнику кодов категорий застрахованных лиц, применяемых в отчетности по взносам.
Практический совет: если программа подставляет код автоматически, не ломаем механику: проверяем, что он соответствует вашему тарифу (основной/пониженный) и статусу физлица. Если программа просит выбрать вручную — для стандартного случая берём НР.
Рассмотрим подробнее подход «070 = начисленные выплаты».
Когда применяется: директору не начисляли зарплату/вознаграждения, нет кадрово-зарплатных документов начисления за месяц, организация не проводит «виртуальные начисления» ради минимальной базы.
Как заполняем:
Включаем директора в ПСВ как застрахованное лицо (персональные данные, СНИЛС и т. п.).
В строке 070 за месяц ставим 0,00.
Код категории застрахованного лица ставим тот, который соответствует тарифу и статусу директора (для обычного случая — НР).
Аргументы в пользу «0»:
Строка 070 прямо описана как «сумма выплат и иных вознаграждений, начисленных» — если начислений нет, сумма ноль.
Норма НК РФ про МРОТ сформулирована «для целей определения базы для исчисления страховых взносов», а ПСВ по смыслу — не «расчет взносов», а «сведения о начисленных выплатах».
Если в ПСВ показать «МРОТ как доход», можно создать искусственную картину дохода директора там, где его фактически не было (это может быть чувствительно в некоторых жизненных ситуациях, когда где-то анализируют доходы; даже если формально это «для взносов», на уровне данных это выглядит как начисление).
Риски подхода «0»:
Может появляться расхождение между тем, что вы платите взносы «с МРОТ» (по новому правилу), и тем, что показываете в ПСВ нулевые начисления.
В некоторых инспекциях или при автоматизированных контрольных соотношениях могут возникать вопросы, потому что «по директору ожидают базу не ниже МРОТ», а видят ноль в сведениях. Это не означает автоматически «ошибка», но может повышать вероятность требований/пояснений.
Как уменьшить риск вопросов при «0»:
Проверяем, что РСВ заполняется корректно по правилам минимальной базы (в РСВ есть строки/поля для базы и взносов, и именно там «дотяжка до МРОТ» должна быть отражена в нужных показателях).
Держим под рукой аргументацию: «ПСВ — это выплаты/начисления, а минимальная база — это расчетный механизм для взносов».
Если используем 1С, фиксируем учетную логику: отсутствие документов начисления означает отсутствие начисленного дохода — значит в ПСВ будет ноль.
Теперь разберем альтернативный подход, который многие выбирают, потому что он кажется «более безопасным» с точки зрения автоматических проверок и сопоставления с расчетом взносов.
Идея подхода: раз по директору с 2026 года нужно исчислить взносы не ниже чем с МРОТ, то в ПСВ показываем сумму выплат (строка 070) равной МРОТ, чтобы ПСВ «не выглядел нулевым» и данные были согласованы с логикой начисления взносов.
Когда применяется на практике:
Организация не начисляет директору зарплату, но платит взносы по правилу «минимальной базы».
Программа (например, 1С или сервис сдачи отчетности) предлагает заполнение ПСВ так, что строка 070 автоматически становится равной МРОТ.
Бухгалтер выбирает стратегию «минимизировать общение с ИФНС», предпочитая показать МРОТ в ПСВ, чтобы снизить вероятность требований.
Как заполняем:
Включаем директора в ПСВ.
В строке 070 ставим федеральный МРОТ на начало 2026 года (например, в обсуждениях фигурирует сумма 27 093 руб.).
Код категории — как правило НР (если основной тариф и директор — гражданин РФ), либо другой код по статусу/тарифу.
Аргументы, которыми обычно обосновывают «МРОТ» в строке 070:
По директору с 2026 года база по взносам не может быть ниже МРОТ — значит в «персонифицированных данных» тоже надо показать сумму не ниже МРОТ.
Есть разъяснения ФНС о том, что в отчетности по взносам нужно отражать сумму выплат, минимальную базу и взносы — и это часто читают расширительно, применяя к ПСВ по аналогии с разделом 3 РСВ.
Так реализовано/рекомендовано в части методических материалов и в некоторых программных подсказках: строку 070 трактуют как «базу для взносов» (хотя терминологически это спорно).
Риски подхода «МРОТ»:
Методологический: строка 070 формально про начисленные выплаты, а вы фактически показываете «расчетную базу», то есть «как будто начислили доход», которого не было.
Учетный: в данных появляется «начисление» на МРОТ. Если дальше эти данные кто-то интерпретирует как доход, может возникнуть путаница. Поэтому важно понимать, что вы делаете и зачем.
Согласованность с внутренним учетом: если в бухучете и зарплатном учете начислений нет, а в отчетности появляется «начислено МРОТ», нужно аккуратно организовать учетную логику в программе, чтобы не порождать дополнительных расхождений.
Как уменьшить риск методологических претензий при «МРОТ»:
Не смешиваем понятия: в учетной политике/внутреннем регламенте фиксируем, что отражаем «минимальную базу для взносов», а не «реальную зарплату».
В 1С используем специальные механизмы (если они реализованы в конфигурации) для отражения «минимальной базы» без формирования реальной зарплаты и НДФЛ.
Проверяем, чтобы 6-НДФЛ/НДФЛ-логика не «подтягивалась» автоматически из такого «виртуального дохода» (если программно есть риск — настраиваем начисление так, чтобы оно не облагалось НДФЛ и не попадало в зарплатные выплаты).
Сведем различия в понятную логику выбора. Посмотрим на вопросы, которые нужно себе задать:
Как вы интерпретируете строку 070?
Если строго как «начисленные выплаты», логика ведет к «0». Если как «сумма, с которой платим взносы», логика ведет к «МРОТ».
Как заполняет ваша программа?
Если 1С/сервис отчетности автоматически предлагает МРОТ (и это не «ошибка формата», а заложенная методика), часть компаний следует этому, чтобы не ломать автоматизацию. Но полезно понимать смысл и риски.
Готовы ли вы к потенциальным требованиям/пояснениям?
Если готовы аргументировать «0» ссылкой на порядок заполнения и разделение понятий «выплаты» и «база», можно выбрать «0». Если вы хотите снизить вероятность вопросов ценой методического компромисса, выбирают «МРОТ».
Важно ли вам не создавать «виртуальный доход» в данных?
Если принципиально важно, чтобы нигде не появлялся «начисленный доход», выбираем «0» и отдельно отражаем минимальную базу только в расчетах по взносам.
Итоговый практический вывод: в профессиональной среде реально используются оба решения. С точки зрения буквального чтения порядка заполнения — сильная позиция у варианта «0 при отсутствии начислений». С точки зрения «прикладной согласованности с минимальной базой по взносам» и некоторых программных реализаций — распространен вариант «МРОТ в строке 070».
Теперь посмотрим на прикладную часть: что делать в 1С, чтобы отчет сформировался корректно и выбранная стратегия не привела к «снежному кому» расхождений.
Где в 1С формируется ПСВ: как правило, отчет находится в списке регламентированных отчетов (раздел «Отчетность» / «Регламентированные отчеты») и формируется как «Персонифицированные сведения о физических лицах» (КНД 1151162).
Что проверяем перед формированием отчета:
Физлицо директора заведено корректно: СНИЛС, паспортные данные, статус (гражданин РФ/иностранный гражданин) — от этого может зависеть код категории.
Есть ли по директору кадровые основания (прием/назначение), чтобы он попадал в отчет как застрахованное лицо.
Какая у вас учетная логика: есть ли начисления зарплаты/вознаграждений или вы ведете «нулевую зарплату».
Если выбираем решение «0»:
Не создаем никаких «технических начислений» на МРОТ.
Формируем ПСВ и проверяем, что директор включен, а в строке 070 стоит 0.
Отдельно контролируем РСВ: минимальная база для взносов должна отработать там, где она предусмотрена для расчета взносов. Если в вашей конфигурации для директора реализован отдельный механизм минимальной базы, проверяем его настройки и результат.
Если выбираем решение «МРОТ»:
Проверяем, как именно ваша конфигурация 1С реализует минимальную базу: иногда это делается расчетным механизмом без «выплаты», иногда — через специальный вид начисления/корректировки.
Смотрим, чтобы техническая сумма попадала именно в ПСВ/взносы, но не превращалась в «зарплату к выплате» и не тянула за собой НДФЛ как реальный доход (это критично, если вы не хотите показывать «выплату»).
Формируем ПСВ и проверяем строку 070: стоит МРОТ за соответствующий месяц.
Какие объекты 1С обычно помогают контролировать ситуацию:
РегламентированныеОтчеты — место, где формируем ПСВ и проверяем итоговые показатели.
ФизическиеЛица и карточка сотрудника/руководителя — корректность персональных данных и статуса.
НастройкиРасчетаЗарплаты (или аналог в вашей конфигурации) — чтобы исключить нежелательные налоги/удержания при технических начислениях.
РасчетСтраховыхВзносов (или механизм расчета взносов) — чтобы убедиться, что минимальная база учитывается там, где ей место: в расчете взносов и РСВ.
Важно: названия объектов и точные пункты меню могут отличаться в зависимости от конфигурации (1С:Бухгалтерия, 1С:ЗУП, версии платформы). Но логика контроля одинаковая: разделяем «начисления как доход» и «расчетные корректировки базы по взносам» и проверяем, куда что попадает.
Посмотрим на типовые ошибки, которые «выплывают» из обсуждений и реальной практики.
Путают ПСВ и раздел 3 РСВ
Раздел 3 РСВ и форма ПСВ похожи по «персонифицированной» части, но это разные отчеты с разной методологией. Не переносим механически правила из одного в другой без проверки.
Подменяют «выплаты» «базой» без понимания последствий
Если ставим МРОТ в строке 070, осознаем, что это может выглядеть как начисление дохода, хотя по сути это минимальная база для взносов. Настраиваем учет так, чтобы это не превращалось в «зарплату к выплате».
Смешивают тему ПСВ с 6-НДФЛ
ПСВ — про выплаты/взносы, а 6-НДФЛ — про НДФЛ и удержание налога с доходов. Если дохода не было, НДФЛ-отчетность живет по своим правилам. Не делаем выводы «раз в ПСВ МРОТ, то и НДФЛ надо сдавать как будто был доход» — это разные налоги и разные основания.
Не проверяют код категории застрахованного лица
Для директора-гражданина РФ при основном тарифе обычно будет НР. Для иных статусов (иностранцы, пониженные тарифы) код будет другой. Проверяем соответствие тарифу и статусу.
Соберем короткий, но четкий алгоритм — как действовать без лишних кругов.
Шаг 1. Определяем учетную ситуацию: директору реально начисляли выплаты за месяц или нет.
Шаг 2. Выбираем стратегию заполнения строки 070:
Если придерживаемся буквального смысла «начислено = то, что начислили документами» — ставим 0.
Если хотим синхронизировать ПСВ с минимальной базой и следуем программной методике/рекомендациям — ставим МРОТ.
Шаг 3. Выбираем код категории застрахованного лица:
Обычный случай (директор — гражданин РФ, основной тариф) — НР.
Иные статусы — подбираем код по справочнику кодов категорий застрахованных лиц.
Шаг 4. Формируем отчет в 1С/сервисе сдачи отчетности, проверяем строку 070 и код категории, контролируем отсутствие «лишних» налоговых последствий (НДФЛ/выплаты).
Шаг 5. Сверяем логику с РСВ: минимальная база и взносы должны быть отражены там корректно; ПСВ не должен «ломать» общую согласованность отчетности.
Если цель — ответить именно на вопрос «какую сумму ставить в строке 070», то технически вариантов два:
0,00 — если трактуем строку 070 строго как «начисленные выплаты», а начислений по директору нет.
МРОТ — если выбираем практику «показываем минимальную базу» и/или следуем методике, заложенной в части программных решений и разъяснительных материалов.
Чтобы принять решение без «веры в слухи», действуем так: вместе отделяем выплаты от базы, читаем формулировку строки 070 («начисленные выплаты»), анализируем норму НК РФ («для целей определения базы по взносам»), а затем выбираем стратегию с учетом вашей практики взаимодействия с инспекцией и вашей учетной политики.
Важно: если вы хотите полностью снять проблему «виртуальных начислений», самый понятный с точки зрения учета путь — оформлять директору реальные законные начисления (даже минимальные, если это допускается режимом работы и документами). Но это уже управленческое решение компании, а не только вопрос одной строки отчета.
Информация носит справочный характер и не заменяет анализ вашей конкретной ситуации, учетной политики и применяемой конфигурации 1С.