Проблема №1. Разница в копейки при начислении амортизации между БУ и НУ.
Рассмотрим первую ситуацию.
После перехода на ФСБУ6 по некоторым основным средствам при начислении амортизации может наблюдаться следующая картина:
То есть мы наблюдаем разницу между бухгалтерским и налоговым учетом по тем ОС, по которым ранее никаких разниц не было. В данном случае в одну копейку. Это происходит по тем ОС, у которых амортизация начислялась с округлением.
Поясню на примере. Допустим в январе 2021 года было приобретено ОС стоимостью 1 000 000 руб. и срок его эксплуатации 30 мес. До перехода на ФСБУ6 сумма ежемесячной амортизации вычислялась путем деления первоначальной стоимости на срок эксплуатации ОС.
Т.е. 1 000 000 / 30 = 33 333, 3333333. Программа округляла до 33 333,33. Таким образом амортизация начислялась и в бухгалтерском и налоговом учете по декабрь 2021 года включительно.
С января 2022 года в налоговом учете ничего не меняется, и амортизация по прежнему 33 333,33, а в бухгалтерском учете, в связи с переходом на ФСБУ6 формула поменялась и теперь амортизация вычисляется путем деления остаточной (балансовой) стоимости на оставшийся срок эксплуатации. И в январе 2022 года мы получаем следующую картину.
Остаточная стоимость (633 333,37 руб.) делится на оставшийся срок эксплуатации (19 мес.) и мы получаем на одну копейку больше 33 333, 34 руб. Это происходит за счет накопившихся "хвостиков", которые программа отбрасывала в течении 11 мес. в 2021 году.
Причем если весь 2021 год "хвостики" были положительные, то в 2022 году они будут то положительные то отрицательные. В январе 2022 и феврале 2022 хвостики будут отрицательные, и они скомпенсируют хвостики 2021 года, и амортизация в БУ и НУ в марте 2022 года вновь станет одинаковой. А в апреле у нас вновь будет разница в одну копейку. И далее эта копейка так и будет "скакать" из месяца в месяц.
Многим такая ситуация не нравится. Я писал в 1С, и они ответили следующее:
Добрый день.
Формулы расчета теперь разные: в бухучете исходя из балансовой стоимости, в налоговом - из первоначальной. Налоговая формула приводит к накоплению погрешностей округления, бухгалтерская - более точная. Поэтому возникает разница.
Прямо сейчас с этим ничего нельзя сделать.
Посмотрим, если эти копейки будут мешать многим, то рассмотрим, может быть дадим возможность несущественно отклониться от правил бухгалтерского учета и вносить эти погрешности из сумм бухгалтерского учета. Но уверенности, что это хорошая идея, нет: в реализации это замороченно, а польза выглядит сомнительной.
Проблема №2. Некорректная дата принятия к учету. Как следствие после перехода не начисляется амортизация. Плюс некорректные проводки в декабре при переходе.
Вторая проблема связана с некорректным остатком срока полезного использования. И возникает она по ОС,
которые были занесены в программу через ввод начальных остатков. Дело в том, что оставшийся срок использования программа определяет сопоставляя "Дату принятия к учету" и "Срок полезного использования". Так вот эта "Дата принятия к учету" определяется не автоматически, как это происходит при регистрации поступления нового ОС, а ее задает пользователь:
И до перехода на новое ФСБУ 6/2020 эта дата на начисление амортизации никак не влияла, поэтому ошибка в дате никак себя не проявляла.
Понять, что у вас есть проблема с этой датой по каким - либо ОС можно, если посмотреть проводки регламентной операции по переходу (Переход на ФСБУ 6, в обработке закрытия месяц за декабрь 2021). Дело в том, что проводки в этой операции по ОС должны быть лишь в том случае, если вы по этому ОС пересмотрели срок или установили ликвидационную стоимость с помощью документа "Изменение элементов амортизации" в декабре 2021 года. Потому, если "Изменение элементов амортизации" вы не делали, а "Переход на ФСБУ6" содержит проводки, то явно у вас ошибочный оставшийся срок эксплуатации, и программа пытается "подогнать" ту амортизацию, которая у вас к этому времени накопилась на 02 счете, к оставшемуся сроку эксплуатации ОС.
Приведу пример. Допустим вводим начальные остатки на 31.12.2020 г. по ОС стоимостью 120 000 руб. Срок его эксплуатации 120 мес. и к 31.12.2020 г. оно самортизировано ровно на половину, т.е. остаточная стоимость 60 000 руб. Чтобы выполнилось это условие ОС должно быть принято к учету ровно 5 лет назад. Т.е. дата принятия к учету должна быть в декабре 2015 года.
Ставим дату принятия к учету допустим 31.12.2015 г. Переходить на ФСБУ6 мы будем с 2022 года, поэтому в течении 21 года мы начисляем амортизацию как обычно. В декабре 2021 года делаем регламентную операцию "Переход на ФСБУ 6" и смотрим справку расчет:
В графе 9 сумма начисленной к концу декабря 2021 года амортизация: 72000 (60000 на момент ввода остатков и еще 12000 было начислено за 2021 год).
В графе 10 расчетное значение исходя из истекшего срока полезного использования ОС: 72000 (72 мес. умноженные на 1000 руб.
1000 руб. ежемесячной амортизации считается по новой формуле (Стоимость ОС - Ликвидационная стоимость) делится на срок использования ОС. (120000 - 0)/120 = 1000. Под сроком использования ОС подразумевается уточненный срок использования ОС. В данном случае он совпадает и изначальным сроком 120 мес., так как в ходе перехода мы его документом "Изменение элементов амортизации" не меняли, как и не устанавливали ликвидационную стоимость (равна нулю).
Итак сумма амортизации накопленная к моменту перехода равна стоимости, рассчитанной по формуле, исходя из истекшего срока использования. А он в свою очередь рассчитывается исходя из даты принятия к учету и полного срока эксплуатации.
А теперь давайте предположим, что мы перепутали дату принятия к учету. Допустим поставили на месяц позже - 31.01.2016 г. Получим следующую картину при переходе:
Из-за того, что мы перепутали во вводе начальных остатков дату принятия к учету, программа некорректно рассчитала истекший срок использования (71 вместо 72). В результате у нас не сходится начисленная к этому времени амортизация и ее расчетное значение по формуле. И программа делает корректировку в регламентной операции "Переход на ФСБУ6":
Программа уменьшает сумму накопленной амортизации по кредиту 02 счета, делая проводку по дебету на 1000 руб. Подгоняет амортизацию к расчетному значению.
Если мы при вводе остатков ошибемся с датой принятия к учету в другую сторону, причем ошибемся сильно и поставим 31.01.2000 г. получим следующую картину:
Программа будет считать оставшийся срок эксплуатации равным нулю, и скорректирует сумму амортизации на 02 счете, сделав ее равной первоначальной стоимости ОС, как будто ОС уже полностью самортизировалость. Вот только отправит ее не на затратный, а на 84 счет.
И со следующего месяца с января 2022 года амортизация по этому ОС начисляться перестанет. Кстати, это очень распространенная ошибка. Причем в бухгалтерском учете амортизация начисляться не будет, а в налоговом продолжит, и возникнут временные разницы.
Как исправить эту ошибку, ведь мы скорее всего уже не сможем "залезть" в закрытый период и исправить дату в документе ввода остатков. Можно попробовать следующий вариант.
Во-первых нужно будет сделать документ "Изменение элементов амортизации" декабрем 2021 года. Проводок он не сделает, но поменяет срок в нужном регистре:
А во вторых нужно будет или пропустить регламентную операцию "Переход на ФСБУ6" если вы не меняли сроки эксплуатации ОС в связи с переходом. Если по каким-то ОС меняли, то тогда нужно будет вручную скорректировать проводки в регламентной операции, а именно удалить строку с корректировкой по нужному ОС, по которому мы ранее ввели неправильную дату принятия к учету.
