Ви щойно витратили $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. Тут розділова лінія — це єдина віха: технологічна здійсненність. Усі витрати до цієї точки є дослідженнями та розробками, які відносяться до витрат у міру виникнення. Витрати після досягнення здійсненності, але до загального випуску, капіталізуються. Підтримка після випуску відноситься до витрат.
На практиці багато agile-команд досягають технологічної здійсненності дуже пізно — іноді з робочою моделлю, яка з'являється за кілька днів до випуску — тому капіталізувати майже нічого. Це законний результат, а не невдача в капіталізації. Примусове перетворення витрат в актив, коли здійсненність ніколи чітко не була встановлена, є однією з найпоширеніших причин перерахунку звітності в компаніях-розробниках програмного забезпечення.
Напрямок 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 року, Закон про скорочення податків і створення робочих місць (TCJA) вимагав від бізнесів капіталізувати внутрішні дослідницькі та експериментальні витрати — явно включаючи розробку програмного забезпечення — і амортизувати їх протягом п'яти років (п'ятнадцяти для зарубіжних досліджень). Це перетворило «ми витратили $200 000 на розробників» з поточного відрахування на відрахування $20 000 у перший рік, а решта витікала б протягом п'яти років.
Закон One Big Beautiful Bill Act, підписаний у 2025 році, відновив негайне віднесення до витрат внутрішніх дослідницьких та експериментальних витрат, із зворотною силою до податкових років, що починаються у 2025 році, і уточнив, що розробка програмного забезпечення враховується. Малі бізнеси зазвичай мають перехідні опції для неамортизованих залишків 2022–2024 років — прискорення залишку або продовження його амортизації. Витрати на зарубіжні дослідження залишаються за п'ятнадцятирічним графіком.
Практичні наслідки:
- У вас будуть різниці між книгами та податковою декларацією. GAAP може вимагати капіталізації витрат на впровадження, які ваша податкова декларація відносить до витрат негайно, або навпаки. Відстежуйте обидва підходи паралельно; ваш розрахунок резерву та ваш Schedule M-1 залежать від цього.
- Відповідність на рівні штатів різниться. Не кожен штат дотримується федерального відновлення, тому витрата, віднесена до витрат на федеральному рівні, може все ще амортизуватися для цілей штату.
- Документація служить двом панам. Відстеження часу за етапами проєкту підтримує ваш аналіз етапів GAAP та вашу заявку на дослідницький кредит за статтею 41 одночасно. Одна хороша система живить обидва.
Податкове законодавство змінюється досить швидко, щоб будь-який подібний посібник був лише знімком. Підтвердьте правила поточного року з вашим податковим консультантом перед поданням — і ніколи не дозволяйте податковому хвосту керувати собакою GAAP. Ваші фінансові звіти повинні відповідати GAAP незалежно від того, що робить податкова декларація.
П'ять помилок, які спричиняють коригування
- Капіталізація етапу оцінки. Демонстрації постачальників, запити пропозицій та консалтинг «створити чи купити» є витратами попереднього етапу. Віднесення їх до витрат не є опціональним.
- Капіталізація навчання. Кожен стандарт є категоричним: навчання відноситься до витрат, навіть під час розробки додатка. Виділіть його з рахунків за впровадження.
- Забуття зупинитися. Капіталізація закінчується, коли програмне забезпечення готове до використання за призначенням — а не коли надходить останній рахунок. Години підрядників після запуску є обслуговуванням, доки не почнеться справжнє вдосконалення.
- Капіталізація плати за підписку. Трирічний передплачений контракт SaaS є передплаченою витратою, яка амортизується в міру споживання послуги, а не активом програмного забезпечення. Не проводьте його через ASC 350-40.
- Відсутність обліку часу. Капіталізована заробітна плата без одночасного відстеження часу за проєктом і етапом — це перше, що аудитор або перевіряючий не визнає. Оцінки, відтворені в кінці року, рідко витримують перевірку.
Практичний контрольний список капіталізації
Перш ніж віднести будь-яку витрату на програмне забезпечення до активу, дайте письмові відповіді на ці питання та підшийте меморандум до записів проєкту:
- Який напрямок застосовується — внутрішнє використання (350-40), програмне забезпечення для продажу (985-20) чи контракт на хмарну послугу?
- Чи закінчився попередній етап — чи взято зобов'язання щодо фінансування і чи є завершення ймовірним?
- Чи програмне забезпечення суттєво завершене та готове до використання? Якщо так, капіталізація закінчилася.
- Чи це витрата на навчання, обслуговування, введення даних чи загальні накладні витрати? Якщо так, віднесіть до витрат.
- Чи можете ви прив'язати кожен капіталізований долар до табеля обліку робочого часу, рахунку чи технічного завдання підрядника?
- Який період амортизації відображає очікуваний строк корисної служби (або строк хостингу для витрат на впровадження)?
- Чи зафіксували ви податковий підхід окремо, включаючи будь-яку різницю між книгами та податковою декларацією?
Короткий меморандум з відповідями на ці сім питань займає двадцять хвилин на написання і може заощадити тижні суперечок з аудитором, банківським перевіряючим або IRS.
Тримайте свої витрати на програмне забезпечення готовими до аудиту
Кожен рахунок від ваших розробників, постачальників SaaS та хмарного провайдера — це рішення про класифікацію, яке чекає на своє вирішення. Бізнеси, які роблять це правильно, мають одну спільну звичку: вони відстежують витрати на програмне забезпечення за проєктом і етапом у міру витрачання грошей, а не коли CPA запитує про це дванадцять місяців потому. Позначайте години впровадження окремо від годин підтримки, виділяйте навчання з технічних завдань постачальників і ведіть поточний меморандум про те, на якому етапі знаходиться кожен проєкт.
Чисті записи також роблять розподіл між книгами та податковою декларацією керованим. Коли ваш регістр уже відокремлює капіталізовану розробку від витрат на підписки, підготовка декларації — та її захист — стає питанням формування звіту, а не відтворення цілого року.
Beancount.io надає вам бухгалтерський облік у простому тексті, який зберігає кожну з цих класифікацій прозорою, контрольованою версіями та готовою до ШІ — тож ваша політика капіталізації живе у ваших книгах, а не в електронній таблиці, яку ніхто не може знайти. Почніть безкоштовно і дізнайтеся, чому розробники та фінансові фахівці переходять на бухгалтерський облік у простому тексті.
