Запитайте керівника розробки, коли проєкт «почався», — і почуєте номер спринту. Запитайте про те саме контролера, і за правилами обліку, які регулювали програмне забезпечення для внутрішнього використання з 1998 року, відповідь мала випливати з жорсткого триетапного чек-листа, що передбачає, ніби ніхто не пише код, поки вимоги не зафіксовані. Кожен, хто випускав програмне забезпечення за останнє десятиліття, знає, що так це вже не працює — і у вересні 2025 року FASB нарешті це визнала.
Оновлення стандартів бухгалтерського обліку (ASU) 2025-06, Нематеріальні активи — гудвіл та інше — програмне забезпечення для внутрішнього використання (Підрозділ 350-40): цільові вдосконалення обліку програмного забезпечення для внутрішнього використання, повністю відкидає стару поетапну модель тестування і замінює її єдиним питанням, що спирається на професійне судження: чи ймовірно, що це програмне забезпечення справді буде завершено і виконуватиме те, для чого призначене? Для будь-якої компанії, яка розробляє програмне забезпечення власними силами — і особливо для гнучких (agile) команд, під які старе правило ніколи не було розраховане, — це змінює момент, коли витрати на розробку переходять зі звіту про прибутки та збитки на баланс, і наскільки суттєво.
Проблема: посібник 1998 року для каскадної (waterfall) розробки
Настанова, яку замінює ASU 2025-06, — ASC 350-40 (спочатку SOP 98-1) — була написана тоді, коли «розробка програмного забезпечення» означала лінійний каскадний процес. Вона поділяла кожен проєкт програмного забезпечення для внутрішнього використання на три послідовні етапи:
- Попередній етап проєкту — концептуальне формулювання, оцінка альтернатив, вибір постачальника. Усе на цьому етапі списується на витрати в міру виникнення.
- Етап розробки застосунку — власне написання коду, налаштування та тестування. Витрати на цьому етапі капіталізуються.
- Етап після впровадження — навчання та підтримка. Знову списується на витрати.
Ця модель чудово працює, якщо команда три місяці пише документ із вимогами, отримує затвердження, а потім починає будувати. Вона розвалюється тієї миті, коли команда працює двотижневими спринтами, випускає інкрементальні релізи та переглядає обсяг роботи на кожному ретро. У гнучкому (agile) середовищі «попередній» етап і «розробка застосунку» — це не послідовні фази, а перемежовані процеси, іноді навіть у межах одного спринту. Компанії та їхні аудитори роками сперечалися, до якого етапу насправді належить конкретний двотижневий спринт, і чесна відповідь часто звучала як «трохи того й іншого, ми вгадуємо». Власні консультації FASB показали, що зацікавлені сторони постійно вказували на це як на одну з найбільш операційно болісних частин US GAAP, яку складно застосовувати послідовно.
Рішення: один тест замість трьох етапів
ASU 2025-06 прибирає будь-які згадки про старі етапи проєкту. Натомість він встановлює єдиний поріг визнання «ймовірності завершення». Згідно з новою настановою, компанія капіталізує витрати на програмне забезпечення для внутрішнього використання, щойно одночасно виконуються обидві умови:
- Керівництво санкціонувало проєкт і взяло на себе зобов'язання його фінансувати. Це не нова концепція — вона існувала і в старій настанові, — але тепер вона відіграє більшу роль, будучи однією з лише двох визначальних умов, а не похованою всередині аналізу етапів.
- Ймовірно, що проєкт буде завершено, а програмне забезпечення використовуватиметься для виконання свого призначеного функціоналу. Це справді нова складова, і саме тут потрібне професійне судження.
Цей другий критерій вимагає оцінити, чи досі існує суттєва невизначеність розробки. FASB вказує на два основні джерела такої невизначеності:
- Недоведена технологія або нова функціональність, здійсненність якої ще не підтверджена реальним написанням коду та тестуванням — не проєктним документом, не специфікацією, а робочим доказом.
- Невизначені або досі мінливі вимоги до функціонування — стандарт визначає їх як «те, що суб'єкт господарювання потребує від програмного забезпечення, наприклад функції або можливості». Якщо команда досі змістовно обговорює, що саме має робити продукт, ця невизначеність ще не усунена.
На практиці це означає, що момент капіталізації тепер визначається доказами здійсненності, а не календарною фазою. Команда, яка два спринти досліджує технічно нову функцію (spike), перш ніж узятися за її повноцінну реалізацію, спише витрати на ці дослідницькі спринти на витрати — адже невизначеність щодо того, чи взагалі можливо це реалізувати, ще не усунена. Щойно дослідження підтверджує здійсненність, а керівництво виділяє бюджет на повноцінну розробку, поріг «ймовірності завершення» досягається, і подальші витрати на розробку капіталізуються — незалежно від того, які agile-ритуали при цьому відбуваються.
Чому FASB вважає, що капіталізація майже не зміниться — окрім SaaS
Власні очікування FASB полягають у тому, що для більшості локального або ліцензійного програмного забезпечення для внутрішнього використання ці зміни не спричинять різкого зсуву в результатах капіталізації — компанії й раніше капіталізували витрати, щойно починалося реальне написання коду, і новий тест приводить приблизно до того самого результату, просто без вправи з присвоєння етапних ярликів.
Програмне забезпечення, що розробляється для постачання через SaaS або хмарну модель, — це вже зовсім інша історія. FASB прямо очікує зниження капіталізації для таких проєктів. Логіка така: SaaS-продукти за своєю природою будуються й перебудовуються безперервно, а суттєва технічна та продуктова невизначеність зберігається глибоко в межах усього циклу розробки — іноді аж до моменту, коли функція наближається до релізу. За тестом «ймовірності завершення» ця стійка невизначеність означає, що багато витрат на SaaS-розробку не подолають поріг капіталізації аж до значно пізнішого етапу побудови, ніж це передбачала б стара поетапна модель. Чистий ефект: більша частина фонду оплати праці інженерів SaaS-продукту потрапляє в поточні витрати на дослідження та розробку (R&D), а не у багаторічний актив, що амортизується. Це суттєвий зсув для показника EBITDA будь-якої SaaS-компанії та бази її активів — ще до того, як зміниться хоч один рядок коду.
Конкретний приклад: дві команди, два результати
Припустімо, SaaS-компанія з 40 співробітників вирішує розробити для свого продукту модуль прогнозування на основі ШІ. Ось як старі й нові правила по-різному трактували б однакову восьмимісячну розробку.
За старою поетапною моделлю фінансова команда намагалася б провести межу: перші шість тижнів збору вимог та оцінки постачальників вважалися «попереднім» етапом (списувалися на витрати), а все після установчої наради (kickoff) — «розробкою застосунку» (капіталізувалося) — навіть попри те, що команда розробників наступні два місяці витратила на дослідницькі спринти (spikes), намагаючись з'ясувати, чи зможе обраний підхід до прогнозування досягти прийнятної точності на виробничих обсягах даних. За буквою старого правила, щойно «етап» змінювався, ці дослідницькі спринти часто також капіталізувалися, оскільки формально відбувалися після установчої наради.
За ASU 2025-06 фінансова команда натомість запитує: коли стало ймовірним, що цю функцію буде завершено і вона працюватиме за призначенням? Якщо підхід до точності залишався недоведеним протягом перших двох місяців — команда тестувала три різні підходи до моделювання і не знала, чи подолає хоч один із них потрібну планку, — увесь цей період дослідження списується на витрати, незалежно від того, до якого «етапу» за календарем він потрапляв. Капіталізація починається лише тоді, коли команда обирає перевірений підхід, а керівництво виділяє бюджет на його реалізацію, що в цьому прикладі може настати на третьому місяці, а не на другому. Результат: менший капіталізований актив, більші поточні витрати на R&D і — що важливо — показник, який фінансовий директор дійсно може обґрунтувати під час аудиту, оскільки він прив'язаний до конкретної, задокументованої точки прийняття рішення, а не до етапного ярлика, застосованого заднім числом.
Саме такого зсуву FASB очікує в усьому секторі SaaS: менше «ми назвали це розробкою застосунку, бо саме так відбувалося після установчої наради» і більше «ми можемо вказати на спринт, у якому було знято технічний ризик».
Дати набуття чинності та перехід
ASU 2025-06 набуває чинності для всіх суб'єктів господарювання — публічних і приватних — для річних звітних періодів, що починаються після 15 грудня 2027 року, і для проміжних періодів у межах цих років. Дострокове застосування дозволене для будь-якого суб'єкта в будь-якому проміжному чи річному періоді після офіційного випуску стандарту.
Суб'єкти господарювання можуть застосувати ці зміни, обравши один із трьох підходів до переходу: перспективно — лише до нових витрат на програмне забезпечення, понесених після дати набуття чинності; перспективно — до витрат, понесених від початку року застосування або пізніше; або ретроспективно — до всіх представлених періодів. Ця гнучкість має значення: компанія, яка на момент набуття чинності правила перебуває в середині масштабного переписування платформи, не зобов'язана переглядати роки історії капіталізованих витрат, якщо тільки сама не обере ретроспективний варіант.
Що варто зробити зараз невеликим і середнім софтверним компаніям
Грудень 2027 року здається далеким, але практична підготовка — це не завдання останнього кварталу, особливо для компаній із компактними фінансовими командами без окремої функції технічного обліку.
Почніть документувати судження щодо «ймовірності завершення» в реальному часі, а не заднім числом. Стара поетапна модель була механічною — можна було відновити, на якому етапі перебував проєкт, місяцями пізніше, просто за датами спринтів. Новий тест запитує коли ми перестали відчувати технічну невизначеність, а це судження, яке набагато складніше відновити постфактум. Виробіть просту звичку вже зараз: коли керівництво розробки та фінансова команда погоджуються, що функція пройшла технічну перевірку (spike) і затверджена до реалізації, фіксуйте цю дату. Цей запис стане датою початку вашої капіталізації та підтвердженням для аудиту.
Розділяйте роботу над «дослідженням» і роботу над «затвердженою розробкою» у своєму обліку часу або кодах проєктів, якщо ви ще цього не робите. Чи то прапорець епіка в Jira, чи окремий код центру витрат, чи просто мітка в інструменті обліку часу — наявність чіткого сліду даних про те, коли функція перейшла від дослідження/прототипу до затвердженої розробки, зробить застосування нового стандарту значно менш болісним, ніж спроба відновити це з пам'яті під час аудиту.
Прорахуйте обидва варіанти переходу, перш ніж обрати один із них. Якщо ваша компанія агресивно капіталізувала витрати на SaaS-розробку за старою поетапною моделлю, ретроспективне застосування може призвести до одноразового списання раніше капіталізованих активів, оскільки ці витрати будуть перекласифіковані так, ніби вони весь час були витратами. Перспективний підхід дозволяє уникнути такого перерахунку, але означає, що ваш звіт про прибутки та збитки не відображатиме нову методологію, доки після впровадження не почнуться нові проєкти. Прорахуйте цифри за обома варіантами, перш ніж це доведеться робити вашому аудиторському комітету.
Поговоріть зі своїм аудитором заздалегідь, особливо якщо ви SaaS-компанія. Враховуючи власні очікування FASB щодо зниження капіталізації для SaaS-розробки, аудитори, ймовірно, ретельніше перевірятимуть судження щодо «ймовірності завершення», ніж вони перевіряли класифікацію за етапами за старим правилом, — саме тому, що це судження більш суб'єктивне. Компанія, яка приходить на аудит 2028 року з задокументованою, сучасною системою прийняття таких рішень, матиме значно легшу розмову, ніж та, що відновлює все заднім числом.
Чиста бухгалтерія полегшує захист професійних суджень
Будь-яке облікове судження — а «ймовірність завершення» безумовно є таким судженням — настільки ж легко захистити, наскільки надійними є записи, що його підтверджують. Якщо ваш план рахунків уже розділяє витрати на R&D за проєктами, а записи у вашій бухгалтерській книзі версіоновані й придатні для аудиту, а не розкидані по непов'язаних електронних таблицях, застосування такого стандарту, як ASU 2025-06, зводиться до маркування наявних даних, а не до відновлення історії з переписок у Slack. Текстовий облік Beancount.io від початку дає вам саме таку прозору, версіоновану через git бухгалтерську книгу — кожен запис можна відстежити, кожну зміну можна перевірити, без прив'язки до постачальника. Почніть безкоштовно і ведіть облік, який витримає перевірку — незалежно від того, хто ставить питання: аудитор, покупець компанії чи наступне оновлення FASB.