Капитализация на софтуер съгласно ASC 350-40: Практическо ръководство за решението „Капитализация срещу текущ разход“

Проучване на Gartner от 2024 г. установи, че 63% от основателите на SaaS компании в ранен етап класифицират неправилно разходите за разработка на софтуер. Тази грешка им коства много на два фронта: инвеститорите дисконтират техните финансови показатели, когато класификациите изглеждат небрежни, а одиторите сигнализират за проблема по време на дю дилиджънс, което може да забави кръговете на финансиране или процесите на продажба с месеци.

Капитализацията на софтуер не е просто счетоводна формалност. Тя пряко влияе върху EBITDA, баланса и начина, по който бизнесът ви изглежда пред кредитори, инвеститори и купувачи. Правилата по ASC 350-40 — и основната актуализация от 2025 г. — определят кои разходи попадат веднага в отчета за приходите и разходите и кои се разпределят във времето в продължение на години.

Това ръководство разглежда изискванията на стандарта, скорошната ревизия от ASU 2025-06, разходите, които можете да капитализирате, тези, които не можете, и последиците за финансовия отчет от правилното им отразяване.

Какво обхваща ASC 350-40

ASC 350-40 е стандартът на FASB за софтуер за вътрешна употреба — софтуер, който вашата компания създава или купува за собствените си операции, а не за продажба на клиенти като основен продукт. Примерите включват:

• Вътрешни CRM, ERP, HR или счетоводни системи
• Инструменти за облачна инфраструктура и DevOps платформи
• SaaS платформа, която оперирате за клиенти (клиентът я достъпва като услуга, а не като лицензиран софтуер, който инсталира)
• Вътрешни потоци от данни, табла за управление (dashboards) и инструменти за анализи
• Персонализирана автоматизация на работни процеси или бек-офис

Ако продавате лицензиран софтуер, който клиентите инсталират на собствените си машини, това попада под 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 изрично премахна всички препратки към етапи на проекта, тъй като старата рамка не отговаряше на съвременните гъвкави (agile) и итеративни практики за разработка, където изискванията се развиват, а „етапите“ се припокриват или протичат паралелно.

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

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

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

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

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

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

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

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

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

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

Обикновено подлежащи на капитализация

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

Обикновено отчитани като текущи разходи

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

Проблемът с проследяването на времето

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

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

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

Ефект върху Отчета за приходите и разходите (ОПР)

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

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

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

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

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

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

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

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

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

Одиторите и купувачите на компании виждат едни и същи грешки отново и отново.

Капитализиране на разходи преди оторизация

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

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

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

Третиране на цялото инженерно време като подлежащо на капитализация

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

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

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

Пропускане на тестването за обезценка

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

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

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

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

2. Проследявайте времето на софтуерните инженери на ниво проект. Това е основният входен елемент. Независимо дали използвате етикети в Jira, персонализирани тагове в тракер за проекти или официални графици (timesheets), трябва да можете да защитите твърдението „инженер Х е прекарал Y% от времето си в работа, подлежаща на капитализация по проект Z“.

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

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

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

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

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

Капитализацията на софтуер е една от онези области, в които дисциплината в счетоводството от първия ден се отплаща години по-късно. Инвеститорите по време на кръг от серия B ще поискат вашата оборотна ведомост; купувачите в процес на продажба ще проследят трансакциите обратно до счетоводните записвания; данъчните служби могат да сравнят вашето третиране по GAAP с вашето данъчно третиране на НИРД по Раздел 174, който има свои собствени правила. Ако вашите книги не разделят капитализираните проекти от оперативните разходи, не могат да обвържат разходите за времето на инженерите с конкретни проекти или не поддържат чисти амортизационни планове, всеки одит и цикъл на проверка става болезнен.

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

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

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