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. Поріг ймовірності завершення: Ймовірно, що проєкт буде завершено, а програмне забезпечення виконуватиме свою передбачувану функцію.

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

• Чи включає програмне забезпечення нові або неперевірені функції, які не були підтверджені через кодування чи тестування
• Чи залишаються вимоги до продуктивності невизначеними або підлягають суттєвим переглядам

Якщо існує значна невизначеність, капіталізацію слід відкласти до моменту вирішення невизначеності. FASB сигналізував, що очікує, що нове правило призведе до списання більшої кількості витрат на програмне забезпечення, особливо в SaaS-компаніях, де вимоги постійно ітеруються.

Що це означає на практиці​

Для стартапу, який створює щось справді нове — платформу агентів ШІ, новий двигун автоматизації — нове правило може перенести більше витрат у операційні витрати раніше. Для зрілих компаній, які вдосконалюють чітко визначені системи, практичний вплив буде меншим. У будь-якому випадку, перехід від механічної перевірки етапів до принципового порогу означає, що компаніям потрібна чіткіша документація рішень керівництва, технічної здійсненності та статусу проєкту.

Що можна і що не можна капіталізувати: практичний контрольний список​

Незалежно від того, чи застосовуєте ви стару етапну модель, чи новий принциповий тест, межа між капіталізованими та витратними витратами схожа за духом. Ось робочий контрольний список.

Зазвичай капіталізується​

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

Зазвичай списується​

• Попереднє дослідження, вибір постачальника та аналіз техніко-економічного обґрунтування
• Навчання співробітників новій системі
• Очищення даних, звірка та міграція записів
• Рутинне обслуговування, виправлення помилок і незначний рефакторинг
• Витрати на програмне забезпечення, понесені в періоди значної невизначеності розробки
• Загальні адміністративні накладні витрати, не пов'язані безпосередньо з розробкою
• Маркетинг, підтримка та заходи щодо успіху клієнтів після запуску

Проблема обліку часу​

Найбільша практична проблема — розподіл інженерного часу. Старший інженер, який працює 40 годин на тиждень, навряд чи виконує 100% роботи, що капіталізується — він також налагоджує продакшн, наставляє колег, відвідує стендапи та перевіряє запити на злиття для старих систем. Без захищенного методу обліку часу (завдання інженерії, позначені за проєктами, програмне забезпечення для обліку часу або формальні опитування про розподіл), оцінки капіталізації не витримають аудиторської перевірки.

Вплив на фінансову звітність​

Капіталізація проти списання того самого долара створює кардинально різні фінансові звіти.

Вплив на звіт про прибутки та збитки​

Капіталізована вартість не потрапляє у звіт про прибутки та збитки в періоді витрат. Натомість вона амортизується — зазвичай лінійним методом протягом трьох-п'яти років для внутрішнього програмного забезпечення. Таким чином, капіталізовані витрати на інженерію в розмірі 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. Тестуйте на знецінення, коли проєкти змінюються. Щоразу, коли ви залишаєте, суттєво переписуєте або виводите з експлуатації капіталізовану роботу, проведіть аналіз знецінення та відобразіть списання за потреби.

Чому це важливо для бухгалтерського обліку​

Капіталізація програмного забезпечення — це одна з тих сфер, де дисципліна обліку з першого дня окупається роками пізніше. Інвестори під час раунду серії B перевірять ваш пробний баланс; покупці в процесі продажу простежать транзакції до бухгалтерських проводок; IRS може порівняти вашу обробку за GAAP з вашою податковою обробкою R&D за Розділом 174, яка має власні правила. Якщо ваші книги не відокремлюють капіталізовані проєкти від операційних витрат, не можуть прив'язати витрати інженерного часу до конкретних проєктів або не ведуть чисті графіки амортизації, кожен цикл аудиту та перевірки стає болісним.

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

Тримайте облік програмного забезпечення готовим до аудиту​

Чи капіталізуєте ви свою першу внутрішню платформу, чи ведете графіки амортизації для десятків проєктів, чисті фінансові записи є основою. Beancount.io надає бухгалтерський облік у відкритому текстовому форматі, який гарантує прозорі, версіоновані книги — кожна проводка простежувана, кожен рахунок перевіряється, кожен звіт відтворюваний. Для програмних компаній, які відстежують капіталізовану розробку в багатьох проєктах, наявність книг, які читаються як код, є серйозною перевагою. Почніть безкоштовно і побачте, чому розробники та фінансові професіонали переходять на бухгалтерський облік у відкритому текстовому форматі.