При подготовке отчетности 6-НДФЛ в программе 1С:Зарплата и Управление Персоналом 2.5 бухгалтеры часто сталкиваются с неприятной ситуацией: значение в строке 110 Раздела 2 (сумма начисленного дохода) не соответствует данным, которые программа выдает при нажатии кнопки «Расшифровать». При этом программа выдает предупреждение: «Внимание. Значение показателя в отчете отличается от данных расшифровки». Ситуация осложняется тем, что расшифровка может показывать визуально верные суммы, а итоговая ячейка в самом отчете — заниженные или завышенные данные.
Рассмотрим детально причины такого поведения системы и разберем пошаговый алгоритм поиска ошибки, чтобы привести отчет в соответствие с учетными данными.
Одной из самых распространенных причин расхождения является наличие отрицательных сумм дохода (сторно) в отчетном периоде. Проанализируем механику работы программы: алгоритм заполнения ячейки 6-НДФЛ в 1С:ЗУП 2.5 суммирует все записи по регистру накопления за указанный период арифметически. Однако механизм расшифровки, заложенный в старых версиях конфигурации, зачастую игнорирует строки с отрицательными значениями или обрабатывает их некорректно, выводя в список только положительные начисления.
В результате мы видим следующую картину:
Чтобы проверить эту версию, необходимо проанализировать документы Перерасчет зарплаты и исправления за прошлые периоды, которые были зарегистрированы в текущем квартале.
Если визуальный анализ документов не дает результата, перейдем к более глубокому анализу регистров. Выясним причину расхождения, сопоставив данные регистра и итогов отчета. Для этого нам понадобится стандартный отчет по НДФЛ или Универсальный отчет по регистру накопления НДФЛ сведения о доходах.
Рассмотрим алгоритм настройки отчета для поиска расхождений:
Проанализируем сформированный отчет. Сумма дохода по этому регистру должна в точности совпадать со значением в строке 110. Если мы видим, что по конкретному сотруднику сумма в универсальном отчете отличается от его расчетного листка или от данных расшифровки в 6-НДФЛ, значит, мы нашли источник проблемы. Обратим внимание на поле Регистратор — оно укажет на конкретный документ, который некорректно сформировал движение.
Проанализируем ситуацию с датами. В 1С:ЗУП 2.5 учет НДФЛ строится на жесткой привязке к дате выплаты дохода. Строка 110 заполняется на основании записей регистра, где ДатаПолученияДохода попадает в отчетный период.
Часто возникает путаница: начисление произведено в сентябре (последний месяц отчетного периода), а фактическая выплата (например, межрасчетная) прошла в октябре. В зависимости от настроек учетной политики и вида дохода, программа может включить этот доход в 9 месяцев или перенести на следующий период. Если расшифровка строится по «упрощенному» алгоритму (просто по начислениям месяца), а отчет — по регистру с учетом дат выплаты, возникнет расхождение.
Проверьте следующие документы:
Зарплата к выплате организаций — какая дата выплаты там указана?Расходный кассовый ордер или Выписка из банка — совпадают ли даты с реальным перечислением?Посмотрим на примеры с кодами 2720 (подарки) или 2760 (материальная помощь). Эти доходы предполагают наличие необлагаемого вычета (например, 4000 рублей). В некоторых релизах ЗУП 2.5 возникала техническая коллизия: в строку 110 попадал доход уже за вычетом этой суммы (чистая налоговая база), а в расшифровке отображалась полная сумма начисления. Выяснить это можно, проверив сотрудников, получавших такие выплаты, и сверив их данные с регистром НДФЛ сведения о доходах.
Иногда корень зла кроется в техническом состоянии базы данных. Рассмотрим два сценария:
1. Дублирование физических лиц. Если в справочнике Физические лица создано два элемента для одного человека, а в справочнике Сотрудники они привязаны вперемешку, отчет 6-НДФЛ может собрать данные по обоим, но расшифровка «споткнется» на одном из них из-за нарушения ссылочной целостности.
2. Кэш формы отчета. В версии 2.5 отчеты на обычных формах сохраняют промежуточные расчеты в кэше. Если вы меняли данные в документах, нажимали «Заполнить», но сумма не меняется — попробуйте выполнить следующие действия:
Если организация имеет обособленные подразделения или меняла юридический адрес (КПП/ОКТМО) в течение года, данные могут «разъехаться» по разным регистрациям. Отчет 6-НДФЛ формируется строго по конкретному ОКТМО/КПП. Если в документе начисления по ошибке указана старая регистрация или другое подразделение, эта сумма не попадет в текущий отчет, но может отобразиться в общей расшифровке, если она не настроена на фильтрацию по регистрации.
Для исправления воспользуйтесь инструментом Корректировка учета по НДФЛ, страховым взносам или просто исправьте регистрацию в первичных документах начисления и перепроведите их.
Чтобы окончательно устранить расхождение, мы рекомендуем придерживаться следующей логики:
// Схема поиска ошибки:
1. Сформировать 6-НДФЛ и зафиксировать сумму в строке 110.
2. Сформировать Универсальный отчет по регистру "НДФЛ сведения о доходах".
3. Если Итого Универсального отчета = Строка 110, значит ошибка в алгоритме расшифровки (можно игнорировать предупреждение, если уверены в данных).
4. Если Итого Универсального отчета <> Строка 110, ищем сотрудника с расхождением.
5. Проверяем документы этого сотрудника на наличие сторно, дат выплаты и правильность ИФНС.
Помните, что 1С:ЗУП 2.5 — это программный продукт, поддержка которого ограничена, поэтому ручной контроль регистров через универсальные отчеты является самым надежным способом проверки корректности заполнения регламентированной отчетности.