Вы только что потратили $180 000 на создание заказного программного обеспечения для своего бизнеса. Ваш разработчик называет это инвестицией. Ваш бухгалтер называет это расходом. Ваш налоговый консультант говорит, что ответ — «и то, и другое, но в разных отчётностях». Все трое могут быть правы одновременно — и выбор неправильного подхода может завысить вашу прибыль на шестизначную сумму, спровоцировать корректировку при проверке или незаметно нарушить ковенант по кредиту.
Решение о капитализации или отнесении на расходы — одно из наиболее ответственных суждений в бухгалтерском учёте малого бизнеса. Капитализируйте затраты — и они попадут в ваш баланс как актив, а затем постепенно проявятся в отчёте о прибылях и убытках как амортизация в течение нескольких лет. Отнесите их на расходы — и вся сумма сразу уменьшит прибыль текущего года. Тот же отток денежных средств, но совершенно иная финансовая отчётность.
Это руководство разбирает правила, регулирующие разработку ПО, подписки SaaS и расходы на облачную инфраструктуру — ASC 350-40, ASC 985-20 и руководство по облачным вычислениям — а также показывает, где налоговые правила расходятся с вашими книгами.
Почему это решение так сильно влияет на ваши показатели
Капитализация распределяет признание затрат на будущее. Отнесение на расходы признаёт их сейчас. Эта разница во времени отражается на всём, что важно для читателя вашей отчётности:
- Прибыль и EBITDA. Капитализация $180 000 затрат на разработку вместо отнесения их на расходы добавляет $180 000 к прибыли до налогообложения текущего года (за вычетом небольшой амортизации первого года). EBITDA вырастает почти на всю сумму, поскольку амортизация прибавляется обратно.
- Ковенанты по кредитам. Многие кредитные соглашения малого бизнеса устанавливают минимальные коэффициенты покрытия обслуживания долга или прибыльности. Агрессивная капитализация может создать видимость соблюдения условий у испытывающего трудности заёмщика — пока проверка банка это не обнаружит.
- Оценка стоимости. Покупатели и инвесторы нормализуют прибыль с учётом капитализированного ПО. Непоследовательная политика приводит к снижению цены покупки в ходе комплексной проверки.
- Налоги. Ваши книги и налоговая декларация здесь следуют разным сводам правил. Разрыв между ними создаёт отложенные налоговые активы и обязательства, которые необходимо отслеживать, а ошибка в налоговой части означает штрафы за недоплату.
Ничто из этого не является причиной бояться этого решения. Это причина принимать его осознанно, документировать и применять последовательно.
Три учётных подхода к затратам на ПО
US GAAP не содержит единого правила для ПО. Их три, и первый шаг — определить, к какому из них относятся ваши расходы.
Подход 1: ПО внутреннего использования (ASC 350-40)
ПО, которое вы создаёте или покупаете для ведения собственного бизнеса — внутренняя панель управления, заказная система обработки заказов, скрипты автоматизации, портал для сотрудников — подпадает под ASC 350-40. Это подход, в котором живёт большинство малых предприятий. Даже ПО, которое вы продаёте клиентам как хостинговую услугу (SaaS), как правило, учитывается как ПО внутреннего использования, поскольку клиент никогда не получает права владения кодом.
ASC 350-40 делит каждый проект на три стадии, и именно стадия определяет учёт:
Стадия 1 — Предварительная стадия проекта: всё относится на расходы. Оценка поставщиков, сравнение вариантов «создать или купить», выбор технологии и работы по оценке осуществимости относятся на расходы по мере возникновения. Если вы платите консультанту $15 000 за определение объёма проекта и рекомендацию платформы, эти $15 000 — расход, и точка.
Стадия 2 — Стадия разработки приложения: капитализируются квалифицируемые затраты. Как только предварительная стадия завершена, руководство приняло решение финансировать проект и завершение вероятно, начинается капитализация. К капитализируемым затратам относятся:
- Заработная плата и связанные с ней расходы сотрудников, непосредственно работающих над проектом (пропорционально затраченному времени)
- Плата внешним разработчикам и подрядчикам за проектирование, программирование, конфигурирование и тестирование
- Стоимость ПО, приобретённого специально для проекта
- Затраты на преобразование данных, когда преобразование выполняется ПО, разработанным для этой цели
- Процентные расходы, понесённые в период разработки ПО, если они существенны
Затраты на обучение всегда относятся на расходы, даже если они понесены на этой стадии. То же касается общих административных накладных расходов и затрат, которые нельзя обоснованно связать с проектом.
Стадия 3 — После внедрения и эксплуатация: всё снова относится на расходы. Обучение, сопровождение, исправление мелких ошибок и текущая поддержка после ввода ПО в эксплуатацию относятся на расходы. Исключение: модернизация или усовершенствование, добавляющее функциональность, может возобновить капитализацию для этой новой работы, следуя тому же анализу трёх стадий.
Капитализированное ПО внутреннего использования амортизируется в течение срока его полезного использования — как правило, от трёх до пяти лет для большинства бизнес-приложений — начиная с момента, когда ПО готово к использованию по назначению.
Подход 2: ПО для продажи, сдачи в аренду или продвижения (ASC 985-20)
Если вы создаёте ПО, которое продаёте как продукт — загружаемое приложение, лицензируемое локальное ПО, игру — применяется ASC 985-20. Здесь разделительная линия — один рубеж: технологическая осуществимость. Все затраты до этой точки являются исследованиями и разработками и относятся на расходы по мере возникновения. Затраты после достижения осуществимости, но до общего выпуска, капитализируются. Сопровождение после выпуска относится на расходы.
На практике многие гибкие команды достигают технологической осуществимости очень поздно — иногда с рабочей моделью, появляющейся за считанные дни до выпуска — поэтому капитализировать почти нечего. Это законный результат, а не неудача в капитализации. Принудительное отнесение затрат в актив, когда осуществимость никогда чётко не устанавливалась, — одна из наиболее частых причин пересмотра отчётности в компаниях-разработчиках ПО.
Подход 3: Соглашения об облачных вычислениях (ASU 2018-15)
Облачные сделки бывают двух видов, и учёт зависит от одного вопроса: включает ли договор лицензию на ПО или это чисто услуга?
- Соглашение включает лицензию (вы могли бы получить во владение ПО и запускать его самостоятельно): учитывайте лицензию как ПО внутреннего использования по ASC 350-40, а связанные затраты относите на расходы или капитализируйте по модели трёх стадий.
- Договор чисто на услуги (типичные соглашения SaaS, хостинга и инфраструктуры): абонентская плата и плата за использование являются операционными расходами. Но затраты на внедрение — конфигурирование, настройка, работы по интеграции, миграция данных — оцениваются по ASC 350-40 по аналогии. Работы по внедрению на стадии разработки приложения капитализируются и амортизируются в течение срока хостинга (включая продления, которые вы разумно уверены, что возьмёте). Оценка на предварительной стадии и поддержка после внедрения относятся на расходы.
Это застаёт многие предприятия врасплох в обе стороны. Некоторые относят на расходы внедрение ERP стоимостью $60 000, которое правила предписывают капитализировать. Другие капитализируют трёхлетнюю абонентскую плату SaaS, которая явно является операционным расходом. Абонентская плата почти никогда не является активом; разовые работы по запуску системы — часто являются.
А как насчёт подписок и счетов за облачную инфраструктуру?
Примените изложенную выше схему к статьям типичного счёта за технологии:
| Затрата | Обычный учёт | Почему |
|---|---|---|
| Ежемесячная подписка SaaS (без лицензии) | Расход | Договор на услуги; вы платите за доступ, а не за актив |
| Плата за использование AWS, Azure или хостинга | Расход | Потребление услуг с оплатой по факту использования |
| Внедрение и конфигурирование ERP или SaaS | Часто капитализируется | Работы на стадии разработки приложения по ASU 2018-15 |
| Заказные интеграции и коннекторы API, которые вы создаёте | Часто капитализируется | Разработка ПО внутреннего использования |
| Скрипты миграции данных | Капитализировать, если управляются ПО | Правило ASC 350-40 о преобразовании данных |
| Обучение персонала работе с новой системой | Расход | Обучение всегда относится на расходы |
| Планы текущей поддержки и сопровождения | Расход | Стадия после внедрения |
| Новый модуль, добавляющий функциональность год спустя | Капитализировать новую работу | Усовершенствование возобновляет анализ стадий |
Две серые зоны заслуживают особого внимания. Во-первых, конфигурирование против настройки: переключение настроек в панели администратора SaaS редко подлежит капитализации, тогда как написание заказного кода или сложных скриптов интеграции обычно подлежит. Документируйте, какие часы к чему относились. Во-вторых, срок хостинга для амортизации: амортизируйте капитализированные затраты на внедрение в течение периода, в который вы рассчитываете пользоваться услугой, включая продления, которые вы разумно уверены, что возьмёте — а не в течение какого-то теоретического срока службы ПО.
Обновление 2025 года, которое меняет стадии
В сентябре 2025 года FASB выпустил ASU 2025-06, который упраздняет трёхстадийные обозначения для ПО внутреннего использования в пользу единого порога: капитализируйте затраты, как только руководство приняло решение финансировать проект и завершение вероятно. Обновление обязательно для годовых периодов, начинающихся после 15 декабря 2027 года, с разрешённым досрочным применением.
Для большинства малых предприятий практический эффект скромен — разделительная линия проходит примерно там же, где сегодня находится граница между предварительной стадией и стадией разработки — но новый стандарт сигнализирует, что больше затрат на гибкую, итеративную разработку будут квалифицироваться. Если ваша команда работает спринтами, а не по каскадным фазам, поговорите со своим CPA о досрочном применении. До тех пор продолжайте применять модель трёх стадий и ведите документацию по стадиям, которую ожидает ваш аудитор.
Ваша налоговая декларация играет по другим правилам
Вот где владельцы обжигаются: учёт по GAAP в ваших книгах и налоговый учёт в вашей декларации регулируются совершенно разными сводами правил, и они часто не совпадают.
Для налоговых лет, начинающихся после 31 декабря 2021 года, Закон о сокращении налогов и рабочих местах требовал от предприятий капитализировать внутренние расходы на исследования и эксперименты — явно включая разработку ПО — и амортизировать их в течение пяти лет (пятнадцати для зарубежных исследований). Это превратило «мы потратили $200 000 на разработчиков» из текущего вычета в вычет первого года в размере $20 000, а остальное растянулось на пять лет.
Закон One Big Beautiful Bill Act, подписанный в 2025 году, восстановил немедленное отнесение на расходы внутренних затрат на исследования и эксперименты, задним числом с налоговых лет, начинающихся в 2025 году, и уточнил, что разработка ПО учитывается. У малых предприятий, как правило, есть переходные варианты для неамортизированных остатков 2022–2024 годов — ускорить оставшуюся часть или продолжать её амортизировать. Зарубежные расходы на исследования остаются на пятнадцатилетнем графике.
Практические последствия:
- У вас будут различия между книжным и налоговым учётом. GAAP может требовать капитализации затрат на внедрение, которые ваша налоговая декларация относит на расходы немедленно, или наоборот. Отслеживайте оба подхода параллельно; от этого зависят ваши налоговые резервы и Schedule M-1.
- Соответствие на уровне штатов различается. Не каждый штат следует федеральному восстановлению, поэтому затрата, отнесённая на расходы на федеральном уровне, может по-прежнему амортизироваться для целей штата.
- Документация служит двум хозяевам. Учёт времени по фазам проекта одновременно поддерживает ваш анализ стадий по GAAP и вашу заявку на исследовательский кредит по разделу 41. Одна хорошая система питает оба.
Налоговое законодательство меняется достаточно быстро, чтобы любое подобное руководство было лишь снимком. Подтвердите правила текущего года со своим специалистом до подачи — и никогда не позволяйте налоговому хвосту вилять бухгалтерской собакой. Ваша финансовая отчётность должна следовать GAAP независимо от того, что делает налоговая декларация.
Пять ошибок, которые вызывают корректировки
- Капитализация стадии оценки. Демонстрации поставщиков, запросы предложений и консультации «создавать или покупать» — это затраты предварительной стадии. Отнесение их на расходы не является опцией.
- Капитализация обучения. Каждый стандарт однозначен: обучение относится на расходы, даже в ходе разработки приложения. Выделяйте его отдельно из счетов за внедрение.
- Забыли остановиться. Капитализация прекращается, когда ПО готово к использованию по назначению — а не когда приходит последний счёт. Часы подрядчиков после ввода в эксплуатацию являются сопровождением, пока не начнётся подлинное усовершенствование.
- Капитализация абонентской платы. Трёхлетний предоплаченный контракт SaaS — это предоплаченный расход, который амортизируется по мере потребления услуги, а не актив ПО. Не проводите его через ASC 350-40.
- Отсутствие учёта рабочего времени. Капитализированная заработная плата без одновременного учёта времени по проектам и стадиям — первое, что отклоняет аудитор или проверяющий. Оценки, восстановленные в конце года, редко выдерживают проверку.
Практический контрольный список капитализации
Прежде чем отнести любые затраты на ПО к активу, ответьте на эти вопросы письменно и подшейте служебную записку к материалам проекта:
- Какой подход применяется — внутреннее использование (350-40), ПО для продажи (985-20) или договор на облачную услугу?
- Закончилась ли предварительная стадия — принято ли решение о финансировании и вероятно ли завершение?
- Является ли ПО по существу завершённым и готовым к использованию? Если да, капитализация прекратилась.
- Является ли эта затрата обучением, сопровождением, вводом данных или общими накладными расходами? Если да, отнесите её на расходы.
- Можете ли вы привязать каждый капитализированный доллар к табелю, счёту или техническому заданию подрядчика?
- Какой период амортизации отражает ожидаемый срок полезного использования (или срок хостинга для затрат на внедрение)?
- Записали ли вы налоговый учёт отдельно, включая любое различие между книжным и налоговым учётом?
Короткая служебная записка с ответами на эти семь вопросов пишется за двадцать минут и может сэкономить недели споров с аудитором, банковским инспектором или IRS.
Держите свои расходы на ПО готовыми к проверке
Каждый счёт от ваших разработчиков, поставщиков SaaS и облачного провайдера — это решение о классификации, которое ждёт своего часа. Предприятия, которые делают это правильно, объединены одной привычкой: они отслеживают затраты на ПО по проектам и стадиям по мере оттока денег, а не когда CPA спрашивает об этом двенадцать месяцев спустя. Помечайте часы внедрения отдельно от часов поддержки, выделяйте обучение из технических заданий поставщиков и ведите текущую записку о том, на какой стадии находится каждый проект.
Чистые записи также делают разделение книжного и налогового учёта управляемым. Когда ваш регистр уже разделяет капитализированную разработку и отнесённые на расходы подписки, подготовка декларации — и её защита — становится делом формирования отчёта, а не восстановления года.
Beancount.io предоставляет вам учёт в виде простого текста, который делает каждую из этих классификаций прозрачной, версионируемой и готовой для ИИ — так что ваша политика капитализации живёт в ваших книгах, а не в электронной таблице, которую никто не может найти. Начните бесплатно и узнайте, почему разработчики и финансисты переходят на учёт в виде простого текста.
