Спросите руководителя разработки, когда «начался» проект, — и в ответ услышите номер спринта. Задайте тот же вопрос финансовому контролёру, и, согласно правилам учёта, регулирующим программное обеспечение для внутреннего использования с 1998 года, ответ должен был опираться на жёсткий трёхэтапный чек-лист, который исходит из того, что никто не пишет код, пока требования не зафиксированы окончательно. Любой, кто выпускал программные продукты за последнее десятилетие, знает, что на практике всё давно работает иначе — и в сентябре 2025 года это наконец признал и сам FASB.
Обновление стандартов учёта (ASU) 2025-06, «Нематериальные активы — гудвил и прочее — программное обеспечение для внутреннего использования (подраздел 350-40): точечные усовершенствования учёта программного обеспечения для внутреннего использования», полностью отменяет прежний пофазный тест и заменяет его одним вопросом, требующим профессионального суждения: вероятно ли, что это программное обеспечение будет действительно завершено и будет выполнять свою предназначенную функцию? Для любой компании, разрабатывающей программное обеспечение собственными силами, — и особенно для agile-команд, под которые старое правило никогда не было рассчитано, — это меняет момент, когда затраты на разработку переходят из отчёта о прибылях и убытках в баланс, а также величину этих затрат.
Проблема: свод правил 1998 года для каскадной разработки
Руководство, которое заменяет ASU 2025-06, — ASC 350-40 (изначально SOP 98-1), — было написано в те времена, когда «разработка программного обеспечения» означала линейный каскадный (waterfall) процесс. Оно делило каждый проект по разработке ПО для внутреннего использования на три последовательных этапа:
- Этап предварительной подготовки проекта — формулирование концепции, оценка альтернатив, выбор поставщика. Все затраты на этом этапе списываются на расходы по мере возникновения.
- Этап разработки приложения — непосредственно написание кода, конфигурация и тестирование. Затраты на этом этапе капитализируются.
- Этап после внедрения — обучение и сопровождение. Затраты снова списываются на расходы.
Эта схема прекрасно работает, если команда три месяца пишет документ с требованиями, получает согласование и только потом начинает разработку. Но она рассыпается в тот момент, когда команда работает двухнедельными спринтами, выпускает инкрементальные релизы и пересматривает объём работ на каждом ретро. В agile-среде «предварительный этап» и «этап разработки приложения» — это не последовательные фазы, а переплетённые процессы, иногда происходящие в рамках одного и того же спринта. Компании и их аудиторы годами спорили о том, к какому этапу на самом деле относится тот или иной двухнедельный спринт, и честный ответ часто звучал как «понемногу и то, и другое — мы гадаем». Собственные консультации FASB с заинтересованными сторонами показали, что они регулярно называют это одной из самых болезненных с операционной точки зрения частей GAAP, которую сложно применять последовательно.
Решение: один тест вместо трёх этапов
ASU 2025-06 устраняет все упоминания прежних этапов проекта. Вместо них устанавливается единый порог признания «вероятности завершения». Согласно новому руководству, компания капитализирует затраты на программное обеспечение для внутреннего использования, как только одновременно выполняются оба следующих условия:
- Руководство утвердило проект и взяло на себя обязательство его финансировать. Это не новая концепция — она существовала и в прежнем руководстве, — но теперь она играет куда более значимую роль, будучи одним из всего двух отсекающих условий, а не погребённой внутри анализа этапов.
- Вероятно, что проект будет завершён, а программное обеспечение будет использоваться по своему прямому назначению. Это по-настоящему новый элемент, и именно здесь требуется профессиональное суждение.
Второй критерий требует оценки того, сохраняется ли всё ещё существенная неопределённость в разработке. FASB указывает на два основных источника такой неопределённости:
- Непроверенная технология или принципиально новая функциональность, реализуемость которой ещё не подтверждена реальным написанием кода и тестированием — не проектной документацией, не спецификацией, а работающим доказательством.
- Неопределённые или всё ещё меняющиеся требования к функциональности — стандарт определяет их как «то, что организации нужно от программного обеспечения, например функции или возможности». Если команда всё ещё содержательно спорит о том, что должен делать продукт, эта неопределённость не разрешена.
На практике это означает, что момент начала капитализации теперь определяется доказательством реализуемости, а не календарной фазой. Команда, которая в течение двух спринтов исследует («спайкует») технически новую функцию, прежде чем взять на себя обязательство серьёзно её разрабатывать, спишет затраты этих спринтов-исследований на расходы — неопределённость в том, возможно ли вообще это реализовать, ещё не разрешена. Как только исследование подтверждает реализуемость и руководство выделяет бюджет на полноценную разработку, порог «вероятности завершения» считается достигнутым, и последующие затраты на разработку капитализируются — независимо от agile-ритуалов.
Почему FASB считает, что капитализация почти не изменится — кроме как для SaaS
Собственные ожидания FASB состоят в том, что для большинства локально устанавливаемого или лицензионного программного обеспечения для внутреннего использования поправки не приведут к резким изменениям в капитализации: компании и раньше начинали капитализировать затраты, как только стартовало реальное написание кода, а новый тест приводит примерно к тому же результату — просто без упражнения по навешиванию ярлыков этапов.
С программным обеспечением, разрабатываемым для поставки по модели SaaS или через облачную схему, дело обстоит иначе. FASB прямо ожидает снижения капитализации по таким проектам. Логика такова: SaaS-продукты по своей природе непрерывно создаются и пересоздаются, а существенная техническая и продуктовая неопределённость сохраняется вплоть до поздних стадий разработки — иногда почти до самого момента выпуска функции. При тесте на «вероятность завершения» такая устойчивая неопределённость означает, что многие затраты на разработку SaaS-продуктов преодолеют порог капитализации значительно позже в ходе разработки, чем предполагала бы старая пофазная модель. Итоговый эффект: большая часть расходов на оплату труда инженеров по SaaS-продукту попадает в текущие расходы на НИОКР, а не становится активом, амортизируемым в течение нескольких лет. Это существенный сдвиг в отчётных показателях EBITDA и величине активов любой SaaS-компании — ещё до того, как изменится хоть одна строка реального кода.
Конкретный пример: две команды, два результата
Предположим, SaaS-компания из 40 человек решает создать для своего продукта модуль прогнозирования на основе ИИ. Вот как старые и новые правила по-разному отнеслись бы к одной и той же восьмимесячной разработке.
По старой пофазной модели финансовая команда попыталась бы провести черту: первые шесть недель сбора требований и оценки поставщиков считались «предварительным этапом» (списывались на расходы), а всё, что происходило после установочной встречи, — «этапом разработки приложения» (капитализировалось), — даже несмотря на то, что следующие два месяца инженерная команда потратила на исследовательские спайки, чтобы понять, способен ли выбранный подход к прогнозированию обеспечить приемлемую точность при промышленных объёмах данных. По букве старого правила, как только «этап» менялся, эти спринты-исследования тоже нередко капитализировались — просто потому, что формально они происходили после установочной встречи.
По ASU 2025-06 финансовая команда вместо этого задаёт вопрос: когда стало вероятно, что эта функция будет завершена и будет работать так, как задумано? Если подход к достижению точности оставался непроверенным первые два месяца — команда тестировала три разных подхода к моделированию и не знала, преодолеет ли хоть один из них планку, — весь этот период исследований списывается на расходы, независимо от того, к какому «этапу» по календарю он относился. Капитализация начинается только тогда, когда команда выбирает подтверждённый подход, а руководство выделяет бюджет на его реализацию, — в этом примере это может быть третий месяц, а не второй. Результат: меньший капитализированный актив, больший текущий расход на НИОКР и, что важно, показатель, который финансовый директор действительно сможет защитить при аудите, поскольку он привязан к конкретной, документально зафиксированной точке принятия решения, а не к ярлыку этапа, присвоенному задним числом.
Именно такого сдвига FASB и ожидает во всём секторе SaaS: меньше аргументов вида «мы назвали это этапом разработки приложения, потому что это произошло после установочного звонка» и больше конкретики вида «мы можем точно указать спринт, в котором технический риск был снят».
Даты вступления в силу и переход на новый стандарт
ASU 2025-06 вступает в силу для всех организаций — публичных и частных — начиная с годовых отчётных периодов, начинающихся после 15 декабря 2027 года, а также промежуточных периодов внутри этих лет. Досрочное применение разрешено для любой организации, в любом промежуточном или годовом периоде, с момента публикации стандарта.
Организации могут применять поправки одним из трёх переходных способов: перспективно — только к новым затратам на ПО, понесённым после даты вступления в силу; перспективно — к затратам, понесённым с начала года применения стандарта или позднее; либо ретроспективно — ко всем представленным периодам. Эта гибкость важна: компании, находящейся в середине масштабного переписывания платформы на момент вступления правила в силу, не придётся распутывать многолетнюю историю капитализированных затрат, если только она сама не выберет ретроспективный вариант.
Что делать небольшим и средним софтверным компаниям уже сейчас
Декабрь 2027 года звучит как далёкое будущее, но практическая подготовка — это не задача на последний квартал, особенно для компаний с небольшими финансовыми командами без выделенной функции технического учёта.
Начните документировать суждение о «вероятности завершения» в реальном времени, а не задним числом. Старая пофазная модель была механической — можно было восстановить, на каком этапе находился проект, спустя месяцы, просто по датам спринтов. Новый тест спрашивает когда мы перестали быть технически неуверены, а это суждение гораздо сложнее восстановить постфактум. Заведите простую привычку уже сейчас: когда руководство разработки и финансовая команда сходятся во мнении, что функция прошла технический спайк и утверждена к разработке, фиксируйте эту дату. Этот журнал станет вашей датой начала капитализации и опорой при аудите.
Разделяйте работу над «исследованием» и работу над «утверждённой разработкой» в учёте времени или кодах проектов, если вы ещё этого не делаете. Будь то флаг эпика в Jira, отдельный код центра затрат или просто метка в инструменте учёта времени — наличие чёткого следа данных о том, когда функция перешла от спайка/прототипа к утверждённой разработке, сделает применение нового стандарта заметно менее болезненным, чем попытка восстановить это по памяти во время аудита.
Смоделируйте оба варианта перехода, прежде чем выбрать один. Если ваша компания агрессивно капитализировала затраты на разработку SaaS-продуктов по старой пофазной модели, ретроспективное применение может привести к единовременному списанию ранее капитализированных активов, поскольку эти затраты будут реклассифицированы так, как если бы изначально списывались на расходы. Перспективный подход позволяет избежать такого пересчёта, но означает, что отчёт о прибылях и убытках не отразит новую методологию, пока после перехода не начнутся новые проекты. Просчитайте оба сценария заранее — до того, как это придётся делать вашему комитету по аудиту.
Обсудите вопрос с аудитором заранее, особенно если вы работаете по модели SaaS. Учитывая собственные ожидания FASB по снижению капитализации для SaaS-разработки, аудиторы, вероятно, будут проверять суждения о «вероятности завершения» тщательнее, чем прежде проверяли классификацию по этапам, — именно потому, что это суждение более субъективно. Компании, которая приходит на аудит 2028 года с задокументированной, ведущейся в реальном времени системой для таких решений, будет заметно проще, чем той, что восстанавливает всё задним числом.
Чистая отчётность облегчает защиту суждений
Любое суждение в учёте — а «вероятность завершения» это именно суждение — защитимо ровно настолько, насколько защитимы стоящие за ним записи. Если ваш план счетов уже разделяет расходы на НИОКР по проектам, а записи в регистре версионируются и доступны для проверки, а не разбросаны по несвязанным таблицам, применение такого стандарта, как ASU 2025-06, сводится к разметке уже существующих данных, а не к восстановлению истории по переписке в Slack. Учёт в формате обычного текста от Beancount.io по умолчанию даёт вам именно такой прозрачный, версионируемый через git регистр — каждая запись отслеживаема, каждое изменение можно проверить, без привязки к конкретному поставщику. Начните бесплатно и ведите учёт, который выдержит проверку — будь то вопрос от аудитора, покупателя компании или очередного обновления FASB.