При переносе данных из старых систем в 1С:Бухгалтерия предприятия 3.0 КОРП часто возникают ситуации, когда остатки по счету 02 «Амортизация основных средств» в бухгалтерском (БУ) и налоговом (НУ) учете не совпадают с расчетными ожиданиями программы. Типичная причина — пропуск начисления амортизации за один или несколько месяцев в старой базе. Если отчетность за прошлый год уже сдана, главный бухгалтер, как правило, отказывается корректировать ввод остатков, чтобы не изменять входящее сальдо и не подавать уточненные декларации. В этой статье мы подробно разберем, как программно и методологически выровнять учет в текущем периоде, в том числе используя специализированное выравнивание остатков БУ и НУ для 1С:Бухгалтерии 3.0 (для этого есть обработка автоматического выравнивания остатков БУ и НУ в 1С).
Для начала проанализируем ситуацию с точки зрения математических формул, которые использует 1С для расчета амортизации. Понимание алгоритма критически важно для выбора метода исправления. Рассмотрим формулы:
Амортизация_НУ = ПервоначальнаяСтоимость / СрокПолезногоИспользования. Как мы видим, в НУ сумма ежемесячной амортизации фиксирована и не зависит от текущей остаточной стоимости. Пропуск одного месяца в прошлом просто приведет к тому, что в конце срока использования останется «недоамортизированный» хвост, но текущие начисления не изменятся.Амортизация_БУ = (БалансоваяСтоимость - ЛиквидационнаяСтоимость) / ОстаточныйСрок. Здесь БалансоваяСтоимость — это Счет01 - Счет02. Если в прошлом периоде мы не начислили амортизацию, то Счет02 меньше, чем должен быть, балансовая стоимость выше, и программа в текущем месяце распределит «излишек» на оставшиеся месяцы, увеличивая сумму ежемесячного платежа.Таким образом, простое «игнорирование» ошибки приведет к тому, что суммы амортизации в БУ и НУ будут ежемесячно различаться, порождая временные разницы. Проконтролировать эти отклонения в динамике поможет ведомость амортизации основных средств по месяцам за период — для контроля ошибок также пригодится обработка проверки базы на ошибки перед отчетностью.
Если нам нужно, чтобы входящее сальдо на 1 января нового года было верным, но при этом оборотно-сальдовая ведомость за прошлый год осталась неизменной (совпадала со сданным балансом), проанализируем механизм межотчетного периода. Это специальный технический момент «между» 31 декабря старого года и 1 января нового.
Рассмотрим пошагово, как это реализовать:
Операция, введенная вручную.Дт 84.01 - Кт 02.01 на сумму пропущенной амортизации.Почему это работает: Данная проводка не повлияет на финансовый результат (счет 90, 91) 2024 года, не изменит налог на прибыль и не отразится в отчетности за 2024 год. Однако при открытии января 2025 года начальное сальдо по счету 02 уже будет включать эту сумму, и программа корректно рассчитает амортизацию БУ, исходя из правильной остаточной стоимости.
Согласно ФСБУ 6/2020, исправление параметров амортизации может рассматриваться как изменение оценочных значений. Мы можем легально изменить параметры так, чтобы расчет «выровнялся» сам собой. Для этого воспользуемся документом Изменение элементов амортизации ОС.
Выясним причину: если мы хотим, чтобы ежемесячная сумма амортизации в БУ стала равна сумме в НУ, несмотря на разницу в накопленном износе, нам нужно математически изменить знаменатель в формуле БУ.
Рассмотрим пример. Если пропущен 1 месяц амортизации, нам нужно увеличить ОстаточныйСрокПолезногоИспользования в бухгалтерском учете на этот 1 месяц. Посмотрим, как это сделать в программе:
Изменение элементов амортизации ОС.Этот метод является наиболее «чистым» с точки зрения аудита, так как он не требует ручных правок регистров и опирается на стандартные механизмы ПБУ 21/2008.
Проанализируем еще один математический подход. Поскольку формула БУ включает ЛиквидационнуюСтоимость, мы можем временно или постоянно изменить ее так, чтобы разница между балансовой стоимостью и ликвидационной давала нужный результат при делении на срок.
Как предложили эксперты, формула выглядит так: ЛиквидационнаяСтоимость_Новая = ЛиквидационнаяСтоимость_Старая + Сумма_Пропущенной_Амортизации. Это позволит «заморозить» сумму недоимки, чтобы она не размазывалась по текущим периодам. Однако помните, что в НУ ликвидационной стоимости не существует, поэтому данный метод гарантированно создаст разницы по ПБУ 18/02.
Если главный бухгалтер готов отразить ошибку в текущем периоде (например, январе), можно доначислить амортизацию через прочие расходы. Но помните: в 1С недостаточно просто сделать проводку. Для оперативного исправления движений может понадобиться универсальное редактирование движений документа (в этом поможет обработка редактирования проводок и регистров накопления).
Разберем, какие объекты и регистры 1С нужно задействовать:
Операция, введенная вручную.Дт 91.02 (не принимаемые в НУ) - Кт 02.01. Важно использовать не принимаемые расходы, чтобы не занизить налог на прибыль текущего года ошибочными расходами прошлых лет.Амортизация ОС (или Расчет амортизации ОС (бухгалтерский учет) в зависимости от версии) — этот процесс упростит помощник заполнения документа Корректировка регистров.Если объектов основных средств «миллион», как выразился автор темы, ручные операции не подходят. В этом случае необходимо написать небольшую обработку или воспользоваться готовыми инструментами автоматизации. Проанализируем пример логики для такой обработки:
// Пример логики поиска расхождений
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| ПараметрыАмортизации.ОсновноеСредство,
| ПараметрыАмортизации.СрокИспользованияНУ,
| ПараметрыАмортизации.СрокИспользованияБУ
|ИЗ
| РегистрСведений.ПараметрыАмортизацииОСБухгалтерскийУчет КАК ПараметрыАмортизации";
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
// Здесь можно программно создать документ "Изменение элементов амортизации"
// и скорректировать ОстаточныйСрок для выравнивания сумм
КонецЦикла;
Рассмотрим вариант сдвига СПИ в налоговом учете. Многие программисты пытаются «подогнать» НУ под БУ, изменяя срок полезного использования. Будьте осторожны! Срок в налоговом учете жестко регламентирован амортизационными группами. Любое изменение СПИ_НУ должно быть обосновано либо модернизацией, либо исправлением технической ошибки первичного ввода.
Для решения задачи без изменения прошлых периодов и без «уточненок» мы рекомендуем: