ASC 350-40: Капитализация или расходы на внутреннее ПО

ASC 350-40 — тема кодификации, которую ищущие часто набирают как 350/40 — это правило FASB для программного обеспечения внутреннего использования: когда затраты на разработку относятся на расходы сейчас, а когда капитализируются как нематериальный актив и амортизируются позже. В рамках устаревшей трехэтапной модели (которую большинство компаний все еще применяют до обязательной даты ASU 2025-06) ответ умещается в одну таблицу:

ASU 2025-06 (выпущен 18 сентября 2025 года; обязателен для годовых периодов, начинающихся после 15 декабря 2027 года) упраздняет эти этапные метки в пользу порога "вероятно к завершению" и сигнализирует о том, что больше затрат будет относиться на расходы. Разделы ниже охватывают то, что включает ASC 350-40, детали этапов, обновление 2025 года, чек-лист капитализации/расходов, а также влияние выбора на EBITDA и баланс.

Что охватывает 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: Этап разработки приложения​

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

Капитализируемые затраты на этом этапе обычно включают:

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

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

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

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

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

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

Изменение структурное: трехэтапная модель упразднена. FASB явно удалил все ссылки на этапы проекта, потому что устаревшая структура не соответствовала современным гибким и итеративным практикам разработки, где требования развиваются, а "этапы" пересекаются или выполняются параллельно.

Новый порог на основе принципов​

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

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

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

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

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

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

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

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

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

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

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

Обычно относится на расходы​

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

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

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

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

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

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

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

Вот почему капитализация улучшает 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 по Разделу 174, у которого свои правила. Если ваши книги не разделяют капитализированные проекты и операционные расходы, не могут привязать затраты инженерного времени к конкретным проектам или не ведут чистые графики амортизации, каждый цикл аудита и должной осмотрительности станет болезненным.

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

Поддерживайте бухгалтерский учет ПО готовым к аудиту​

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