Капитализация программного обеспечения согласно ASC 350-40: Практическое руководство по выбору между капитализацией и расходами

Опрос Gartner 2024 года показал, что 63% основателей SaaS-стартапов на ранних стадиях неправильно классифицируют затраты на разработку программного обеспечения (ПО). Эта ошибка обходится им дорого по двум направлениям: инвесторы дисконтируют их финансовые показатели, когда классификация выглядит небрежной, а аудиторы отмечают проблему в ходе проверки (due diligence), что может задержать раунды финансирования или процессы продажи на месяцы.

Капитализация ПО — это не просто технический нюанс бухгалтерского учета. Она напрямую влияет на EBITDA, балансовый отчет и то, как ваш бизнес выглядит в глазах кредиторов, инвесторов и покупателей. Правила ASC 350-40 — и важное обновление 2025 года — определяют, какие расходы попадают в отчет о прибылях и убытках немедленно, а какие распределяются на годы.

Это руководство подробно описывает требования стандарта, недавние изменения в ASU 2025-06, затраты, которые можно капитализировать, затраты, которые нельзя, и последствия правильного учета для финансовой отчетности.

Что охватывает стандарт ASC 350-40

ASC 350-40 — это стандарт FASB для программного обеспечения для внутреннего использования — ПО, которое ваша компания создает или покупает для собственных нужд, а не для продажи клиентам в качестве основного продукта. Примеры включают:

• Внутренние системы CRM, ERP, HR или бухгалтерского учета
• Инструменты облачной инфраструктуры и платформы DevOps
• SaaS-платформа, которую вы эксплуатируете для клиентов (клиент получает доступ к ней как к услуге, а не как к лицензионному ПО, которое он устанавливает)
• Внутренние конвейеры данных, дашборды и инструменты аналитики
• Индивидуальная автоматизация рабочих процессов или бэк-офиса

Если вы продаете лицензионное ПО, которое клиенты устанавливают на свои собственные машины, это подпадает под действие стандарта ASC 985-20 (ПО для внешней продажи), который имеет другие правила. Большинство современных SaaS-компаний подпадают под ASC 350-40, так как клиенты используют ПО как облачный сервис.

Основной вопрос, на который отвечает стандарт: когда вы тратите деньги на создание ПО, следует ли списывать эти расходы немедленно или капитализировать их как нематериальный актив и амортизировать в будущих периодах?

Старая трехэтапная модель (до ASU 2025-06)

На протяжении десятилетий в ASC 350-40 использовалась структура, основанная на этапах. Согласно устаревшим рекомендациям, которые все еще действуют для большинства компаний до 2027 года, разработка ПО делится на три отдельных этапа.

Этап 1: Предварительный этап проекта

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

Мероприятия на этом этапе включают:

• Формулирование концепции и проектирование альтернатив
• Демо-версии поставщиков и оценка технологий
• Анализ затрат и выгод и технико-экономическое обоснование
• Окончательный выбор подхода или поставщика

Этап 2: Этап разработки приложения

Капитализация начинается, когда руководство санкционирует проект, выделяет финансирование и вероятность завершения проекта высока. Этот этап охватывает непосредственное создание — написание кода, тестирование, конфигурацию, интеграцию и установку.

Затраты, подлежащие капитализации на этом этапе, обычно включают:

• Заработную плату и льготы для разработчиков, инженеров QA и менеджеров проектов (только то время, которое напрямую относится к кодированию, тестированию и настройке ПО)
• Гонорары внешних консультантов за работы по разработке
• Лицензии на ПО и инструменты, используемые для создания приложения
• Прямые затраты на материалы и услуги, потребленные при разработке
• Процентные расходы (в ограниченных случаях)

Капитализация прекращается, когда программное обеспечение существенно завершено и готово к использованию по назначению — как правило, когда тестирование закончено и система развернута в производственной среде, даже если внедрение происходит постепенно.

Этап 3: Поствнедренческий этап

После ввода в эксплуатацию текущие затраты снова переводятся в разряд расходов. Обучение, техническое обслуживание, исправление ошибок и рутинная поддержка — все это списывается в расходы. Исключение: улучшения, которые добавляют новую функциональность (а не просто исправляют или поддерживают существующую), могут быть капитализированы по тем же критериям, что и на этапе 2.

Крупное обновление 2025 года: ASU 2025-06

18 сентября 2025 года FASB выпустил обновление ASU 2025-06, которое значительно модернизирует ASC 350-40. Обновление является обязательным для годовых периодов, начинающихся после 15 декабря 2027 года, при этом допускается досрочное применение.

Изменение носит структурный характер: трехэтапная модель упразднена. FASB явно удалил все ссылки на этапы проекта, поскольку старая структура не соответствовала современным гибким (agile) и итеративным методам разработки, где требования развиваются, а «этапы» перекрываются или выполняются параллельно.

Новый порог, основанный на принципах

Согласно пересмотренному стандарту, вы капитализируете затраты на ПО только при соблюдении обоих следующих условий:

1. Санкционирование руководством: Руководство санкционировало проект и обязалось его финансировать.
2. Порог вероятности завершения: Вероятно, что проект будет завершен и программное обеспечение будет выполнять предназначенную ему функцию.

Этот второй тест является ключевым. FASB ввел понятие значительной неопределенности разработки для оценки вероятности завершения. Вы должны оценить:

• Содержит ли ПО новые или недоказанные функции, которые не были подтверждены в ходе кодирования или тестирования
• Остаются ли требования к производительности неопределенными или подлежат существенному пересмотру

Если существует значительная неопределенность, капитализация должна быть отложена до тех пор, пока неопределенность не будет разрешена. FASB дал понять, что ожидает от нового правила увеличения объема расходов на ПО, списываемых сразу, особенно в SaaS-компаниях, где требования постоянно меняются.

Что это означает на практике

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

Что можно и нельзя капитализировать: практический чек-лист

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

Обычно капитализируемые затраты

• Прямые затраты на оплату труда разработчиков, дизайнеров и специалистов по тестированию (QA) на этапе сборки
• Распределенные налоги на фонд оплаты труда и социальные выплаты для этих сотрудников
• Гонорары внешних консультантов и подрядчиков за работы по разработке
• Стоимость программного обеспечения, инструментов и облачной инфраструктуры, непосредственно использованных в процессе разработки
• Затраты на разработку нового функционала после запуска (улучшения, которые существенно расширяют возможности)
• Затраты на разработку ПО для конвертации (ПО, которое переносит старые данные в новые), в отличие от самой деятельности по миграции данных

Обычно списываемые на расходы затраты

• Предварительные исследования, выбор поставщиков и анализ осуществимости
• Обучение сотрудников работе с новой системой
• Очистка, сверка и миграция записей данных
• Регулярное обслуживание, исправление ошибок и незначительный рефакторинг
• Затраты на ПО, понесенные в периоды значительной неопределенности разработки
• Общие административные накладные расходы, не связанные напрямую с разработкой
• Маркетинг, поддержка и деятельность по обеспечению успеха клиентов (customer success) после запуска

Проблема учета времени

Самая большая практическая сложность заключается в распределении времени инженеров. Маловероятно, что ведущий инженер, работающий 40 часов в неделю, на 100% занят капитализируемой работой — он также занимается отладкой в продакшене, наставничеством, посещает планерки (standups) и проверяет пул-реквесты для устаревших систем. Без обоснованного метода учета времени (тикеты в Jira с тегами по проектам, ПО для тайм-трекинга или формальные опросы по распределению времени) оценки капитализации не пройдут аудиторскую проверку.

Влияние на финансовую отчетность

Капитализация и списание одной и той же суммы на расходы создают кардинально разную финансовую отчетность.

Влияние на отчет о прибылях и убытках

Капитализированные затраты не отражаются в отчете о прибылях и убытках в том периоде, когда они были понесены. Вместо этого они амортизируются — обычно линейным методом в течение трех-пяти лет для ПО внутреннего использования. Таким образом, капитализированные затраты на разработку в размере 1 млн долларов в первый год могут привести лишь к расходам на амортизацию в размере от 200 до 333 тыс. долларов в год, в результате чего операционная прибыль в первый год будет существенно выше.

Именно поэтому капитализация дает импульс показателю EBITDA. Амортизация по определению исключается из EBITDA, поэтому перевод большего объема затрат на разработку из операционных расходов (которые снижают EBITDA) в амортизацию (которая не снижает) улучшает показатель. Инвесторы, анализирующие метрики SaaS, часто смотрят на «EBITDA до капитализации R&D» или расчеты «Правила 40», используя денежные затраты на R&D, чтобы видеть реальную динамику.

Влияние на бухгалтерский баланс

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

• Увеличиваются совокупные активы и капитал
• Рентабельность активов (ROA) улучшается только в том случае, если прибыль растет быстрее базы активов
• Создается актив, который должен проверяться на обесценение в случае прекращения проекта или снижения его стоимости

Если проект заброшен на середине разработки, ранее капитализированные затраты должны быть списаны, что приводит к внезапному, часто существенному убытку. Это одна из причин, почему новый стандарт ASU 2025-06 уделяет такое внимание критерию «вероятности завершения».

Влияние на отчет о движении денежных средств

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

Распространенные ошибки, создающие проблемы для компаний

Аудиторы и покупатели бизнеса снова и снова сталкиваются с одними и теми же ошибками.

Капитализация предпроектных затрат

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

Отсутствие документации на уровне проектов

Если регулятор или аудитор попросит: «Покажите мне проекты, которые вы капитализировали», а вы сможете указать только на общие расходы на разработку, вы проиграете. Вам нужны записи по каждому проекту: объем работ, дата авторизации, бюджет, статус и затраченное время.

Отношение всего времени инженеров к капитализируемым затратам

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

Продолжение капитализации после запуска

Как только программное обеспечение готово к использованию по назначению, капитализация прекращается. Исправление ошибок, настройка производительности и незначительные улучшения после этого момента относятся к операционным расходам. Новые функции с отдельным объемом работ могут начать новый период капитализации, но рутинная работа после запуска — нет.

Пренебрежение тестом на обесценение

Капитализированное ПО является активом, а активы должны подвергаться проверке на обесценение, если их стоимость падает. Если вы консервируете продукт, прекращаете поддержку функции или фундаментально переписываете систему, вам необходимо провести переоценку и, скорее всего, списать предыдущий баланс.

Как настроить надежный процесс

Если вы решите, что капитализация подходит вашей компании, процесс важен не меньше, чем сама учетная политика.

1. Разработайте политику капитализации ПО. Определите, какие проекты подходят под критерии, опишите процедуру утверждения, оценку срока полезного использования и способ распределения времени. Согласуйте ее с финансовым директором или аудиторским комитетом.

2. Отслеживайте рабочее время инженеров на уровне проектов. Это базовые данные. Используете ли вы метки в Jira, пользовательские теги в системе управления проектами или официальные табели учета рабочего времени, вы должны уметь обосновать, что «инженер X потратил Y% своего времени на капитализируемую работу над проектом Z».

3. Документируйте одобрение руководства. Для каждого капитализируемого проекта необходимы доказательства авторизации — датированное письменное одобрение, протоколы заседаний совета директоров или устав проекта, подписанный руководством.

4. Регулярно проводите переоценку значительной неопределенности. Согласно новым правилам, вам нужно отслеживать, остаются ли функции инновационными или непроверенными, и стабилизируются ли требования. Ежеквартальные обзоры с техническим руководством являются разумной практикой.

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

6. Проверяйте на обесценение при изменении проектов. Каждый раз, когда вы отказываетесь от проекта, существенно переписываете его или прекращаете поддержку капитализированной работы, проводите анализ обесценения и отражайте списания по мере необходимости.

Почему это важно для бухгалтерии

Капитализация программного обеспечения — одна из тех областей, где дисциплина в ведении учета с первого дня окупается спустя годы. Инвесторы в ходе раунда Series B запросят вашу оборотную ведомость; покупатели в процессе сделки будут отслеживать транзакции до журнальных проводок; налоговая служба (IRS) может сравнить ваш учет по GAAP с налоговым режимом R&D согласно Section 174, у которого свои правила. Если в вашем учете капитализированные проекты не отделены от операционных расходов, затраты времени инженеров нельзя привязать к конкретным проектам или отсутствуют четкие графики амортизации, каждый аудит и цикл проверки (due diligence) становится мучительным.

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

Держите ваш учет ПО готовым к аудиту

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