Opýtajte sa manažéra softvérového vývoja, kedy sa projekt „začal", a dostanete číslo šprintu. Opýtajte sa na to isté ich kontrolóra a podľa účtovných pravidiel, ktoré od roku 1998 upravujú softvér pre vlastnú potrebu, mala odpoveď vychádzať z rigidného trojstupňového kontrolného zoznamu, ktorý predpokladá, že nikto nepíše kód, kým nie sú uzamknuté požiadavky. Každý, kto za posledné desaťročie dodával softvér, vie, že takto to už dávno nefunguje – a v septembri 2025 to napokon uznal aj FASB.
Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, úplne zrušuje starý test založený na štádiách a nahrádza ho jedinou otázkou založenou na úsudku: je pravdepodobné, že tento softvér bude skutočne dokončený a bude plniť svoju zamýšľanú funkciu? Pre každú spoločnosť, ktorá vyvíja softvér vo vlastnej réžii – a najmä pre agilné tímy, pre ktoré stará norma nikdy nebola stavaná – to mení, kedy sa náklady na vývoj presúvajú z výkazu ziskov a strát do súvahy, a o koľko.
Problém: Pravidlá z roku 1998 pre vodopádový vývoj
Usmernenie, ktoré ASU 2025-06 nahrádza – ASC 350-40 (pôvodne SOP 98-1) – bolo napísané v čase, keď „vývoj softvéru" znamenal lineárny vodopádový proces. Rozdeľovalo každý projekt softvéru pre vlastnú potrebu do troch po sebe nasledujúcich štádií:
- Prípravné štádium projektu – koncepčné formulovanie, hodnotenie alternatív, výber dodávateľa. Všetko v tomto štádiu sa účtuje do nákladov v okamihu vzniku.
- Štádium vývoja aplikácie – samotné programovanie, konfigurácia a testovanie. Náklady v tomto štádiu sa kapitalizujú.
- Štádium po implementácii – školenia a údržba. Opäť sa účtuje do nákladov.
Tento rámec funguje dobre, ak tím strávi tri mesiace písaním dokumentu s požiadavkami, získa schválenie a až potom začne stavať. Rozpadne sa vo chvíli, keď tím beží v dvojtýždňových šprintoch, dodáva inkrementálne vydania a upravuje rozsah pri každom retre. V agilnom prostredí nie sú „prípravná fáza" a „vývoj aplikácie" postupnými fázami – prelínajú sa, niekedy aj v rámci toho istého šprintu. Spoločnosti a ich audítori strávili roky dohadovaním sa o tom, do ktorého štádia daný dvojtýždňový šprint vlastne patrí, a úprimná odpoveď často znela „trochu oboch, len hádame". Vlastný prieskum FASB medzi zainteresovanými stranami zistil, že túto oblasť konzistentne označujú za jednu z prevádzkovo najbolestivejších častí US GAAP na dôsledné uplatňovanie.
Riešenie: Jeden test namiesto troch štádií
ASU 2025-06 odstraňuje všetky odkazy na staré štádiá projektu. Namiesto nich stanovuje jediný prah uznania „pravdepodobnosti dokončenia". Podľa nového usmernenia spoločnosť kapitalizuje náklady na softvér pre vlastnú potrebu vo chvíli, keď súčasne platia obe nasledujúce podmienky:
- Manažment schválil projekt a zaviazal sa k jeho financovaniu. Toto nie je nový koncept – existoval už aj v starom usmernení – no teraz zohráva väčšiu úlohu ako jedna z iba dvoch vstupných podmienok namiesto toho, aby bol ukrytý v analýze štádií.
- Je pravdepodobné, že projekt bude dokončený a softvér sa bude používať na plnenie svojej zamýšľanej funkcie. Toto je skutočne nová časť a práve tu sa uplatňuje odborný úsudok.
Toto druhé kritérium vyžaduje posúdiť, či ešte pretrváva významná neistota súvisiaca s vývojom. FASB uvádza dva hlavné zdroje tejto neistoty:
- Neoverená technológia alebo nová funkcionalita, ktorej realizovateľnosť ešte nebola preukázaná skutočným programovaním a testovaním – nie návrhovým dokumentom, nie špecifikáciou, ale funkčným dôkazom.
- Nedefinované alebo stále sa meniace požiadavky na výkon – norma ich definuje ako „to, čo účtovná jednotka od softvéru potrebuje, napr. funkcie alebo vlastnosti". Ak sa tím stále vecne dohaduje o tom, čo má produkt robiť, táto neistota nebola vyriešená.
V praxi to znamená, že načasovanie kapitalizácie teraz sleduje dôkaz realizovateľnosti, nie kalendárnu fázu. Tím, ktorý dva šprinty overuje technicky novú funkciu formou spike-u predtým, než sa zaviaže k jej plnohodnotnému vývoju, by tieto spike šprinty účtoval do nákladov – neistota o tom, či sa to vôbec dá postaviť, ešte nebola vyriešená. Keď spike overenie potvrdí a manažment schváli rozpočet na plnohodnotnú stavbu, prah „pravdepodobnosti dokončenia" je splnený a následné náklady na vývoj sa kapitalizujú, bez ohľadu na agilné ceremónie.
Prečo FASB tvrdí, že kapitalizácia sa výrazne nezmení – okrem SaaS
Samotný FASB očakáva, že pri väčšine on-premise alebo licenčného softvéru pre vlastnú potrebu zmeny nespôsobia dramatický posun vo výsledkoch kapitalizácie – spoločnosti už aj tak kapitalizovali od okamihu, keď sa začalo so skutočným programovaním, a nový test dospieva približne k rovnakému záveru, len bez cvičenia s označovaním štádií.
Softvér vyvíjaný na dodanie formou SaaS alebo cloudového riešenia je iný príbeh. FASB výslovne očakáva, že kapitalizácia pri týchto projektoch poklesne. Dôvod: SaaS produkty sú svojou povahou nepretržite budované a prestavované, pričom výrazná technická a produktová neistota pretrváva hlboko do priebehu vývoja – niekedy až kým sa funkcia nepribližuje k vydaniu. Podľa testu pravdepodobnosti dokončenia táto pretrvávajúca neistota znamená, že mnohé náklady na vývoj SaaS nesplnia hranicu pre kapitalizáciu až do oveľa neskoršej fázy stavby, než by naznačoval starý model štádií. Čistý efekt: väčšia časť mzdových nákladov na inžiniering pri SaaS produkte skončí ako bežný nákladový výdavok na výskum a vývoj v danom období namiesto viacročne odpisovaného aktíva. Ide o významný posun pre vykazovanú EBITDA a majetkovú základňu akejkoľvek SaaS spoločnosti, ešte skôr, než sa zmení čo i len jeden riadok samotného kódu.
Konkrétny príklad: Dva tímy, dva výsledky
Predstavme si, že SaaS spoločnosť so 40 zamestnancami sa rozhodne vybudovať modul prognózovania poháňaný umelou inteligenciou pre svoj produkt. Takto by staré a nové pravidlá odlišne posudzovali tú istú osemmesačnú stavbu.
Podľa starého modelu štádií by sa finančný tím snažil vymedziť hranicu: prvých šesť týždňov zberu požiadaviek a hodnotenia dodávateľov bolo „prípravných" (do nákladov), a všetko po úvodnom stretnutí bolo „vývoj aplikácie" (kapitalizované) – aj napriek tomu, že vývojový tím strávil ďalšie dva mesiace prieskumnými spike-mi, aby zistil, či zvolený prognostický prístup dokáže dosiahnuť prijateľnú presnosť pri produkčných objemoch dát. Podľa litery starého pravidla sa po „prepnutí štádia" tieto spike šprinty často kapitalizovali tiež, pretože sa formálne odohrali až po úvodnom stretnutí.
Podľa ASU 2025-06 sa finančný tím namiesto toho pýta: kedy sa stalo pravdepodobným, že táto funkcia bude dokončená a bude fungovať podľa zámeru? Ak bol prístup k presnosti počas prvých dvoch mesiacov ešte neoverený – tím testoval tri rôzne modelovacie prístupy a nevedel, či niektorý z nich splní požadovanú úroveň –, celé toto skúmavé obdobie sa účtuje do nákladov bez ohľadu na to, do ktorého „štádia" na kalendári spadalo. Kapitalizácia sa začína až vo chvíli, keď si tím vyberie overený prístup a manažment schváli rozpočet na jeho realizáciu, čo môže byť v tomto príklade tretí mesiac, nie druhý. Výsledok: menšie kapitalizované aktívum, vyšší bežný nákladový výdavok na výskum a vývoj a – čo je dôležité – číslo, ktoré finančný riaditeľ dokáže pri audite skutočne obhájiť, pretože je naviazané na konkrétny, zdokumentovaný rozhodovací bod, a nie na štítok štádia priradený až dodatočne.
Presne toto je posun, ktorý FASB očakáva naprieč sektorom SaaS: menej „nazvali sme to vývojom aplikácie, pretože to prišlo po úvodnom hovore" a viac „vieme ukázať na šprint, v ktorom bolo technické riziko odstránené".
Dátumy účinnosti a prechod
ASU 2025-06 nadobúda účinnosť pre všetky účtovné jednotky – verejné aj súkromné – pre ročné vykazovacie obdobia začínajúce sa po 15. decembri 2027, a pre medziobdobia v rámci týchto rokov. Skoršie uplatnenie je povolené pre akúkoľvek účtovnú jednotku, v akomkoľvek medziobdobí či ročnom období, po vydaní normy.
Účtovné jednotky môžu zmeny uplatniť jedným z troch prechodných prístupov: prospektívne len na nové náklady na softvér vzniknuté po dátume účinnosti, prospektívne na náklady vzniknuté od začiatku roka prijatia normy, alebo retrospektívne na všetky vykázané obdobia. Táto flexibilita je dôležitá – spoločnosť, ktorá je uprostred veľkého prepisovania platformy v čase, keď pravidlo nadobudne účinnosť, nemusí rozpletať roky histórie kapitalizovaných nákladov, pokiaľ si nezvolí retrospektívnu možnosť.
Čo by mali malé a stredné softvérové spoločnosti robiť už teraz
December 2027 znie vzdialene, no praktická príprava nie je úlohou na posledný štvrťrok, najmä pre spoločnosti s úspornými finančnými tímami bez vyhradenej funkcie technického účtovníctva.
Začnite dokumentovať úsudok o „pravdepodobnosti dokončenia" v reálnom čase, nie so spätným pohľadom. Starý model štádií bol mechanický – v ktorom štádiu sa projekt nachádzal, sa dalo mesiace neskôr zrekonštruovať z dátumov šprintov. Nový test sa pýta kedy sme prestali byť technicky neistí, čo je úsudok, ktorý sa dodatočne rekonštruuje oveľa ťažšie. Vybudujte si už teraz jednoduchý návyk: keď sa vedenie vývoja a financie zhodnú, že funkcia prešla technickým overením a je záväzne určená na vývoj, zaznamenajte tento dátum. Tento záznam sa stane vaším dátumom začiatku kapitalizácie a podkladom pre audit.
Oddeľte „prieskumnú" prácu od „záväznej stavebnej" práce vo svojom sledovaní času alebo v projektových kódoch, ak to ešte nerobíte. Či už ide o príznak epicu v Jire, samostatný kód strediska nákladov, alebo len označený štítok vo vašom nástroji na sledovanie času, čistá dátová stopa o tom, kedy sa funkcia presunula zo spike-u/prototypu do záväzného vývoja, urobí uplatňovanie novej normy výrazne menej bolestivým než snahu rekonštruovať to z pamäti počas auditu.
Pred výberom si namodelujte obe prechodné možnosti. Ak vaša spoločnosť agresívne kapitalizovala náklady na vývoj SaaS podľa starého rámca štádií, retrospektívne uplatnenie by mohlo priniesť jednorazový odpis predtým kapitalizovaných aktív, keďže tieto náklady sa preklasifikujú, akoby boli od začiatku účtované do nákladov. Prospektívny prístup sa tejto prepočítanej úprave vyhne, no znamená, že váš výkaz ziskov a strát nebude odrážať novú metodiku, kým po prijatí normy nezačnú nové projekty. Prepočítajte čísla podľa oboch prístupov skôr, než to bude musieť urobiť váš výbor pre audit.
Komunikujte so svojím audítorom včas, najmä ak ste SaaS spoločnosť. Vzhľadom na to, že samotný FASB očakáva pokles kapitalizácie pri vývoji SaaS, audítori pravdepodobne budú posudzovať úsudky o „pravdepodobnosti dokončenia" prísnejšie, než posudzovali klasifikáciu do štádií podľa starého pravidla – práve preto, že je subjektívnejšia. Spoločnosť, ktorá do svojho auditu za rok 2028 vstúpi so zdokumentovaným, priebežne vedeným rámcom pre toto rozhodovanie, bude mať oveľa jednoduchšiu diskusiu než tá, ktorá ho rekonštruuje dodatočne.
Čisté účtovníctvo uľahčuje obhajobu odborných úsudkov
Každý účtovný úsudok – a „pravdepodobnosť dokončenia" je jednoznačne úsudkom – je len tak obhájiteľný, ako sú záznamy, ktoré ho podopierajú. Ak vaša účtová osnova už teraz oddeľuje výdavky na výskum a vývoj podľa projektov a vaše účtovné zápisy sú verzované a auditovateľné namiesto toho, aby žili v odpojených tabuľkách, uplatnenie normy ako ASU 2025-06 sa stáva otázkou označovania existujúcich dát namiesto rekonštrukcie histórie zo Slack vlákien. Plain-text účtovníctvo od Beancount.io vám takýto transparentný, git-verzovaný denník poskytuje ako štandard – každý zápis vysledovateľný, každá zmena kontrolovateľná, bez viazanosti na dodávateľa. Začnite zadarmo a vybudujte si účtovníctvo, ktoré obstojí, či už otázka príde od audítora, nadobúdateľa, alebo ďalšej aktualizácie FASB.