Рассмотрим ситуацию на примере 1С:Бухгалтерии предприятия 3.0, когда при формировании расчета 6-НДФЛ за 9 месяцев 2023 года программа неожиданно заполняет строку 180 суммой, которая совпадает с НДФЛ, удержанным при выплате зарплаты за первую половину октября. Например, аванс выплачен 20.10.2023, с него удержано 1 351 рубль НДФЛ, и ровно 1 351 рубль появляется в строке 180 расчета за 9 месяцев.
Сразу определим главное: НДФЛ, удержанный с зарплаты, фактически выплаченной 20.10.2023, сам по себе не должен попадать в расчет 6-НДФЛ за 9 месяцев 2023 года. Такая выплата относится уже к IV кварталу. Если строка 180 за 9 месяцев заполнилась такой же суммой, совпадение сумм еще не означает, что программа действительно включила октябрьский аванс в отчет. Чаще это признак существовавшего ранее остатка, некорректного движения по регистрам НДФЛ, задвоенного удержания или ошибки в документах прошлых месяцев.
В рассматриваемой ситуации особенно важно обратить внимание на то, что в анализе НДФЛ появляются отрицательные строки, относящиеся к июню, а в октябрьских ведомостях присутствуют остатки за предыдущие месяцы. Это существенно меняет направление проверки: искать причину нужно не только в октябрьском начислении, а начиная с первого месяца, в котором возник неправильный остаток.
Разберем сначала законодательную логику. С 1 января 2023 года изменился порядок определения даты фактического получения дохода в виде оплаты труда. Для целей НДФЛ датой получения зарплаты стала дата ее фактической выплаты. Это правило распространяется и на зарплату за первую половину месяца, которую в обиходе продолжают называть авансом.
То есть с 2023 года при каждой выплате зарплаты необходимо исчислять и удерживать НДФЛ. Если зарплата за первую половину октября выплачена 20.10.2023, то именно 20.10.2023 является датой получения этого дохода для НДФЛ.
Расчет за 9 месяцев охватывает доходы соответствующего отчетного периода. В Разделе 2 показатели отражаются нарастающим итогом с начала налогового периода. Поэтому доход с датой фактического получения 20.10.2023 и связанный с ним НДФЛ должны учитываться уже при формировании расчета за 2023 год, а не расчета за 9 месяцев.
Для 2023 года действовала форма 6-НДФЛ, утвержденная приказом ФНС России от 15.10.2020 № ЕД-7-11/753@ в редакции приказа ФНС России от 29.09.2022 № ЕД-7-11/881@. ФНС отдельно разъясняла порядок заполнения этой формы и указывала, что в Разделе 2 отражаются обобщенные показатели дохода, исчисленного и удержанного налога нарастающим итогом с начала налогового периода.
При этом для Раздела 1 расчета за 9 месяцев 2023 года применялся специальный период удержания: в нем отражался НДФЛ за интервалы, относящиеся к периоду с 23 июня по 22 сентября. Налог, удержанный 20 октября, в этот интервал также не входит.
Следовательно, если мы видим в расчете за 9 месяцев сумму 1 351 рубль и точно знаем, что 20 октября с аванса был удержан НДФЛ в размере 1 351 рубль, не будем сразу делать вывод, что именно октябрьская выплата попала в строку 180. Сначала выясним происхождение этой суммы по регистрам.
Теперь рассмотрим подробнее саму строку 180. В форме 6-НДФЛ за 2023 год строка 180 Раздела 2 предназначалась для отражения общей суммы НДФЛ, излишне удержанной налоговым агентом, нарастающим итогом с начала налогового периода.
Это принципиально важно. Строка 180 не является строкой для обычного удержанного НДФЛ. Обычный удержанный налог отражается по строке 160. Поэтому появление суммы в строке 180 означает, что учетная система считает определенную сумму налога излишне удержанной.
Например, если по данным налогового учета по сотруднику исчислено 10 000 рублей НДФЛ, а зарегистрировано удержание 11 351 рубля, в учете возникает превышение удержанного налога над тем налогом, который должен был быть удержан. Разница 1 351 рубль может быть интерпретирована программой как излишне удержанная сумма и попасть в строку 180.
Поэтому при неожиданном заполнении строки 180 зададим другой вопрос: не «почему октябрьский аванс попал в отчет?», а «где в регистрах до окончания сентября возникло лишнее удержание или неправильная аналитика на сумму 1 351 рубль?»
Посмотрим на пример. Допустим, НДФЛ с аванса октября составляет 1 351 рубль. В строке 180 также находится 1 351 рубль. На первый взгляд связь кажется очевидной.
Но в зарплатном учете одинаковые суммы регулярно повторяются. Если сотруднику несколько месяцев начисляется приблизительно одинаковая зарплата, НДФЛ с авансов тоже может быть одинаковым. Поэтому остаток 1 351 рубль вполне мог образоваться, например, в июне, июле или сентябре.
Более того, октябрьская ведомость может подхватить ранее возникший остаток. Тогда именно после проведения октябрьских документов проблема становится заметной, хотя создана она была несколькими месяцами раньше.
Это хорошо согласуется с ситуацией, когда в октябрьской ведомости неожиданно видим строки «за июнь», отрицательные суммы или другие остатки прошлых периодов. Такая картина означает, что программа пытается обработать ранее возникшую задолженность либо излишнее удержание в разрезе внутренней аналитики НДФЛ.
Для рассматриваемой ситуации есть еще одна очень важная техническая деталь. В 2023 году фирма 1С официально описывала проблему в 1С:Бухгалтерии 8 редакции 3.0, связанную с учетом НДФЛ при начислении аванса.
Ошибка была зарегистрирована в базе ошибок под идентификатором БЗКБ 60008207. В материалах поддержки также встречается связанный код ошибки 30179948 и исправление EF_60008207.
Суть ошибки состояла в следующем: при окончательном расчете зарплаты НДФЛ, ранее рассчитанный с аванса, мог повторно отражаться в учете. В результате возникали расхождения между начисленной зарплатой, суммой к выплате и данными НДФЛ в ведомостях.
Особенно показательно, что проблема активно проявлялась при расчетах за июнь 2023 года. Фирма 1С указывала, что некоторые пользователи обнаруживали расхождение именно в июне, а у некоторых некорректные данные тянулись с начала года.
Исправление было выпущено для версий 3.0.138 и 3.0.139. Позднее ошибка была исправлена в выпущенной версии 3.0.139.23. Следовательно, в версии 3.0.143.32 программный код этого исправления уже присутствует.
Однако здесь есть важный нюанс. Обновление программы не обязательно исправляет движения уже проведенных старых документов. Если начисление аванса и окончательной зарплаты было создано в проблемном релизе и сформировало неправильные движения по регистрам, после обновления эти старые записи могут продолжать находиться в информационной базе.
Именно поэтому рекомендация по этой ошибке заключалась не только в установке исправления. После установки исправленной версии требовалось перепровести документы начисления аванса и окончательного расчета, а ведомости на выплату перезаполнить.
Обратим внимание на слово «перезаполнить». Просто нажать «Провести» у уже существующей ведомости иногда недостаточно. Если табличная часть ведомости была рассчитана еще по неправильным данным, повторное проведение может сохранить старый состав выплат и старые суммы НДФЛ.
Поэтому появление в рассматриваемой ситуации красных отрицательных остатков именно с июня является серьезным основанием проверить эту проблему в первую очередь.
Разберем по шагам правильную последовательность проверки. Не будем сразу корректировать строку 180 и не будем создавать ручные движения по регистрам. Сначала определим источник ошибки.
Сделаем резервную копию информационной базы перед массовым перепроведением документов.
Откроем сформированный расчет 6-НДФЛ за 9 месяцев и расшифруем строку 180. Определим сотрудников, по которым программа показывает излишне удержанный налог.
Запомним конкретную сумму по каждому сотруднику. Например, 1 351 рубль.
Сформируем зарплатные отчеты по этому сотруднику не только за октябрь, а за период с 01.01.2023 по 30.09.2023.
Затем сформируем аналогичный анализ за более длинный период, например по 20.10.2023. Сравним состояние учета до и после октябрьской выплаты.
Найдем первую дату, после которой появляется отрицательный остаток или расхождение между исчисленным и удержанным налогом.
Если первая проблемная строка относится к июню, начнем исправление именно с июня, даже если строка 180 стала заметна только в октябре.
Не ориентируемся только на месяц, в котором ошибка проявилась в отчетности. Регистры накопления хранят движения предыдущих периодов, поэтому документ октября может лишь обнаружить или погасить неправильный остаток, сформированный в июне.
Для первичной диагностики сформируем доступные в конфигурации отчеты по НДФЛ. В зависимости от версии и интерфейса названия отдельных команд могут немного различаться, но прежде всего используем Подробный анализ НДФЛ по сотруднику, Анализ НДФЛ по документам-основаниям и отчет по удержанному НДФЛ.
В Подробном анализе НДФЛ по сотруднику проследим, как менялись доход, налоговая база, исчисленный налог и удержанный налог. Особенно внимательно посмотрим даты фактического получения доходов.
Затем используем Анализ НДФЛ по документам-основаниям. Он полезен тем, что позволяет перейти от итоговой суммы к конкретным документам, которые сформировали налоговые показатели.
Если обычный отчет Удержанный НДФЛ выглядит правильно, это еще не означает, что регистры полностью корректны. В рассматриваемой ситуации как раз возможен вариант, когда итоговое удержание внешне выглядит нормально, но по отдельной аналитике регистра остается неправильный остаток. Поэтому после стандартных отчетов перейдем к технической проверке регистров.
Один из ключевых объектов для такой диагностики — регистр накопления Расчеты налогоплательщиков с бюджетом по НДФЛ. Он используется для налогового учета НДФЛ и влияет на заполнение Раздела 2 расчета 6-НДФЛ.
В этом регистре отражаются данные об исчисленном и удержанном налоге с необходимой аналитикой. Упрощенно можно ориентироваться следующим образом: исчисленный НДФЛ формирует увеличение обязательства, а удержание его погашает. Если по одной аналитике удержано больше, чем было начислено к удержанию, может возникнуть остаток, который программа интерпретирует как излишнее удержание.
Откроем Функции для технического специалиста, перейдем к регистрам накопления и найдем Расчеты налогоплательщиков с бюджетом по НДФЛ. Если технический раздел в интерфейсе недоступен, используем Универсальный отчет.
В Универсальном отчете выберем регистр накопления Расчеты налогоплательщиков с бюджетом по НДФЛ и установим период, например с 01.01.2023 по 20.10.2023.
Добавим отбор по проблемному сотруднику. Для анализа обязательно выведем дату получения дохода и регистратор. Поле регистратора особенно полезно: оно показывает конкретный документ 1С, который создал движение.
Затем последовательно найдем движения на сумму 1 351 рубль. Не будем ограничиваться датой 20 октября. Проверим все движения с такой суммой и посмотрим, каким документом каждое из них зарегистрировано.
Если увидим, например, что отрицательный остаток 1 351 рубль появился еще после окончательного расчета за июнь, мы фактически нашли источник строки 180. Октябрьская сумма в этом случае лишь совпала с ранее возникшим остатком.
При технической проверке легко перепутать два похожих регистра:
Расчеты налогоплательщиков с бюджетом по НДФЛ — используем прежде всего для проверки исчисленного и удержанного НДФЛ в разрезе физических лиц. Именно его особенно внимательно анализируем при проблеме со строкой 180.
Расчеты налоговых агентов с бюджетом по НДФЛ — исторически использовался для учета перечисленного в бюджет налога.
Поэтому дата перечисления НДФЛ в бюджет сама по себе не определяет, должен ли налог находиться в строке 180. Нам необходимо разделять три события: исчисление налога, удержание налога с работника и перечисление налога налоговым агентом.
В частности, появление в анализе записи о перечислении 5 октября рядом с июньской аналитикой не означает автоматически, что октябрьский доход отнесен к июню. Сначала посмотрим регистратор и остальные измерения движения. Октябрьский документ мог закрывать старый остаток, который находился в базе с июня.
Проанализируем эту ситуацию отдельно. Если в Ведомости в банк или другой ведомости октября программа показывает какие-либо суммы «за июнь», в том числе отрицательные, это означает, что с точки зрения внутренних регистров по сотруднику существует остаток прошлых расчетов.
При нормальном закрытии зарплатного учета старые остатки, не соответствующие реальной задолженности, тянуться несколько месяцев не должны. Поэтому отрицательная июньская сумма — более важная диагностическая информация, чем совпадение строки 180 с октябрьским НДФЛ.
Выясним, откуда она появилась. Для этого откроем июньские документы в хронологическом порядке:
Начисление зарплаты за первую половину июня.
Ведомость, которой была выплачена первая половина июня.
Документ фактической выплаты — например, Списание с расчетного счета при выплате через банк.
Начисление зарплаты при окончательном расчете июня.
Ведомость окончательной выплаты за июнь.
Документ фактической выплаты остатка зарплаты.
Посмотрим движения каждого документа по регистрам НДФЛ. Если налог, относящийся к авансу, отражен повторно при проведении окончательного расчета, это очень похоже на последствия ошибки БЗКБ 60008207.
Отдельно проверим дату выплаты в документах начисления. С 2023 года этот реквизит особенно важен, поскольку именно дата фактического получения денежного дохода определяет налоговый период для НДФЛ.
В Начислении зарплаты посмотрим дату выплаты для каждого начисления. Не ограничимся октябрем. Если ошибка тянется с июня, проверим июнь, июль, август и сентябрь.
Дата выплаты может автоматически подставляться на основании настроек зарплаты. Если фактическая дата перечисления сотрудникам отличается от настроенной, необходимо было своевременно указать фактическую дату.
Например, если остаток зарплаты за сентябрь фактически выплачен 5 октября 2023 года, для НДФЛ этот доход относится к октябрю. То, что зарплата начислена «за сентябрь», не делает ее сентябрьским доходом для НДФЛ по правилам, действовавшим в 2023 году.
Но если в документах стоит правильная дата 20.10.2023, а строка 180 за 9 месяцев все равно заполнена, не будем менять правильную дату только ради того, чтобы отчет стал «красивым». Продолжим искать неправильное движение в регистрах.
Теперь разберем способ исправления, если обнаружили последствия ошибки учета авансов 2023 года.
Поскольку исправление этой программной ошибки уже входило в релизы после 3.0.139.23, версия 3.0.143.32 содержит исправленный алгоритм. Однако документы, проведенные ранее неправильным алгоритмом, необходимо обработать заново.
Выполним исправление на резервной копии базы и строго в хронологической последовательности.
Определим первый месяц, в котором появляется неправильный остаток. Если это июнь, начнем с июня.
При необходимости временно отменим проведение связанных с выплатой последующих документов, чтобы более поздние движения не мешали восстановлению последовательности.
Откроем Начисление зарплаты за первую половину месяца и пересчитаем НДФЛ.
Проведем документ заново.
Откроем окончательное Начисление зарплаты за этот же месяц, пересчитаем НДФЛ и проведем его заново.
После этого перезаполним ведомости на выплату. Не ограничимся обычным перепроведением уже заполненной табличной части.
Проверим суммы к выплате и НДФЛ в перезаполненной ведомости.
Проведем документы фактической выплаты — например, Списание с расчетного счета или Выдача наличных.
Перейдем к следующему месяцу и повторим последовательность.
После восстановления июня последовательно обработаем июль, август и сентябрь.
Не изменяем фактически перечисленные сотрудникам суммы только ради исправления регистра. Наша задача — заставить 1С заново сформировать правильные налоговые движения на основании реальных начислений и выплат.
Если ошибка присутствовала только в июне, обычно достаточно восстановить последовательность начиная с июня. Если неправильные остатки существуют с января, обработаем документы с января.
В рассматриваемой проблеме пользователь может уже попробовать перепроведение и не получить результата. Это не опровергает версию с ошибочными регистрами.
Разберем причины.
Перепроведена только октябрьская зарплата, хотя неправильный остаток образован июньским документом.
Перепроведены начисления, но не перезаполнены ведомости.
Ведомость перезаполнена, но связанный документ фактической выплаты сохранил старые движения и требует последовательного перепроведения.
Между начислением и выплатой присутствует ручной документ Операция учета НДФЛ, который снова создает неправильный остаток.
Неправильная аналитика существует в более раннем месяце, чем тот, с которого начали перепроведение.
В базе есть дополнительные ручные корректировки регистров НДФЛ.
По одному физическому лицу заведено несколько элементов справочника сотрудников, и движения разделены между ними.
Поэтому после каждого этапа не будем просто снова открывать 6-НДФЛ. Сначала сформируем Универсальный отчет по регистру и проверим, исчез ли конкретный неправильный остаток.
Следующая распространенная причина появления строки 180 — ручные операции НДФЛ.
Откроем список документов Операция учета НДФЛ за 2023 год, а при необходимости и за предыдущий год. Особенно внимательно проверим операции по сотруднику, который расшифровывается в строке 180.
Проверим вкладки, связанные с исчислением и удержанием налога, в том числе Удержано по всем ставкам. Если в документ вручную внесено удержание НДФЛ, но отсутствует соответствующее исчисление либо оно записано с другой аналитикой, программа может считать сумму излишне удержанной.
Также проверим Перечислено по всем ставкам, если в базе ранее вручную корректировались данные перечисленного налога.
Для каждой ручной операции сопоставим:
физическое лицо;
сотрудника;
дату получения дохода;
дату удержания;
налоговую ставку;
вид дохода;
сумму исчисленного налога;
сумму удержанного налога;
ИФНС и ОКТМО, если эти реквизиты участвуют в соответствующих движениях.
Даже когда общие суммы исчисленного и удержанного НДФЛ совпадают, ошибка в одной аналитике может привести к тому, что на одной строке регистра программа увидит неудержанный налог, а на другой — излишне удержанный.
При ручном вводе операций по НДФЛ важно правильно заполнять не только сумму, но и вид дохода. В практике встречаются ситуации, когда после заполнения суммы удержания в Операции учета НДФЛ не указан необходимый вид дохода. В обычном отчете итог может выглядеть логично, но 6-НДФЛ получает другую аналитику и формирует неправильные строки.
Если найдена ручная операция, не будем просто удалять из нее сумму 1 351 рубль. Сначала определим хозяйственную операцию, которую документ должен был отражать, и восстановим все связанные реквизиты.
Особенно внимательно проанализируем операции по договорам ГПХ, прочим доходам, отпускным, больничным, перерасчетам, налоговым вычетам и смене налогового статуса. Для таких операций неправильная дата или категория дохода чаще приводит к расхождению аналитики.
Еще один технический вариант — одно физическое лицо представлено несколькими элементами справочника сотрудников.
Например, сначала человек работал по договору ГПХ, а затем был принят в штат, и вместо использования существующего физического лица был создан новый сотрудник или даже второе физическое лицо с теми же ФИО.
В результате часть НДФЛ может оказаться исчисленной по одной аналитике, а удержанной по другой. Визуально фамилия будет одинаковой, поэтому в отчетах проблему легко пропустить.
Если обнаружим дубли, не будем просто объединять или удалять элементы справочника без анализа ссылок. Сначала выясним, на какие элементы записаны начисления, выплаты и движения НДФЛ.
Если в Расчетах налогоплательщиков с бюджетом по НДФЛ обнаруживаем расхождение, дополнительно посмотрим регистр Учет доходов для исчисления НДФЛ.
Наша задача — убедиться, что доход зарегистрирован с правильной датой и аналитикой. Налог может быть удержан корректной суммой, но если доход в другом регистре записан на другую дату или с другой категорией, программа не сможет правильно сопоставить операции.
Особенно проверим строки, в которых аналитика не заполнена или существенно отличается от соседних движений этого же сотрудника.
Если октябрьская ведомость содержит суммы прошлых месяцев, дополнительно проанализируем регистр, связанный с зарплатой к выплате. Нас интересует, почему программа считает, что по июню или другому старому месяцу осталась задолженность либо отрицательный остаток.
После корректного начисления и выплаты зарплаты остаток должен соответствовать реальному состоянию взаиморасчетов с сотрудником. Если фактически сотруднику все выплачено, а программа продолжает показывать июньскую сумму в октябре, найдем документ-регистратор, создавший этот остаток.
Не будем корректировать последствия непосредственно в октябрьской ведомости. Исправим первичный документ, сформировавший неверное движение.
Красная или отрицательная сумма в аналитическом отчете сама по себе не всегда является ошибкой. Например, отрицательные показатели могут закономерно возникать при перерасчетах.
Но если перерасчетов фактически не было, сотруднику ничего не возвращали, зарплата выплачивалась полностью, а отрицательный остаток тянется несколько месяцев, его необходимо расследовать.
В рассматриваемой ситуации отрицательный июньский остаток особенно важен, потому что именно на июнь 2023 года приходилась известная проблема 1С с повторным отражением НДФЛ с аванса.
Поэтому будем двигаться от этой красной строки к регистратору. Найдем документ, которым она создана, и только после этого решим, является сумма реальной или ошибочной.
Посмотрим на условный пример.
В июне сотруднику рассчитан НДФЛ с зарплаты за первую половину месяца — 1 351 рубль. При выплате налог правильно удержан.
Затем при окончательном расчете за июнь вследствие неправильного движения программа еще раз отражает связанные с авансом 1 351 рубль. В налоговом регистре возникает несоответствие.
После этого зарплату за июль и август выплачивают как обычно. Пользователь может не заметить проблему, потому что сотрудник получает правильные деньги, а основные зарплатные отчеты внешне выглядят приемлемо.
К окончанию сентября в регистре остается отрицательный остаток 1 351 рубль. При формировании 6-НДФЛ за 9 месяцев программа определяет его как излишне удержанный НДФЛ и выводит 1 351 рубль в строку 180.
20 октября сотруднику выплачивают очередной аванс. С него совершенно законно удерживают 1 351 рубль. В октябрьской ведомости одновременно обрабатывается старый остаток. В результате пользователь видит одинаковые суммы и делает вывод, что НДФЛ с аванса 20 октября каким-то образом попал в отчет за 9 месяцев.
Но фактическая причина в нашем примере другая: в строке 180 находится старый остаток, сформированный неправильными движениями июня, а октябрьский налог лишь совпадает с ним по сумме.
Теперь рассмотрим другую ситуацию, чтобы не удалять строку 180 автоматически во всех случаях.
Предположим, в августе с сотрудника удержали 5 200 рублей НДФЛ. Позже обнаружили, что работнику полагался налоговый вычет, и после перерасчета правильная сумма НДФЛ составляет 4 550 рублей.
Разница 650 рублей фактически уже удержана у сотрудника сверх необходимой суммы. Если к окончанию отчетного периода эта сумма остается излишне удержанной и не возвращена сотруднику в установленном порядке, строка 180 может быть заполнена правомерно.
Следовательно, само наличие строки 180 не является ошибкой программы. Ошибка возникает тогда, когда программа показывает излишнее удержание, которого фактически и по данным правильного налогового учета не существовало.
Рассмотрим этот вопрос отдельно. В регламентированном отчете 1С показатели в ряде случаев можно откорректировать вручную. Поэтому технически удалить ошибочно заполненную сумму из строки 180 возможно.
Но прежде чем это сделать, разделим две ситуации.
Первая ситуация: мы точно установили, что по состоянию на 30.09.2023 излишне удержанного НДФЛ не было. Исчисленный и удержанный налог проверены по сотруднику, первичные документы соответствуют фактическим выплатам, а строка 180 возникла из-за технической ошибки старых движений 1С. Если срок сдачи отчетности истекает и исправить базу до отправки невозможно, ручное исправление показателя отчета может использоваться как временное решение.
При этом обязательно сохраним расчет, на основании которого определили правильную сумму. После сдачи отчетности продолжим исправление базы.
Вторая ситуация: в регистрах действительно существует реальное излишнее удержание. Тогда удалять строку 180 только потому, что она мешает сдаче отчета, нельзя. Сначала необходимо разобраться с самим налогом и, если требуется, выполнить перерасчет или возврат в соответствии со статьей 231 НК РФ.
Поэтому правило сформулируем так: ручное удаление строки 180 исправляет только форму отчета, но не исправляет налоговый учет в информационной базе.
Если просто установить в строке 180 ноль, неправильные движения останутся в регистрах. В следующем отчетном периоде программа снова будет опираться на них.
В результате проблема может проявиться:
в годовом расчете 6-НДФЛ;
в сведениях по конкретному физическому лицу;
в последующих ведомостях на выплату;
при перерасчете НДФЛ;
при увольнении сотрудника;
при предоставлении вычетов;
при возврате излишне удержанного налога.
Кроме того, позднее будет значительно сложнее понять происхождение старого остатка. Поэтому ручная корректировка отчета допустима только после того, как мы уверенно рассчитали правильный показатель, и не должна заменять исправление первичного учета.
Не будем использовать Операцию учета НДФЛ как первый способ лечения неизвестной ошибки.
Этот документ действительно позволяет корректировать налоговый учет, но если мы не знаем, каким первоначальным документом создан неправильный остаток, ручная операция только добавит еще одно движение.
В итоге может получиться, что в отчете за 9 месяцев строка 180 исчезнет, но в годовом расчете возникнет другое расхождение.
Поэтому соблюдаем последовательность:
находим ошибочное движение;
определяем документ-регистратор;
исправляем или перепроводим первичный документ;
перезаполняем зависимые ведомости;
проверяем регистры;
и только если исправить первичный документ невозможно или корректировка действительно должна быть ручной, используем Операцию учета НДФЛ.
Иногда при анализе возникает еще одна путаница: пользователь видит рядом с июньскими данными перечисление от 5 октября и предполагает, что именно дата перечисления налога вызвала заполнение строки 180.
Не будем смешивать эти события. Для определения дохода и удержания НДФЛ важны даты получения дохода и удержания налога. Фактическое перечисление налоговым агентом денег в бюджет — отдельная операция.
Если налог удержан правильно, но перечислен позднее, сам факт более поздней уплаты не превращает его в излишне удержанный налог работника.
Поэтому при строке 180 первично анализируем регистр Расчеты налогоплательщиков с бюджетом по НДФЛ, а не только сведения о перечислении денег в бюджет.
Отдельно разберем нормальную ситуацию. Организация может начислить зарплату за вторую половину сентября в сентябре, а выплатить ее в установленный срок в октябре.
Для НДФЛ по правилам 2023 года датой дохода будет дата октябрьской выплаты. Поэтому такая зарплата и НДФЛ с нее не включаются в Раздел 2 расчета за 9 месяцев как доход сентября только потому, что расчетный месяц зарплаты — сентябрь.
Это принципиальное отличие правил 2023 года от более старого порядка, когда для зарплаты применялось специальное правило последнего дня месяца.
Поэтому надпись «за сентябрь» в зарплатном документе сама по себе не означает, что выплата обязана присутствовать в 6-НДФЛ за 9 месяцев. Смотрим именно дату фактической выплаты.
Очень полезный прием — не анализировать только отчет, сформированный после октябрьских операций, а проверить состояние НДФЛ именно на конец отчетного периода.
Сформируем Подробный анализ НДФЛ по сотруднику и Универсальный отчет по 30.09.2023 включительно.
Ответим на три вопроса:
Какой НДФЛ был исчислен по сотруднику по состоянию на 30 сентября?
Какой НДФЛ был фактически удержан по состоянию на 30 сентября?
Существовал ли на эту дату реальный излишне удержанный налог?
Если ответа «да» на третий вопрос нет, а регистр показывает отрицательный остаток 1 351 рубль, будем искать техническую ошибку.
Если же выясним, что налог действительно был удержан сверх исчисленного, строка 180 может быть правильной, даже если позднее в октябре этот остаток каким-либо образом был зачтен.
Для дополнительной диагностики на резервной копии базы можно сравнить два состояния учета.
Сначала сформируем отчет по регистру с окончанием периода 30.09.2023. Затем сформируем его по 20.10.2023 или более позднюю дату.
Если 1 351 рубль уже присутствует на 30 сентября, октябрьский аванс точно не является первоначальной причиной возникновения суммы.
Если остаток появляется только после октябрьских документов, откроем движения конкретного октябрьского документа. Проверим, к какой дате дохода, документу-основанию и другим аналитикам записано удержание.
Такой подход намного надежнее визуального сравнения одинаковых сумм.
Документ может выглядеть заполненным правильно: дата выплаты 20.10.2023, правильный сотрудник, правильная сумма. Но окончательный ответ дает не форма документа, а его движения по регистрам.
Поэтому после проверки реквизитов нажмем команду просмотра движений документа и найдем движения по регистрам НДФЛ.
Особенно это важно для старых документов, которые были созданы до обновления конфигурации. Их внешний вид после обновления может быть нормальным, а движения оставаться сформированными старым алгоритмом до момента повторного проведения.
При перепроведении зарплатных документов будем соблюдать строгую хронологию. Зарплатный учет 1С чувствителен к состоянию регистров на момент проведения каждого следующего документа.
Например, если сначала провести октябрь, затем июнь, затем август, более поздние документы могут продолжать содержать результаты расчета, полученные из старого состояния регистров.
Поэтому работаем последовательно: июнь — июль — август — сентябрь — октябрь.
Внутри каждого месяца сначала обрабатываем начисления, затем ведомости, затем документы фактической выплаты.
После каждого месяца проверяем, нет ли необоснованного остатка. Так мы сразу увидим точку, в которой ошибка возникает повторно.
При выплате зарплаты через банк в учете участвует не только Ведомость в банк, но и документ, отражающий реальное списание денежных средств.
Поэтому недостаточно проверить одну ведомость. Посмотрим связанное Списание с расчетного счета и его движения.
Если ведомость была перезаполнена после исправления начисления, а документ списания остался в старом состоянии, его также необходимо провести в правильной последовательности.
Аналогично при выплате наличными проверим документы кассовой выплаты.
После исправления не будем ограничиваться тем, что строка 180 стала пустой. Проведем контрольную проверку.
Сформируем Подробный анализ НДФЛ по сотруднику за период с начала 2023 года по 30.09.2023.
Проверим соответствие доходов фактическим датам выплаты.
Проверим исчисленный налог.
Проверим удержанный налог.
Убедимся в отсутствии необоснованного отрицательного остатка.
Сформируем Универсальный отчет по Расчетам налогоплательщиков с бюджетом по НДФЛ.
Проверим проблемного сотрудника и сумму 1 351 рубль.
Заново заполним 6-НДФЛ за 9 месяцев.
Расшифруем строки 140, 160, 170 и 180.
Отдельно убедимся, что выплата от 20.10.2023 не включена в показатели за 9 месяцев, которым она не соответствует.
Если обнаружена ошибка регистра, не будем проверять только строку 180. Некорректные движения НДФЛ могут одновременно влиять на несколько показателей.
В Разделе 2 прежде всего проанализируем:
строку 110 — общую сумму дохода;
строку 112 — доходы по трудовым договорам;
строку 130 — налоговые вычеты;
строку 140 — сумму исчисленного налога;
строку 160 — сумму удержанного налога;
строку 170 — налог, который налоговый агент не удержал;
строку 180 — излишне удержанный налог;
строку 190 — возвращенный налог, если возвраты действительно производились.
Особенно внимательно сопоставим строки 140, 160, 170 и 180 по каждому проблемному сотруднику. Наличие одновременно неудержанного и излишне удержанного налога на близкие суммы часто указывает не на реальную налоговую ситуацию, а на несовпадение аналитики движений.
Считаем заполнение строки 180 обоснованным, если после проверки устанавливаем одновременно следующие обстоятельства:
по сотруднику действительно удержали больше НДФЛ, чем следовало по результатам расчета;
разница подтверждается документами и налоговыми регистрами;
это состояние существовало в соответствующем отчетном периоде;
сумма не является результатом задвоения движения, неправильной даты или ошибочной ручной операции;
налог к моменту, для которого определяется показатель, не был устранен способом, исключающим его отражение как излишне удержанного.
Если же единственный аргумент в пользу строки 180 звучит как «сумма совпадает с НДФЛ октябрьского аванса», этого недостаточно.
Теперь соберем все рекомендации применительно к исходной ситуации.
Имеем 1С:Бухгалтерию предприятия редакции 3.0 версии 3.0.143.32. Аванс за октябрь выплачен 20.10.2023. Удержанный при выплате НДФЛ составляет 1 351 рубль. В расчете 6-НДФЛ за 9 месяцев строка 180 также равна 1 351 рублю. В анализе присутствует отрицательный остаток, относящийся к июню, и в октябрьских ведомостях программа подхватывает суммы предыдущих месяцев.
В такой ситуации будем действовать следующим образом.
Не считаем строку 180 правильной только потому, что ее сумма совпала с октябрьским НДФЛ. Выплата 20.10.2023 не относится к расчету за 9 месяцев.
Расшифровываем строку 180 и определяем сотрудника.
Формируем анализ по сотруднику на 30.09.2023. Проверяем, существовали ли 1 351 рубль уже до октября.
Через Универсальный отчет проверяем Расчеты налогоплательщиков с бюджетом по НДФЛ и находим регистратор отрицательного движения.
Если источник находится в июне, исследуем июньские начисления аванса и окончательной зарплаты.
Учитываем известную ошибку 1С БЗКБ 60008207, при которой при окончательном расчете мог повторно отражаться НДФЛ с аванса.
Поскольку версия 3.0.143.32 уже новее релиза, в котором ошибка была исправлена, дополнительное исправление программного кода для этой конкретной ошибки не требуется. Но старые движения, сформированные до обновления, могли сохраниться.
Пересчитываем и перепроводим документы Начисление зарплаты начиная с первого проблемного месяца.
Перезаполняем ведомости на выплату, а не просто перепроводим их.
Последовательно перепроводим связанные документы фактической выплаты.
Проверяем Операции учета НДФЛ и исключаем ручное задвоение удержанного налога.
Повторно формируем анализ регистров по состоянию на 30.09.2023.
Только после устранения старого остатка заново заполняем 6-НДФЛ.
Проанализируем все признаки вместе. Если бы проблема состояла только в неправильной дате выплаты октябрьского аванса, мы ожидали бы увидеть в октябрьском начислении ошибочную сентябрьскую дату.
Но если дата выплаты проверена и действительно равна 20.10.2023, одновременно присутствуют красные июньские строки и октябрьские ведомости подхватывают прошлые остатки, картина сильнее указывает на нарушение последовательности или неправильные движения регистров прошлых месяцев.
Дополнительным аргументом является официально известная в 2023 году проблема 1С с повторным отражением НДФЛ с аванса именно при окончательном расчете зарплаты.
Поэтому в такой ситуации не будем пытаться «привязать» строку 180 к документу от 20 октября. Найдем первый неправильный остаток в хронологии.
Допустим, сотруднику 20.10.2023 выплачена зарплата за первую половину октября. Доход на дату выплаты составляет сумму, с которой рассчитан НДФЛ 1 351 рубль.
В правильном учете 20 октября возникает октябрьский доход и удерживается 1 351 рубль НДФЛ.
В расчете 6-НДФЛ за 9 месяцев эта операция не должна увеличивать ни доход Раздела 2, ни удержанный налог за период январь–сентябрь, ни строку 180.
При последующем формировании расчета за 2023 год октябрьская выплата уже будет учтена в годовых показателях в соответствии с правилами заполнения соответствующих строк.
Если при такой операции строка 180 за 9 месяцев равна 1 351 рублю, проверим остаток на 30.09.2023. Если он уже существовал, октябрьская выплата вообще не является причиной проблемы.
НДФЛ с зарплаты за первую половину октября, выплаченной 20.10.2023, не должен попадать в 6-НДФЛ за 9 месяцев 2023 года. Датой получения зарплатного дохода в 2023 году является дата фактической выплаты, поэтому доход от 20 октября относится уже к IV кварталу.
Строка 180 имеет другое назначение — она показывает излишне удержанный НДФЛ. Поэтому совпадение суммы строки 180 с НДФЛ октябрьского аванса не означает, что программа напрямую включила октябрьский налог в отчет за 9 месяцев.
Если одновременно в учете видим отрицательные остатки, относящиеся к июню, и старые суммы появляются в более поздних ведомостях, ищем источник ошибки начиная с июня.
Особенно учитываем известную ошибку 1С:Бухгалтерии 8 БЗКБ 60008207, при которой при окончательном расчете зарплаты НДФЛ с аванса мог отражаться повторно. Ошибка была исправлена в релизах 1С, в том числе к версии 3.0.143.32 исправленный алгоритм уже присутствовал, но ранее сформированные неправильные движения могли сохраниться в базе.
Поэтому правильное исправление заключается не в простом удалении 1 351 рубля из строки 180, а в поиске документа-регистратора, восстановлении последовательности начислений и выплат, пересчете НДФЛ, перепроведении начислений и перезаполнении ведомостей.
Если после полной проверки подтверждаем, что по состоянию на 30.09.2023 никакого реального излишне удержанного НДФЛ не существовало, а срок сдачи отчета не позволяет сразу исправить всю историю регистров, показатель 6-НДФЛ можно откорректировать вручную до правильного значения. Однако после сдачи обязательно устраним причину в базе, иначе старый остаток может снова проявиться при формировании годового 6-НДФЛ и других отчетов.
При поиске причины используем конкретные объекты 1С: Начисление зарплаты, Ведомость в банк, документы фактической выплаты, Операция учета НДФЛ, Подробный анализ НДФЛ по сотруднику, Анализ НДФЛ по документам-основаниям, Универсальный отчет, регистры Расчеты налогоплательщиков с бюджетом по НДФЛ, Расчеты налоговых агентов с бюджетом по НДФЛ и Учет доходов для исчисления НДФЛ.
Главный принцип диагностики сформулируем так: не исправляем итоговую строку отчета, пока не выяснили, каким документом и на какую дату возник налоговый остаток. Именно поиск первого ошибочного движения позволяет устранить проблему так, чтобы она не повторилась в следующей отчетности.
Нормативной основой для описанной ситуации являются правила определения даты фактического получения дохода, действовавшие с 01.01.2023, положения главы 23 НК РФ и порядок заполнения формы 6-НДФЛ, утвержденной приказом ФНС России от 15.10.2020 № ЕД-7-11/753@ в редакции приказа ФНС России от 29.09.2022 № ЕД-7-11/881@. Техническая проблема повторного отражения НДФЛ с аванса в 1С:Бухгалтерии 8 редакции 3.0 была описана фирмой 1С в материалах по ошибке БЗКБ 60008207.
Информация носит справочный характер