Капіталізація програмного забезпечення за 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 чітко видалила всі посилання на етапи проєкту, оскільки застаріла структура не відповідала сучасним методам гнучкої та ітеративної розробки, де вимоги еволюціонують, а "етапи" накладаються або виконуються паралельно.

Новий поріг на основі принципів

Згідно з переглянутим стандартом, ви капіталізуєте витрати на програмне забезпечення лише за умови дотримання обох таких умов:

1. Авторизація керівництвом: Керівництво санкціонувало проєкт і зобов'язалося його фінансувати.
2. Поріг імовірності завершення: Існує ймовірність того, що проєкт буде завершено, а програмне забезпечення виконуватиме свою призначену функцію.

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

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

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

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

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

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

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

Зазвичай підлягає капіталізації

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

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

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

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

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

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

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

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

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

Чому це важливо для бухгалтерії

Капіталізація програмного забезпечення — це одна з тих сфер, де дисципліна в веденні обліку з першого дня окупається роками пізніше. Інвестори під час раунду серії B перевірятимуть вашу оборотно-сальдову відомість; покупці в процесі придбання відстежуватимуть транзакції до журнальних записів; IRS може порівняти ваш облік за GAAP із податковим режимом для НДДКР згідно з Розділом 174, який має власні правила. Якщо ваші книги не відокремлюють капіталізовані проекти від операційних витрат, не можуть пов’язати витрати часу інженерів з конкретними проектами або не містять чітких графіків амортизації, кожен цикл аудиту та комплексної перевірки (due diligence) стає болючим.

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

Підтримуйте вашу бухгалтерію готовою до аудиту

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