Току-що похарчихте 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 г., като е разрешено предсрочно прилагане.
За повечето малки бизнеси практическата последица е скромна — разделителната линия попада приблизително там, където днес е границата между предварителния етап и етапа на разработка — но новият стандарт показва, че повече разходи за гъвкава, итеративна разработка ще се квалифицират. Ако екипът ви изгражда на спринтове, а не на водопадни фази, говорете с вашия счетоводител за предсрочно прилагане. Дотогава продължавайте да прилагате триетапния модел и пазете документацията за етапите, която одиторът ви очаква.
Вашата данъчна декларация следва различни правила
Тук собствениците се опарят: третирането по GAAP във вашите книги и данъчното третиране в декларацията ви се ръководят от напълно отделни правила и често се разминават.
За данъчни години, започващи след 31 декември 2021 г., Законът за намаляване на данъците и създаване на работни места изискваше бизнесите да капитализират вътрешните разходи за изследвания и експерименти — изрично включително разработката на софтуер — и да ги амортизират за пет години (петнадесет за чуждестранни изследвания). Това превърна „похарчихме 200 000 долара за разработчици“ от текущо приспадане в приспадане от 20 000 долара през първата година, а остатъкът се разпределя за пет години.
Законът One Big Beautiful Bill Act, подписан през 2025 г., възстанови незабавното разходване на вътрешните разходи за изследвания и експерименти, с обратна сила за данъчни години, започващи през 2025 г., и изясни, че разработката на софтуер се брои. Малките бизнеси обикновено имат опции за преход за неамортизираните салда от 2022–2024 г. — ускоряване на остатъка или продължаване на амортизирането му. Чуждестранните разходи за изследвания остават по петнадесетгодишния график.
Практическите последици:
- Ще имате разлики между книги и данъци. GAAP може да изисква капитализиране на разходи за внедряване, които вашата данъчна декларация разходва незабавно, или обратното. Проследявайте и двете третирания успоредно; вашата данъчна провизия и вашата Schedule M-1 зависят от това.
- Съответствието на щатите варира. Не всеки щат следва федералното възстановяване, така че разход, разходван федерално, може все още да се амортизира за целите на щата.
- Документацията служи на двама господари. Проследяването на времето по фаза на проекта подкрепя едновременно вашия анализ на етапите по GAAP и вашата заявка за данъчен кредит за изследвания по член 41. Една добра система захранва и двете.
Данъчното законодателство се движи достатъчно бързо, че всяко ръководство като това е моментна снимка. Потвърдете правилата за текущата година с вашия данъчен консултант преди подаване — и никога не позволявайте на данъчната опашка да размахва счетоводното куче. Вашите финансови отчети трябва да следват GAAP независимо какво прави данъчната декларация.
Пет грешки, които предизвикват корекции
- Капитализиране на етапа на оценка. Демонстрации на доставчици, RFPs и консултации „да изградим ли или да купим“ са разходи от предварителния етап. Разходването им не е по избор.
- Капитализиране на обучение. Всеки стандарт е изричен: обучението се разходва, дори по време на разработката на приложението. Отделете го от фактурите за внедряване.
- Забравяне да спрете. Капитализацията приключва, когато софтуерът е готов за предвидената му употреба — не когато пристигне последната фактура. Часовете на изпълнителя след въвеждането в експлоатация са поддръжка, докато не започне истинско подобрение.
- Капитализиране на абонаментни такси. Тригодишен предплатен SaaS договор е предплатен разход, който се амортизира с потреблението на услугата, а не софтуерен актив. Не го прекарвайте през ASC 350-40.
- Без записи за време. Капитализираните заплати без съвременно проследяване на времето по проект и етап са първото нещо, което одитор или инспектор отхвърля. Оценките, реконструирани в края на годината, рядко издържат проверка.
Практически контролен списък за капитализация
Преди да запишете който и да е софтуерен разход като актив, отговорете на тези въпроси писмено и архивирайте бележката с проектните записи:
- Коя пътека се прилага — вътрешно ползване (350-40), софтуер за продажба (985-20) или договор за облачна услуга?
- Приключил ли е предварителният етап — финансирането ангажирано ли е и завършването вероятно ли е?
- Софтуерът съществено завършен ли е и готов ли е за употреба? Ако да, капитализацията е приключила.
- Този разход за обучение, поддръжка, въвеждане на данни или общи режийни разходи ли е? Ако да, разходвайте го.
- Можете ли да обвържете всеки капитализиран долар с график за работно време, фактура или изявление за обхвата на работата от изпълнителя?
- Кой период на амортизация отразява очаквания полезен живот (или срока на хостинга за разходите за внедряване)?
- Отчели ли сте данъчното третиране отделно, включително всяка разлика между книги и данъци?
Кратка бележка с отговори на тези седем въпроса отнема двадесет минути за писане и може да спести седмици спорове с одитор, банков инспектор или IRS.
Поддържайте софтуерните си разходи готови за одит
Всяка фактура от вашите разработчици, вашите SaaS доставчици и вашия облачен доставчик е решение за класификация, което чака да се случи. Бизнесите, които се справят с това правилно, споделят един навик: те проследяват софтуерните разходи по проект и етап в момента, в който парите излизат, а не когато счетоводителят попита дванадесет месеца по-късно. Маркирайте часовете за внедряване отделно от часовете за поддръжка, отделете обучението от изявленията за обхвата на работата на доставчиците и поддържайте текуща бележка за това в кой етап се намира всеки проект.
Чистите записи също правят разделението между книги и данъци управляемо. Когато вашата главна книга вече разделя капитализираната разработка от разходваните абонаменти, подготовката на декларацията — и защитата ѝ — се превръща в изваждане на справка, а не в реконструиране на година.
Beancount.io ви дава счетоводство на обикновен текст, което поддържа всяка една от тези класификации прозрачна, с контрол на версиите и готова за AI — така че вашата политика за капитализация живее във вашите книги, а не в електронна таблица, която никой не може да намери. Започнете безплатно и вижте защо разработчиците и финансовите специалисти преминават към счетоводство на обикновен текст.
