Как понять логику работы НДФЛ в 1С:ЗУП и почему данные в отчетах не совпадают с документами?

← На главную

Работа с НДФЛ в программе 1С:Зарплата и управление персоналом 8 (ЗУП) часто вызывает вопросы даже у опытных специалистов. Кажется, что система живет своей жизнью: суммы в ведомостях не соответствуют начислениям, а отчеты показывают цифры, которые невозможно найти в табличных частях документов. Рассмотрим подробнее, как на самом деле устроена эта логика, и разберем по шагам механизмы, управляющие налогом. Для детального анализа расчета налога можно использовать отчет для проверки и расшифровки НДФЛ в расчетных документах.

Понятие «Трехглавого дракона» НДФЛ

Для понимания логики системы первым проектом проанализируем ситуацию разделения налога на три независимые, но связанные сущности. В ЗУП НДФЛ — это не одна цифра, а три разных состояния:

НДФЛ бухгалтерский (БУ): Это проводка Дт 70 Кт 68.01. Она фиксируется в момент начисления зарплаты (обычно последним числом месяца). С точки зрения БУ, мы должны выделить налог из задолженности перед сотрудником, чтобы финансовая отчетность была достоверной.
НДФЛ исчисленный (НУ): Это налоговое обязательство, которое возникает согласно НК РФ. Оно жестко привязано к Дате получения дохода.
НДФЛ удержанный (НУ): Это факт удержания налога при выплате денег. Фиксируется только документами типа Ведомость.

Разберем, почему это важно. Налоговый кодекс требует исчислять налог в момент получения дохода (день выплаты), но бухгалтерия должна видеть задолженность уже в конце месяца. Именно из-за этого разрыва в ЗУП реализована сложная система регистров.

Зачем нужна «Планируемая дата выплаты»?

Многих смущает реквизит Планируемая дата выплаты в документах начисления. Выясним причину его существования. Программе необходимо заранее (до момента реальной выплаты) рассчитать налог, определить право на вычеты и применить правильную ставку (13%, 15% или 18%). Поскольку расчет происходит нарастающим итогом с начала года, системе нужно знать, к какому налоговому периоду (дню) отнести этот доход.

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

Почему в ведомостях появляются странные суммы НДФЛ?

Рассмотрим ситуацию: вы создаете ведомость на 10 000 рублей, а НДФЛ в ней подтягивается в размере 5 000 рублей. Почему так происходит? ЗУП — это «машина регистров», а не документов. Система не просто берет 13% от текущей суммы в табличной части, она выполняет следующий алгоритм:

Анализирует остатки по регистру накопления Расчеты налогоплательщиков с бюджетом по НДФЛ.
Смотрит, сколько налога было исчислено ранее, но еще не было удержано.
Если за прошлые периоды накопился «хвост» (например, из-за исправлений задним числом или изменения статуса резидента), ведомость попытается удержать весь этот накопленный долг сразу.

Проанализируем работу регистра накопления. Он хранит данные в разрезе Физическое лицо, Ставка, Месяц налогового периода и Регистрация в ИФНС. Если хотя бы один из этих параметров «разъехался» (например, в начислении указана одна ИФНС, а в ведомости другая), система увидит переплату по одной аналитике и недоимку по другой. В итоге в отчетах вы увидите «раздутые» суммы доходов и налогов. Для устранения подобных расхождений можно воспользоваться инструментом для проверки и выравнивания исчисленного и удержанного НДФЛ.

Механизм накопительного итога и прогрессивная шкала

С введением многоступенчатой шкалы налога (13%, 15%, 18% с 2025 года) логика усложнилась. ЗУП рассчитывает налог по формуле:

(Весь доход с начала года * Ставка) - Налог, исчисленный ранее

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

Как выправить учет, если он «разъехался»?

Если данные в Анализе НДФЛ не сходятся, рекомендуем следующий алгоритм действий:

Восстановление последовательности: В ЗУП, как и в торговых программах, важен порядок. Если вы изменили документ Начисление зарплаты за январь, вы обязаны перезаполнить и перепровести все последующие ведомости по этому сотруднику.
Проверка аналитики: Сравните данные в регистре Учет доходов для исчисления НДФЛ и Расчеты налогоплательщиков с бюджетом по НДФЛ. Особое внимание уделите полям Категория дохода и Регистрация в налоговом органе.
Использование технических отчетов: Вместо обычных расчетных листков используйте отчет Проверка разд. 2 6-НДФЛ или универсальный отчет по регистрам НДФЛ.

Для программной проверки остатков можно использовать запросы к виртуальным таблицам остатков. В коде это выглядит примерно так:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	НДФЛОстатки.ФизическоеЛицо,
    |	НДФЛОстатки.СуммаОстаток КАК ИсчисленоНоНеУдержано
    |ИЗ
    |	РегистрНакопления.РасчетыНалогоплательщиковСБюджетомПоНДФЛ.Остатки(&Период, ) КАК НДФЛОстатки";
Запрос.УстановитьПараметр("Период", ТекущаяДата());
Результат = Запрос.Выполнить();

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