Признание и учет ПО в свете требований ФСБУ 14/2022 «Нематериальные активы»

Авторы: Наталья Прокофьева и Оксана Филатова

В рамках современной тенденции цифровизации и повышения эффективности для большинства компаний важным вопросом становится автоматизация бизнес-процессов. Автоматизация бизнес-процессов — в последнее время один из главных способов сокращения затрат в системе любого уровня: от подразделения или отдела до компании целиком. Автоматизация избавляет людей от рутинных задач, поэтому в процессах, в которых ранее требовалось два сотрудника, после автоматизации нужен только один.

Сейчас считается, что поручить алгоритмам можно любой бизнес-процесс, при этом естественно проще всего автоматизировать типовые операции:

• Обработку/контроль сделок или их отдельных этапов;
• СМС- и email-рассылки;
• документооборот;
• бухгалтерский и складской учёт;
• проведение платежей.

В последние несколько лет в эту сферу как небольшой, так и крупный бизнес начинает активно инвестировать в ожидании повышения эффективности в долгосрочной перспективе. Компании набирают в штат сотрудников и создают новый отдел и/или привлекают подрядчиков для создания нового программного обеспечения (далее – ПО) или существенной доработки существующего. При этом вступившее в силу с 01.01.2024 новое ФСБУ 14/2022 «Нематериальные активы», утвержденное Приказом Минфина России от 30.05.2022 №86н (далее – ФСБУ 14/2022 «Нематериальные активы»), уточняет требования к критериям признания и оценке нематериальных активов, в том числе ПО.

Как показывает практика проверок проект по созданию ПО, а также его реализация не всегда почти никогда тщательно не документируются и не отражаются правильно в бухгалтерском учете. Как следствие, в отдельных случаях возникают сложности с корректностью формирования стоимости таких нематериальных активов на балансе, трудности с доказыванием правомерности капитализации затрат на его создание как для целей налогового, так и бухгалтерского учета. В результате в отчетности такой важный и ценный актив может совсем не появиться или появиться в искаженной стоимости, могут возникнуть и налоговые последствия. Не стоит забывать и о правовых рисках владения ПО в случаях, когда «хромает» юридическая сторона осуществляемых мероприятий по его созданию. В отдельных случаях недобросовестные компании могут использовать возможность капитализации затрат на создание НМА как элемент манипуляции финансовым результатом.

Как это часто бывает, компании начинают свои работы по созданию ПО, не задумываясь о корректности документального оформления: отсутствуют сметы, приказы, решения, договоры со сторонними организациями, акты и отчеты о проделанной работе. Не проявляется должная осмотрительность в выборе подрядчиков, не фиксируются следы проверки их благонадежности, или же фиксируется недостаточно аргументов в пользу экономической обоснованности расходов. Зачастую забывается, что расходы на создания ПО должны соответствовать бюджету и быть измеряемыми. Таким образом, зачастую признание расходов на создание и доработку ПО в затратах периода, с одной стороны занижает размер активов (не всегда правомерно), с другой – несет дополнительные налоговые риски.

Но еще больше сложностей и «подводных камней» возникает, когда компании начинают капитализировать расходы на создание ПО, что в большинстве случаев порождает множество вопросов и споров как с контролирующими органами, налоговой, так и с аудиторами.

Во избежание таких ситуаций, как показывает наша аудиторская практика, для капитализации затрат на создание ПО следует учитывать следующие моменты:

1. Планы компании о создании ПО должны быть зафиксированы. Такие планы могут быть оформлены как на уровне приказа генерального директора, так и решением собственников (или совета директоров). В таких документах необходимо четко указать срок создания, определить основные этапы процесса, способы (собственными силами или сторонними организациями) и укрупненно расписать бюджет мероприятия. Также необходимо назначить ответственное лицо за реализацию проекта по созданию ПО и определить график реализации разработки ПО.
2. На уровне предварительного плана будет полезно сразу определиться с инвентарными объектами, что позволит более четко аллоцировать затраты сначала на уровне капитальных вложений и далее при формировании первоначальной стоимости объектов НМА. ФСБУ 14/2022 «Нематериальные активы» говорит о том, что инвентарный объект может быть как «простым», так и комбинированным.
3. Если компания планирует создать ПО силами подрядчиков, то следует обратить внимание на следующие моменты:
   • если это технически осуществимо, целесообразно использовать одного подрядчика для создания ПО, который занимается соответствующей профильной деятельностью в области ИТ-технологий (состоит в реестре ИТ-компаний, имеет соответствующий ОКВЭД, имеет сайт с описанием основных характеристик бизнеса и достаточный штат сотрудников и т.п.). Данная информация подтвердит наличие возможности и опыта выполнить необходимые работы по созданию ПО. Привлечение нескольких подрядчиков, а уж тем более подрядчиков, имеющих непрофильный вид деятельности по ОКВЭДу или штатную численность 1 человек, может вызвать вопросы, при этом неочевидным станет разграничение между подрядчиками ответственности за финальный результат;
   • всех подрядчиков необходимо проверять на благонадежность, формировать «пакет безопасности» (ст. 54.1 НК РФ, Письма ФНС России от 10.03.2021 БВ-4-7/3060@, от 31.10.2017 N ЕД-4-9/22123@1);
   • Следует детально прописать в договоре перечень работ (техническое задание) и определить их стоимость, а также периодичность и сроки сдачи промежуточных и окончательного результатов (ежемесячно, ежеквартально либо иной период), определить критерии для принятия работ заказчиком;
   • Важно утвердить форму отчетных документов (акты, отчеты) и их детализацию, это поможет в будущем доказать экономическую целесообразность. Чем детальнее и подробнее будет отчет, тем лучше;
   • Так как большинство ИТ компаний работают по почасовым ставкам, в отдельных случаях будет целесообразно установить в договоре средний размер почасовой ставки исполнителя и определить общее количество человеко-часов или лимит часов на выполнение отдельных подэтапов или всего проекта.
4. Если компания планирует создать ПО собственными силами, то при капитализации таких затрат в соответствии с ФСБУ 14/2022 «Нематериальные активы» она должна учитывать один важный критерий, установленный стандартом, а именно: НМА признается, когда может быть выделен (идентифицирован) из других активов или отделен от них. Если ПО пишется силами сотрудников компании, то необходимо организовать учет их рабочего времени таким образом, чтобы можно было четко отделить время на создание ПО от всего остального рабочего времени, это позволит впоследствии четко скалькулировать расходы на оплату труда специалистов, вовлеченных в создание ПО, с последующей их капитализацией.
5. Создание ПО должно быть ограничено по времени и срок этот должен быть соблюден, в противном случае при затянувшемся создании ПО могут возникнуть вопросы к экономической обоснованности расходов и обесценению объекта (п.12 МСФО (IAS) 36 «Обесценение активов»), если задержка срока готовности будет существенной.
6. Далее, компания должна четко определить, какое событие будет свидетельствовать о готовности НМА приносить экономические выгоды компании и наличие права у Компании на эти выгоды (п.4 ФСБУ 14/2022 «Нематериальные активы»), будет ли это такое событие как успешное прохождение тестирования ПО или иное. Данные события также должны произойти в сроках проекта (без существенных задержек) и документально зафиксированы в рамках ввода ПО в эксплуатацию. В комиссию по вводу объекта обязательно следует включить технических специалистов, имеющих соответствующую экспертизу в области ИТ. От правильности момента признания НМА будет зависеть размер начисляемой амортизации, как в налоговом, так и в бухгалтерском учете.
7. При принятии нематериальных активов к учету и вводе в эксплуатацию компании необходимо определить элементы амортизации (п.42 ФСБУ 14/2022 «Нематериальные активы»), включающие в себя срок полезного использования, ликвидационную стоимость и способ начисления амортизации. Следует помнить, что элементы амортизации подлежат проверке на соответствие использованию актива ежегодно, а также при наступлении новых обстоятельств. Изменение элементов амортизации является изменением оценочных значений, должно быть документально оформлено и отражено в бухгалтерском учете перспективно. Стандарт допускает, что по некоторым НМА срок полезного использования определен быть не может. Если у компании есть такие объекты, то суждение о невозможности определения СПИ также актуализируется ежегодно, плюс к таким видам НМА существуют повышенные требования в части теста на обесценение - он проводится на ежегодной основе вне зависимости от наличия/отсутствия признаков обесценения.
8. В ходе создания ПО могут возникать обстоятельства, которые требуют внесения корректировок в первоначальный проект как по срокам, так и по объемам, возникающие корректировки плана должны оформляться соответствующим образом (дополнительным соглашением к договору, приказами, служебными записками ответственных лиц), а также должны быть согласованы с генеральным директором/собственниками на уровне приказов/протоколов.
9. Создание дополнительных модулей ПО диктуется временем и быстрым развитием информационных технологий. Компании могут создавать несколько модулей на базе основного ПО. При этом каждый новый модуль может учитываться как самостоятельный объект или же как составная часть ПО. При этом компании необходимо также документировать создание каждого отдельного модуля как самостоятельного объекта учета, чтобы правильно сформировать его стоимость и своевременно ввести его в эксплуатацию. Расходы по доработке также можно отнести на стоимость НМА, если они связаны с улучшением (повышением) первоначально принятых нормативных показателей функционирования ПО. Соответственно в таких ситуациях также следует помнить о подготовке прозрачных документов, подтверждающих факт улучшения характеристик ПО и стоимостные показатели.

В ходе создания и эксплуатации ПО не следует забывать про вопросы обесценения в соответствии с МСФО (IAS) 36 «Обесценение активов». Тестированию на обесценение подлежат неамортизируемые или незаконченные созданием НМА вне зависимости от признаков обесценения, амортизируемые объекты НМА тестируются только при наличии признаков обесценения

В случае с ПО в большинстве случаев, как показывает практика, лучшей оценкой будет ценность использования актива, т.е. приведённая (дисконтированная) стоимость будущих ожидаемых денежных потоков. Определение возмещаемой суммы ПО может быть произведено только по ПО, если по нему возможно выделить самостоятельный денежный поток, или в составе группы активов – единицы, генерирующей денежный поток (ЕГДС), в случаях, когда такой самостоятельный поток от ПО выделить невозможно.

В век цифровизации и бума развития информационных технологий создание ПО не только повышает прибыльность и повышает конкурентоспособность современных компаний, но и позволяет достичь дополнительной капитализации бизнеса, реального увеличения активов компании, демонстрирующих ее большой экономический потенциал. При этом формальная сторона процесса не должна отставать, чтобы формирование балансовой стоимости такого актива не вызывала вопросов ни у аудиторов, ни у пользователей отчетности. Резюмируя вышеизложенные рекомендации и учитывая возникающие сложности с признанием и оценкой НМА, мы рекомендуем обеспечить:

• наличие распорядительных документов по созданию НМА с указанием способа, сроков, видов работ и их стоимости;
• формирование бюджета на разработку ПО;
• документальное обоснование затраченного времени на разработку ПО и выполненных работ (хозяйственным или подрядным способом);
• демонстрацию функционирования ПО на заключительных этапах: в момент заведения первого проекта, в момент завершения тестирования (это могут быть скрины, внутренние видеоконференции) при вводе в эксплуатацию объекта;
• наличие правоустанавливающих документов (если применимо);
• наличие внутренней документации на установление элементов амортизации (СПИ, метода амортизации, ликвидационной стоимости) и их ежегодную актуализацию.

Мы рассчитываем, что наши рекомендации помогут бухгалтеру эффективно справиться с задачами признания и учета программного обеспечения в отчетности компании.