При работе в 1С:ERP Управление предприятием или 1С:Зарплата и управление персоналом 3.1 многие пользователи сталкиваются с ситуацией, когда при проведении документа Списание безналичных денежных средств с видом операции "Перечисление налога", движения по регистрам выглядят «странно». Вместо того чтобы закрыть налог по конкретному сотруднику или ведомости, программа распределяет сумму мелкими частями (по несколько рублей или копеек) между множеством работников. Рассмотрим, почему это происходит, является ли это ошибкой и как правильно анализировать такие движения.
Для начала проанализируем, в каких именно регистрах фиксируются данные. В системе 1С существует два ключевых регистра накопления для учета НДФЛ, которые часто путают:
Начисление зарплаты) и удержанного налога (документом Ведомость).Важно понимать, что данные для отчета "Регистр налогового учета по НДФЛ" и справок о доходах (бывшие 2-НДФЛ) в части перечисленного налога берутся именно из второго регистра. Если мы видим там множество мелких записей, это результат работы автоматического алгоритма распределения.
Выясним причину распределения. В программах 1С реализован жесткий принцип FIFO (First In, First Out — первым пришел, первым ушел). Система не связывает конкретную платежку в банк с конкретным сотрудником напрямую в момент создания документа. Вместо этого программа «видит» общую очередь из сумм налога, которые уже были удержаны у сотрудников, но еще не были перечислены в бюджет.
Рассмотрим ситуацию на примере. Допустим, 3-го числа выплачивается основная зарплата за прошлый месяц 200 сотрудникам. В этот момент налог у них удержан, но еще не перечислен. В регистре Расчеты налогоплательщиков с бюджетом по НДФЛ образуется «задолженность» перед бюджетом по всей массе сотрудников. Если 2-го числа (днем ранее или даже в тот же день, но раньше по времени) оформляется увольнение одного сотрудника и по нему отдельной платежкой перечисляется НДФЛ, программа анализирует общую очередь.
Поскольку у 200 сотрудников обязательство по перечислению возникло (условно) в ту же секунду или раньше, программа берет сумму из «увольнительной» платежки и начинает гасить ею самые старые записи в очереди. В результате налог уволенного сотрудника «разлетается» копейками по всем остальным коллегам. А когда позже будет проведена основная платежка по всей зарплате, она точно так же «дозакроет» хвосты уволенного и распределится по остатку очереди.
Посмотрим на ситуацию со стороны хронологии. Для корректного (с точки зрения визуального восприятия) отражения данных в регистрах критически важна последовательность проведения документов. Если вы проводите сначала Списание безналичных денежных средств на уплату НДФЛ, а только потом — Ведомость, которой этот налог удерживается, программа вообще не найдет удержанных сумм и не сможет их закрыть корректно, либо закроет суммы за прошлые месяцы.
Правильная последовательность действий выглядит так:
Начисление зарплаты, Увольнение, Отпуск). Здесь налог только исчисляется.Ведомость (в банк, в кассу). В этот момент налог удерживается. Появляется запись в регистре «приход» (обязательство перечислить).Списание безналичных денежных средств. Налог перечисляется. Появляется запись в регистре «расход» (погашение обязательства).Если в цепочке появляется межрасчетная выплата (например, командировка), и вы платите НДФЛ по ней раньше, чем основной НДФЛ с зарплаты, дробление неизбежно, так как программа стремится соблюсти справедливость: перед государством все сотрудники равны, и любая поступившая сумма налога гасит самую старую задолженность организации по любому из них.
Если вы подозреваете, что дробление вызвано не логикой FIFO, а технической ошибкой, рекомендуем проверить остатки по регистрам. Часто «хвосты» тянутся из прошлых периодов из-за ручных корректировок. Для этого можно использовать Универсальный отчет по регистру накопления Расчеты налогоплательщиков с бюджетом по НДФЛ.
Если в отчете вы видите «зависшие» суммы с видом движения Приход, которые не закрываются Расходом уже несколько месяцев — это и есть причина, по которой каждая новая платежка дробится, пытаясь закрыть эти старые долги. Для исправления таких ситуаций в 1С предусмотрен документ Операция учета НДФЛ. С его помощью можно «схлопнуть» остатки, введя корректирующие записи по конкретным сотрудникам и категориям дохода.
Стоит отметить, что описанная проблема дробления была максимально актуальна до 2023 года. С введением Единого налогового платежа (ЕНП) и Единого налогового счета (ЕНС) правила игры существенно изменились. Теперь для налоговой инспекции и отчетности 6-НДФЛ факт привязки конкретной платежки к сотруднику потерял первостепенное значение.
В современных релизах 1С:ERP:
Расчеты налоговых агентов с бюджетом по НДФЛ во многих сценариях заполняется автоматически по факту выплаты зарплаты, а не по факту проведения банковской выписки по налогу.Поэтому, если вы видите дробление в старых периодах или работаете в конфигурации, где еще используется старая методика «по платежкам», помните: это не влияет на итоговую сумму налога по сотруднику за год. Если общая сумма удержанного налога совпадает с общей суммой перечисленного в справке о доходах, значит, учет ведется верно.
Методологи 1С и эксперты по налоговому учету сходятся во мнении: дробление перечисленного налога не является ошибкой. Это математическое следствие алгоритма распределения платежей. Пытаться вручную переделывать движения регистров, чтобы «платежка Иванова закрыла налог Иванова», — это трудозатратный процесс, который может привести к нарушению последовательности и ошибкам в отчетности 6-НДФЛ.
Единственный случай, когда стоит вмешаться — если дробление происходит из-за некорректных аналитик. В 1С:ERP НДФЛ учитывается в разрезе:
Если у вас перечисление идет по одной ИФНС, а удержание зафиксировано по другой (например, ошиблись в подразделении или карточке организации), программа не сможет состыковать эти движения, и возникнет перекос. В остальном же — доверьтесь автоматическим алгоритмам распределения 1С.