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: Етап на разработка на приложението​

Капитализирането започва, когато ръководството одобри проекта, поеме ангажимент за финансиране и завършването е вероятно. Този етап обхваща реалното изграждане — програмиране, тестване, конфигуриране, интегриране и инсталиране.

Капитализируемите разходи на този етап обикновено включват:

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

Капитализирането спира, когато софтуерът е съществено завършен и готов за предназначената му употреба — обикновено когато тестването приключи и системата бъде внедрена в производствена среда, дори ако въвеждането е постепенно.

Етап 3: Етап на следвнедряване​

След пускането в експлоатация текущите разходи се връщат към отнасяне към разход. Обучението, поддръжката, корекциите на грешки и рутинната поддръжка се отнасят към разход. Изключение: подобрения, които добавят нова функционалност (а не просто поправят или поддържат съществуващата), могат да се капитализират, като се използват същите критерии като при Етап 2.

Основната промяна от 2025 г.: ASU 2025-06​

На 18 септември 2025 г. FASB издаде ASU 2025-06, който значително модернизира ASC 350-40. Актуализацията е задължителна за годишни периоди, започващи след 15 декември 2027 г., като се разрешава ранно прилагане.

Промяната е структурна: триетапният модел вече не съществува. FASB изрично премахна всички позовавания на проектни етапи, защото старата рамка не отговаряше на съвременните практики за гъвкава и итеративна разработка, при които изискванията се развиват, а „етапите“ се припокриват или протичат успоредно.

Новият принципно-базиран праг​

Съгласно ревизирания стандарт капитализирате разходи за софтуер само когато са изпълнени и двете условия:

1. Одобрение от ръководството: Ръководството е одобрило и се е ангажирало с финансирането на проекта.
2. Праг на вероятна завършимост: Вероятно е проектът да бъде завършен и софтуерът да изпълнява предназначената си функция.

Вторият тест свършва реална работа. FASB въведе концепция, наречена значителна несигурност при разработката, за да оцени дали завършването е вероятно. Трябва да прецените:

• Дали софтуерът включва нови или недоказани функции, които не са валидирани чрез програмиране или тестване
• Дали изискванията за производителност все още не са определени или подлежат на съществена промяна

Ако съществува значителна несигурност, капитализирането трябва да бъде отложено, докато несигурността бъде разрешена. FASB е сигнализирал, че очаква новото правило да доведе до повече софтуерни разходи, отнасяни към разход, особено в SaaS компании, където изискванията се итерират непрекъснато.

Какво означава това на практика​

За стартъп, който изгражда нещо наистина ново — платформа за AI агенти, нов двигател за автоматизация — новото правило може да премести повече разходи в оперативните разходи по-рано. За зрели компании, които подобряват добре дефинирани системи, практическото въздействие ще е по-малко. Във всеки случай преходът от механична проверка на етапи към основан на преценка праг означава, че компаниите се нуждаят от по-ясна документация на решенията на ръководството, техническата осъществимост и статуса на проекта.

Какво можете и какво не можете да капитализирате: Практически контролен списък​

Независимо дали прилагате стария етапен модел или новия принципно-базиран тест, границата между капитализируеми и отнасяни към разход разходи е сходна по дух. Ето работен контролен списък.

По принцип капитализируеми​

• Преки разходи за труд за разработчици, дизайнери и QA по време на фазата на изграждане
• Разпределени осигуровки върху заплатите и придобивки за тези служители
• Външни консултантски и изпълнителски хонорари за дейности по разработка
• Софтуер, инструменти и разходи за облачна инфраструктура, пряко консумирани в разработката
• Разходи за разработване на нова функционалност след пускането на пазара (подобрения, които съществено разширяват възможностите)
• Разходи за разработване на софтуер за преобразуване (софтуера, който мигрира стари данни към новите), за разлика от самата дейност по преобразуване на данни

По принцип отнасяни към разход​

• Предварителни проучвания, избор на доставчик и анализ на осъществимостта
• Обучение на служителите за новата система
• Почистване на данни, съгласуване и миграция на записи
• Рутинна поддръжка, корекции на грешки и незначително преработване
• Софтуерни разходи, направени през периоди на значителна несигурност при разработката
• Общи административни режийни разходи, които не са пряко свързани с разработката
• Маркетинг, поддръжка и дейности за успех на клиентите след пускането

Проблемът с отчитането на времето​

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

Въздействието върху финансовите отчети​

Капитализирането срещу отнасянето към разход на същата сума води до драстично различни финансови отчети.

Ефект върху отчета за приходите и разходите​

Капитализираният разход не се отразява в отчета за приходите и разходите за периода, в който е направен. Вместо това той се амортизира — обикновено линейно за период от три до пет години за вътрешно използваем софтуер. Така 1 милион долара капитализирани инженерни разходи за Година 1 може да създадат само 200K до 333K долара годишен разход за амортизация, което оставя оперативната печалба за Година 1 значително по-висока.

Ето защо EBITDA получава тласък от капитализацията. Амортизацията по дефиниция е изключена от EBITDA — така че капитализирането на повече разходи за разработка премества суми от оперативни разходи (които намаляват EBITDA) към амортизация (която не го прави). Инвеститорите, които следят SaaS показателите отблизо, често гледат „EBITDA преди капитализирани R&D“ или изчисления по правилото на 40-те, използвайки паричните R&D разходи, за да видят през тази динамика.

Ефект върху баланса​

Капитализираният софтуер се появява като дълготраен нематериален актив, често обозначен като „Капитализирани разходи за разработка на софтуер“ или подобно. Това:

• Увеличава общите активи и собствения капитал
• Подобрява възвръщаемостта на активите (ROA) само ако печалбите растат по-бързо от базата на активите
• Създава актив, който трябва да бъде тестван за обезценка, ако проектът бъде изоставен или стойността му намалее

Ако проект бъде изоставен по средата на разработката, предходно капитализираните разходи трябва да бъдат отписани — което води до внезапна, често съществена загуба. Това е една от причините новият ASU 2025-06 да набляга толкова силно на прага на вероятна завършимост.

Ефект върху отчета за паричните потоци​

Капитализираните разходи за разработка обикновено се класифицират като инвестиционни дейности (не оперативни), което прави оперативния паричен поток да изглежда по-силен. Опитните инвеститори коригират това при сравняване на компании — но водещата цифра все пак печели.

Често срещани грешки, които създават проблеми на компаниите​

Одиторите и acquire-рите виждат едни и същи грешки отново и отново.

Капитализиране на разходи преди одобрение​

Класическата грешка е капитализирането на инженерно време, изразходвано преди ръководството официално да одобри проекта. Без документирано одобрение и ангажимент за финансиране, тези разходи е трябвало да бъдат отнесени към разход. Уверете се, че имате протоколи от срещи, одобрения от борда или писмени съгласия, които установяват кога ръководството се е ангажирало.

Липса на документация на проектно ниво​

Ако регулатор или одитор попита „покажете ми проектите, които сте капитализирали“, а вие можете да посочите само общи инженерни разходи, ще загубите. Имате нужда от записи по проекти: обхват, дата на одобрение, бюджет, статус и отработено време.

Отнасяне на цялото инженерно време към капитализируемо​

Старшите инженери поправят грешки, преглеждат код, участват в срещи и реагират на инциденти. Нищо от това не е капитализируемо. Компаниите, които просто умножават заплатите на инженерния екип по някакъв процент, рядко оцеляват при одит.

Продължаване на капитализирането след пускане​

В момента, в който софтуерът е готов за предназначената му употреба, капитализирането спира. Корекциите на грешки, настройката на производителността и незначителните подобрения след този момент са оперативни разходи. Нови функции с отделен обхват могат да започнат нов период на капитализация — но рутинната работа след пускането не може.

Забравяне на тестването за обезценка​

Капитализираният софтуер е актив и активите трябва да бъдат обезценени, ако стойността им спадне. Ако консервирате продукт, прекратите функция или основно пренапишете системата, трябва да направите повторна оценка и вероятно да отпишете предходното салдо.

Как да изградите защитим процес​

Ако решите, че капитализацията е подходяща за вашата компания, процесът е също толкова важен, колкото и политиката.

1. Напишете политика за софтуерна капитализация. Определете кои проекти отговарят на условията, вашия процес на одобрение, оценката за полезния живот и как ще разпределяте времето. Получете подпис от финансовия директор или одитния комитет.

2. Следете инженерното време на проектно ниво. Това е основният вход. Независимо дали използвате етикети в Jira, персонализирани тагове в система за проследяване на проекти или официални графици за работно време, трябва да защитите тезата „инженер X е отделил Y% от времето си за капитализируема работа по проект Z“.

3. Документирайте одобрението от ръководството. Всеки капитализируем проект се нуждае от доказателство за одобрение — датирано писмено съгласие, протокол от борда или харта на проекта, подписана от ръководството.

4. Преоценявайте значителната несигурност редовно. Съгласно новото правило трябва да следите дали функциите все още са нови или недоказани и дали изискванията се стабилизират. Тримесечните прегледи с инженерното ръководство са разумни.

5. Изградете графици за амортизация по проекти. Всеки капитализиран проект започва да се амортизира, когато е готов за употреба, и трябва да следите себестойността на актива, натрупаната амортизация и оставащия полезен живот.

6. Тествайте за обезценка при промени в проектите. Всеки път, когато изоставите, съществено пренапишете или прекратите капитализирана работа, извършете анализ за обезценка и заведете отписвания, ако е необходимо.

Защо това е от значение за счетоводството​

Софтуерната капитализация е една от онези области, в които дисциплината от първия ден се отплаща години по-късно. Инвеститорите при набиране на серия B ще изтеглят пробния баланс; приобретателите в процес на продажба ще проследяват транзакциите до счетоводните записи; IRS може да сравни вашето третиране по GAAP с вашето данъчно третиране по Секция 174 за R&D, което има свои собствени правила. Ако книгите ви не разделят капитализираните проекти от оперативните разходи, не могат да свържат таксуваното инженерно време с конкретни проекти или не поддържат чисти графици за амортизация, всеки одит и процес на дю дилиджънс става мъчителен.

Решението е просто като концепция: поддържайте чиста структура на сметките, следете времето на проектно ниво и документирайте решенията зад всеки запис за капитализация. Правенето на това от самото начало избягва скъпите почиствания по-късно.

Поддържайте счетоводството на софтуера готово за одит​

Независимо дали капитализирате първата си вътрешна платформа или управлявате графици за амортизация за десетки проекти, чистите финансови записи са основата. Beancount.io предоставя счетоводство в обикновен текст, което ви дава прозрачни книги с контрол на версиите — всяка вписване е проследима, всяка сметка е одитируема, всеки отчет е възпроизводим. За софтуерни компании, които следят капитализираната разработка в множество проекти, книгите, които се четат като код, са сериозно предимство. Започнете безплатно и вижте защо разработчиците и финансовите специалисти преминават към счетоводство в обикновен текст.