Актив с нулевой себестоимостью

Сотрудники финансового блока начали делать софт сами, с помощью ИИ, за часы и за копейки. Баланс этого не замечает — и не может заметить. Что это значит для отчётности, метрик и работы финансового директора.

В этом году финансовая служба группы делает своими руками весь годовой план автоматизации — включая задачи, которые вендоры оценивали примерно в 600 тысяч долларов и которые из бюджета были вырезаны. Тратит на это дни работы и подписку на ИИ-инструмент. В отчётности от этого не осталось следа: ни актива, ни капитальных затрат, ни амортизации. Стандарт применён правильно. Проблема не в применении — проблема в том, что стандарт перестал описывать то, что происходит.

Как это началось

Началось с отчёта, который работал невыносимо медленно. Интегратор, который его когда-то сделал, за ускорение браться не хотел. За обследование и проектирование — только за них, без самой работы — попросил около 10 тысяч долларов. Мы сделали всё сами за полторы недели. Подписка на ИИ-инструмент стоила сто долларов.

Дальше пошло быстрее. Два отчёта, которые поддерживал подрядчик, — по обязательствам группы и по траншам в разрезе банков-кредиторов — он оценивал в 5 и 8 тысяч. Мы закрыли оба примерно за полтора дня.

Потом был большой проект: отчётность по МСФО, которая должна собирать данные из бухгалтерских систем, системы управления рисками, бюджетирования, заявок на оплату и начислений. За один небольшой модуль — сбор начислений от подразделений — подрядчик предварительно оценил работу примерно в 100 тысяч долларов. Техническое задание уже было. Но на первом же совещании по нему стало ясно, что нужно больше, чем в нём написано, и подрядчик ушёл переоформлять задание и смету. Мы тем временем отдали то же ТЗ ИИ-инструменту вместе с новыми пожеланиями, попросили упростить интерфейс и сделать его человеческим, сопоставили данные. На это ушло часа два. Ещё два часа люди пробовали, сказали «удобно, давайте пользоваться» — и стали пользоваться. Когда подрядчик вернулся с уточнённым заданием, модуль уже работал.

Сейчас в очереди заявки, которые вендоры в сумме оценили примерно в 600 тысяч долларов. Мы сделали ещё не всё. Мы рассчитываем закрыть их за три недели — не за полгода, как стояло в сметах. Таких примеров уже десятки, и это только финансовый блок одной группы за один квартал.

Сколько это стоило? Строго говоря — ничего. Часы людей, которые и так на зарплате, и подписка, которой пользуется вся компания.

Почему баланс этого не видит

Софт был активом не потому, что он ценен. Он был активом потому, что его создание требовало отдельного решения, отдельных людей и заметных денег. На этом держится вся конструкция IAS 38: есть момент, когда компания решила разрабатывать, и с этого момента накапливаются затраты. У нас такой момент был: мы решили попробовать сделать модуль с ИИ. Но он оказался готов раньше, чем подрядчик вернулся с уточнённым заданием и сметой. Решение разрабатывать совпало с готовым результатом — к тому времени, когда его можно было оформить, оформлять было уже нечего. А для десятков мелких инструментов не было и такого решения.

Дальше работают три механизма, и каждый по отдельности правильный.

Себестоимость ниже любого порога. Стандарт считает актив по прямым затратам. Два часа работы и доля подписки — несколько сотен долларов. Порог капитализации в учётной политике крупной компании — десятки тысяч. И не важно, какую цифру поставить: любое разумное значение окажется выше того, что мы можем насчитать. Опустить порог до нуля — значит завести реестр активов по триста долларов каждый.

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

Переоценить нельзя. Модель переоценки допускается только при наличии активного рынка. Для внутреннего отчёта о траншах его нет и не будет. Стоимость замещения — то, что просил вендор, — не является допустимой базой оценки.

Стандарт закрыт с обеих сторон: затраты слишком малы, чтобы признать, а ничего кроме затрат признавать не разрешено.

Парадокс подмены

Возьмём модуль сбора начислений. Один и тот же модуль, две истории.

Заказан у вендора: затраты около 100 000 долларов; в балансе — нематериальный актив на 100 000; в отчёте о прибылях — амортизация около 20 000 в год пять лет; EBITDA выше; капитальные затраты плюс 100 000; знаменатель ROIC больше; срок реализации — полгода.

Сделан сотрудником с ИИ: затраты около 300 долларов; в балансе — ничего*; в отчёте о прибылях — расход 300 долларов один раз*; EBITDA ниже; капитальные затраты — ноль; знаменатель ROIC меньше; срок реализации — два часа.

* Если сумма ниже порога капитализации, установленного учётной политикой. Порог есть у любой крупной компании, и ни одна из сумм в этой статье к нему не приближается.

Функция одинаковая, срок службы одинаковый. Отчётность противоположная.

Теперь представьте две компании с одинаковыми системами. Одна покупает, другая строит сама. Та, что строит, — более способная — покажет меньше активов, меньше капитальных затрат и больше операционных расходов. Балансовая стоимость внутреннего софта превращается в меру неспособности компании сделать его самой. Ровно наоборот тому, что прочитает аналитик.

И это не вопрос времени признания. Споры «капитализировать или списать» обычно про то, в каком периоде затраты попадут в прибыль. Здесь затрат нет ни в одном периоде. Актив пропущен навсегда.

Это уже было

Возражение напрашивается: неучтённые ценные вещи — не новость. Тридцать лет финансисты строили модели в Excel, и ни одна компания не ставила макросы на баланс. Компании работают на open source, стоимость которого никто не считал. Пункт 63 IAS 38 прямо запрещает признавать внутренне созданные бренды и клиентские базы, а пункт 64 объясняет почему: затраты на них неотделимы от затрат на развитие бизнеса в целом.

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

Но есть три отличия от бренда, из-за которых случай заслуживает отдельного внимания.

Первое: это прямая подмена того, что признавалось. Бренд никто не собирался покупать и капитализировать. А эти модули — ровно то, что компания покупала и ставила на баланс в прошлом году. В этом году такой же модуль на баланс не встанет.

Второе: эти вещи сидят внутри процесса закрытия отчётности. Скрипт, который собирает начисления для МСФО, сделан вне всякого контроля изменений. Для аудитора это объект проверки независимо от того, актив он или нет.

Третье: стоимость воспроизводства тоже близка к нулю. Обычная логика актива — его дорого повторить. Эти отчёты перегенерируются из технического задания за часы. Долговечное здесь — не код, а ТЗ и данные. Инструмент, который дешевле пересобрать, чем поддерживать, не имеет осмысленного срока амортизации. Актив переехал из кода в спецификацию.

А может, это гудвилл?

Первое, что мы услышали друг от друга: с точки зрения МСФО это ноу-хау, то же самое, что бренд, относится к гудвиллу, а гудвилл признаётся только при покупке компании. Рыночную стоимость повышает, балансовую — нет, и у любой сильной компании таких непризнанных вещей много. Смиритесь.

Вывод верный, путь — нет. Гудвилл по определению остаток: то, что нельзя идентифицировать и признать отдельно. Отчёт по траншам идентифицируем — его можно передать другой компании, он выполняет отдельную функцию, работодатель его контролирует. Он проходит определение нематериального актива. Не проходит только критерии признания: по себестоимости и по дате. Это другой дефект.

И логика про покупку компании работает в обратную сторону. Когда одна компания покупает другую, IFRS 3 требует вытащить из гудвилла всё, что можно идентифицировать, — включая софт, который купленная компания написала сама, — и оценить по справедливой стоимости. Оценщики делают это рутинно. Как именно — зависит от актива. Чаще всего для нематериальных активов берут доходный подход: оценивают, какой экономический эффект актив будет приносить в будущем, и дисконтируют его к текущей стоимости. Внутренний отчёт отдельного дохода не приносит, поэтому его оценивают по затратам — сколько стоило бы сделать его заново. Так или иначе оценка появляется.

То есть в сделке эти отчёты вышли бы из гудвилла и встали на баланс покупателя. Та же вещь, созданная своими руками, на баланс встать не может. Купленное — актив, сделанное — нет. Эта асимметрия — одна из причин, по которым Совет по МСФО открыл пересмотр IAS 38.

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

Что ломается, кроме баланса

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

Льготы на разработку. Налоговые стимулы и гранты на НИОКР привязаны к затратам. Ноль затрат — ноль льгот. Инновация есть, но для стимулирующих механизмов она невидима.

Контроль над отчётностью. Это самое практичное следствие. Если отчёт о прибылях собирается скриптом, который специалист по МСФО сделал в среду после обеда, этот скрипт — часть системы внутреннего контроля. Аудитор обязан его понимать. Нет реестра, нет владельца, нет контроля изменений — это дефицит контроля, а не вопрос оценки актива.

Холдинг. Инструмент, сделанный в одной компании группы, через месяц используют три другие. Внутригрупповая услуга с нулевой базой — трансфертному ценообразованию будет что обсудить.

Зависимость от людей. Сто финансистов, сто скриптов. Когда автор уходит, скрипт остаётся — и никто не знает, что он делает и от чего зависит. Это зоопарк Excel-макросов, только он размножается быстрее.

Что делать финансовому директору

Не капитализировать по отдельности. Попытка поставить каждый скрипт на баланс по себестоимости даст реестр активов по триста долларов, который будет стоить дороже, чем информация в нём. Содержательное делается в трёх местах: в учётной политике, в агрегации и в раскрытии.

1. Прописать в учётной политике явно. Инструменты, созданные сотрудниками операционных подразделений с помощью ИИ-средств, признаются расходом периода. И правило агрегации: единица оценки — не отдельный отчёт, а функциональная платформа.

2. Платформенные вещи оформлять как проект. Отчётность по МСФО — сбор начислений, мэппинги, консолидация — это один актив, а не двадцать скриптов. У него может быть дата: приказ «строим платформу силами отдела». С этой даты капитализируются часы команды по полной ставке плюс доля подписок. Получится не ноль, а честные десятки тысяч. Главная польза не в сумме: побочно появляются дата признания, учёт времени и реестр, которых сейчас нет. Отдельные отчёты сюда не тянуть.

3. Завести реестр. Каждый инструмент: что делает, на каких данных, кто владелец, от чего зависит. Автор не равен владельцу. Всё, что участвует в закрытии периода, расчёте ковенантов или платежах, — в периметр контроля изменений: тест, второй человек, история версий. Это не бухгалтерский документ, а система внутреннего контроля — и без неё раскрытие из следующего пункта нечем подтвердить.

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

5. Хранить спецификацию, а не код. Если инструмент перегенерируется за два часа, ценность в ТЗ, правилах сопоставления и тестовых примерах. Их версионировать. Код — расходный материал.

Одна честная оговорка. Мы рассматривали вариант оценивать такие вещи по стоимости замещения при первоначальном признании — по аналогии с IFRS 3 или с обменом активов. Он не работает по двум причинам. Кредитовая сторона: признать прибыль от того, что сам себе написал отчёт, нельзя. И вторая, важнее: справедливая стоимость кода действительно около нуля. Участник рынка с теми же инструментами восстановит его за те же два часа. Вендорская смета — устаревшая цена, а не стоимость. Баланс прав, что код ничего не стоит. Непризнанным остаётся другое: спецификация, данные и люди, которые умеют. Отсюда и ответ: признавать нечего, раскрывать есть что.

Что будет со стандартом

Совет по МСФО с 2024 года ведёт проект по пересмотру IAS 38. По итогам первичного исследования желающих расширять признание оказалось мало; в мае 2026-го обсуждали, какая информация о непризнанных нематериальных активах нужна пользователям отчётности. Скорее всего, итогом станут не новые активы на балансе, а требования к раскрытию. Это правильное направление, и наше предложение в него ложится: не трогать признание, а добавить в IAS 38 требование раскрывать существенный непризнанный внутренне созданный софт — качественно, с описанием зависимости и поддержки, и количественно как поток избежавших затрат за период. Случай с ИИ-инструментами — хороший тест для проекта: все шесть критериев признания выполнены, а единственная дата, которую можно указать, — начало использования. С неё начинается амортизация, а не накопление затрат. Сумма к капитализации стремится к нулю.

Пока стандарт догоняет практику, вопрос остаётся у финансового директора. И он не про учёт.

Посмотрите, что делает сотрудник отдела МСФО. Сопоставляет план счетов со статьями отчётности. Статьи — с бюджетом. Статьи — с управленческим учётом. Читает каждый договор и относит его на правильную статью. Почти всё это — алгоритм, который теперь можно описать словами и получить работающий инструмент. Что остаётся человеку? Посмотреть на отчётность целиком и понять, где есть место для оптимизации, какие затраты переклассифицировать, где узкие места. И подписать. Машина не подписывает.

В компании остаются три типа людей: те, кто строит инструменты, — бывшие пользователи; те, кто несёт суждение и ответственность; и те, кто обслуживает машины — данные, доступы, периметр. Баланс не увидит ни первых, ни вторых, ни того, что они сделали. И это нормально: баланс никогда и не брался измерять людей — их суждение, опыт, ответственность всегда жили за его пределами. Новое в том, что рядом с ценностью людей появилась ещё одна реальность — ИИ, который превращает их знание в работающие инструменты за часы. Стандарт здесь ни в чём не виноват. Просто то, что раньше было отдельным активом, стало продолжением ценности сотрудника.

Об авторах

Александр Минченков — финансовый директор финтех-группы «Свой» (до 2026 года — IDF Eurasia). В группу входят Свой Банк, инвестиционная компания «Свой Капитал», сервисы альтернативного кредитования Moneyman и Platiza, сервис по работе с проблемной задолженностью ID Collect, страховщик «Кредит Европа Лайф» и ИТ-кластер «Свой Тех».

Петр Мамруков — независимый консультант по управлению изменениями, архитектор ИИ-решений. Помогает компаниям внедрять автоматизацию на базе ИИ в финансовых и операционных функциях; в группе «Свой» сопровождает кейсы, описанные в статье. Более 20 лет в управлении технологиями, включая позиции CIO и CTO в страховании, фармацевтике и аудите. mamrukov.com