underlåtenhet att vidta denna inledande åtgärd kan göra det svårt att korrekt separera kostnaderna mellan de som ska aktiveras och de som ska spenderas. Detta kan leda till fel i tillämpningen av god redovisningssed samt fel i mängden nettoresultat eller förlust enheter rapport., Denna artikel är utformad för att hjälpa läsarna att svara på denna fråga: vilka programvarukostnader ska aktiveras och vilka kostnader ska spenderas när en enhet bygger extern programvara med hjälp av en smidig utvecklingsmiljö?
trenden mot smidig utveckling
mjukvaruutvecklingsmetoden som kallas agile har blivit populär inom mjukvaruindustrin de senaste åren., Eftersom det smidiga tillvägagångssättet (se” Agile Approach ” – diagrammet) allmänt uppfattas vara snabbare och mer lyhörd för snabbt föränderliga krav, använder många företag det nu som ett föredraget alternativ till den traditionella vattenfallsutvecklingsmetoden.
den konventionella vattenfallsutvecklingsmetoden innebär att man organiserar ett projekt i en rad traditionella faser, såsom uppfattning, initiering, analys, design, konstruktion, testning, produktion och genomförande och underhåll., Dessa faser präglas av aktiviteter, som vägledningen använder som ram för att dra en slutsats om när teknisk genomförbarhet uppnås och kostnader för programvaruutvecklingsprojekt kan aktiveras.
under en smidig modell organiseras å andra sidan ett projekt i separata moduler, och utvecklings-och testarbetet på dessa moduler görs i korta sprints., Att identifiera när de traditionella aktiviteterna i vattenfallsmetoden uppstår kräver betydande analys och bedömning i smidig utveckling, vilket kan göra det svårare att tillämpa GAAP-vägledning för att kapitalisera kostnader.
i slutändan kan både de smidiga och vattenfallsmodellerna producera ett framgångsrikt projekt; men att bestämma punkten i mjukvaruutvecklingsprocessen för att börja och sluta kapitalisera kostnader kan vara mer utmanande med den smidiga modellen.,
2 uppsättningar av programvara kapitaliseringsregler
som utgångspunkt för att på lämpligt sätt kapitalisera kostnader för mjukvaruutveckling, är det viktigt att bestämma rätt vägledning. Enligt US GAAP kan två potentiella uppsättningar av viktiga regler gälla vid bestämning av huruvida programvaruutvecklingskostnader ska aktiveras eller kostnadsförs.
en uppsättning regler (FASB Accounting Standards Codification (ASC) ämne 985, programvara) är utformad för programvarukostnader som företaget avser att sälja eller hyra., Dessa regler, vanligen kallad programvara kapitaliseringsregler för extern användning programvara, är det primära fokus i denna artikel. Den andra uppsättningen regler (ASC ämne 350, immateriella — Goodwill och andra) styr programvara som företaget inte har för avsikt att sälja eller hyra. Dessa regler brukar kallas programvaru kapitalisering regler för internt bruk programvara.
det är viktigt att notera att tröskeln för aktivering är lägre för internt bruk., Enligt reglerna för internt bruk kan utvecklingskostnaderna i allmänhet aktiveras efter slutet av det preliminära projektfasen. Tröskeln för programvaruutvecklingskostnader för extern försäljning eller licensiering — fokus i denna artikel — är strängare, vilket innebär att mer analys krävs för att bestämma vilka utvecklingskostnader som ska kapitaliseras.
där GAAP och agile inte anpassar
under Ämne 985 kretsar den kritiska frågan för att avgöra om externa programvaruutvecklingskostnader ska aktiveras kring termen ”teknisk genomförbarhet”.,”Eventuella kostnader för mjukvaruutveckling som uppstår före den punkt där projektet har visat teknisk genomförbarhet bör kostnadsföras när de uppstår.
När den tekniska genomförbarheten har fastställts kan de flesta (men inte alla) utvecklingskostnaderna aktiveras. Slutligen, när utvecklingen är klar och programvaran görs tillgänglig för release till kunder, aktivering är inte längre lämpligt eftersom eventuella återstående kostnader anses löpande underhåll och support. Dessa kostnader måste alltid kostnadsförs eftersom de uppstår.,
definitionen av ”teknisk genomförbarhet” är därför den kritiska faktorn för att bestämma när ett företag ska börja utnyttja sina utvecklingskostnader. Ämne 985 säger: ”den tekniska genomförbarheten av en datorprogramvaruprodukt är etablerad när enheten har slutfört all planering, design, kodning och testverksamhet som är nödvändiga för att fastställa att produkten kan produceras för att uppfylla sina konstruktionsspecifikationer, inklusive funktioner, funktioner och tekniska prestandakrav.,”Det är också viktigt att notera att programvaruutvecklingskostnaderna omfattas av dessa regler oavsett om kostnaderna genererades internt (t.ex. anställningstid) eller externt (t. ex. leverantörsavgifter).
i konventionella mjukvaruutvecklingsprojekt med väldefinierade, på varandra följande faser demonstreras teknisk genomförbarhet i allmänhet genom antingen en detaljerad programdesign eller, när en detaljerad programdesign saknas, en arbetsmodell som är klar för kundprovning. Dessa är kända milstolpar för projekt som använder vattenfallsmetoden.,
i en smidig projektmiljö utvecklas dock enskilda funktioner och funktioner separat i en serie sprintar. Varje sprint eller modul planeras, finansieras, utvecklas och testas individuellt för att införlivas i det övergripande projektet när det är klart.
i en sådan miljö är omfattande programdesigner eller arbetsmodeller ofta opraktiska eller irrelevanta., Företag som använder ett agilt tillvägagångssätt för att utveckla programvara kan dra otillbörligt slutsatsen att teknisk genomförbarhet inte har uppfyllts väsentligt innan programvaruförbättringen är tillgänglig för kunderna, vilket resulterar i att kostnaderna kostnadsförs som uppkommit snarare än att kapitaliseras. Om betydande kostnader uppstår mellan när den tekniska genomförbarheten faktiskt nåddes och när programvaran är tillgänglig för kunderna, kan den resulterande redovisningen vara oförenlig med god redovisningssed.,
tillämpa GAAP i en smidig miljö
även om nuvarande GAAP-vägledning för extern användning inte är anpassad till den agila miljön, betyder det inte att agila utvecklingskostnader inte kan aktiveras alls. Det finns trots allt varierande nivåer av smidighet. Medan ett rent smidigt projekt kan börja med bara en idé och relativt lite designarbete, har vissa smidiga projekt detaljerade programdesigner med djupgående storyboarding, marknadsgodkännandestudier och andra designarbetsdokument som sätts ihop innan den faktiska utvecklingen börjar., Sådana dokument skulle kunna användas för att bedöma den tekniska genomförbarheten.
den kritiska punkten att komma ihåg är att för att bedöma de kostnader som ska aktiveras måste det finnas tillräcklig projektplanering för att visa att kriterierna för en ”detaljerad programdesign” har uppfyllts. Risken är att projektgrupper kanske inte gör tillräckligt med planering i förväg eller behåller tillräcklig dokumentation för att visa att de har uppfyllt detta tröskelvärde., Att visa teknisk genomförbarhet kommer sannolikt att kräva att projektgruppen gör mer planering och sammanställer mer dokumentation än vad som är typiskt i de flesta smidiga projekt.
andra viktiga överväganden vid bestämning av teknisk genomförbarhet avser högriskutvecklingsfunktioner. Till exempel, är projektet en helt ny mjukvaruplattform, eller är det en förbättring eller återskapande av något som har gjorts tidigare? Är företaget utvecklar programvara från grunden, eller är det pussla ihop olika programvarukomponenter som redan finns?, Högriskutvecklingsfunktioner kan kräva ytterligare analys av när teknisk genomförbarhet uppnås och i vissa fall utgifter för tidigare aktiverade kostnader.
produktförbättringar som inte anses underhållsaktiviteter kan ibland lättare uppfylla den tekniska genomförbarhetsgränsen eftersom utvecklarna lägger till funktioner till en redan framgångsrik produkt. Avgörande faktorer i sådana fall inkluderar typen av programvara, nivån på modifiering som krävs och nivån på designarbetet som slutfördes före utvecklingsstart.,
även när teknisk genomförbarhet är etablerad kan inte alla agila utvecklingskostnader aktiveras. I de flesta fall kan endast en del av kostnaderna i varje sprint aktiveras. De kostnader som inte bör kapitaliseras inkluderar inledande analys, kunskapsförvärv, inledande projektplanering, prototypning och jämförbart designarbete som måste göras för att uppnå förståelse för produktens önskade egenskaper och genomförbarhet.
men stora delar av kostnaderna för att utveckla och testa sådana funktioner bör ofta aktiveras om teknisk genomförbarhet uppnås., Dessa kostnader inkluderar faktiska kodning, testning och tillhörande arbetskostnader.
tänk dock på att eventuella underhålls-eller felkorrigeringskostnader som uppstår under sprinten kan behöva spenderas i stället för att aktiveras, eftersom många aktiviteter under sprinten kanske inte är kodning och testning men kan vara aktiviteter som felsökning och upptäckt. Dessutom slutar kapitaliseringen när projektet är klart och programvaran är klar för användning.,
att skilja mellan kostnader som kan aktiveras och de som inte kan aktiveras kan komplicera projektredovisningen, rapporteringen och dokumentationsstegen inom varje sprint något. Men det extra administrativa arbetet behöver inte vara betungande. I de flesta fall kan de olika uppgifterna och resultaten inom varje sprint segmenteras i breda kategorier, så att alla kostnader i samband med den uppgiften kan antingen kostnadsförs eller kapitaliseras.,
förberedelse och kommunikation: de kritiska stegen
att bestämma vilka externa programvaruutvecklingskostnader som kan aktiveras i en smidig projektmiljö innebär en viss bedömning. I många fall kommer de specifika fakta och omständigheter som omger den typ av programvara som utvecklas att driva behandlingen av kostnader. Noggrann planering kan hjälpa till i analysen av vilka kostnader för att kapitalisera kontra kostnad.,
av denna anledning är det vanligtvis lämpligt att diskutera bokföringsbehandlingen med projektledningsgruppen och ämnesexperterna innan du börjar ett stort utvecklingsprojekt. Det är också viktigt att redan från början av ett projekt förstå nivån på stöd och dokumentation som kommer att behövas för att möjliggöra lämpliga beslut om kapitalisering av kostnader. Dessutom krävs en tydlig förståelse för den dokumentationsnivå som måste upprätthållas för revisorer att utvärdera och bekräfta kapitalisering och kostnadsbeslut.,
till exempel bör projektgruppen noggrant dokumentera varje persons roll i projektet så att redovisning kan skilja mellan de personer vars tid och aktiviteter potentiellt kan bli föremål för kapitalisering och de vars aktiviteter aldrig skulle falla i denna kategori. Det är också viktigt att upprätthålla ytterligare interna kontroller som månatliga recensioner av aktiviteter, aktiverade och kostnadsförda belopp och kommunikationsmallar som projektledare kan fylla i för att verifiera att anställningstiden är kodad korrekt.,
även om vissa branschdiskussioner om uppdatering av relevanta standarder för att göra dem mer tillämpliga på den smidiga ramen har inträffat, medför sådana uppdateringar vanligtvis flera års planering, diskussion, förslag och återkoppling från industrin. Det innebär att företag som använder en smidig modell för att utveckla programvara för extern försäljning eller licensiering under överskådlig framtid kommer att behöva fortsätta att samordna nära med sina redovisningsteam för att tillämpa den befintliga GAAP-vägledningen och kapitalisera utvecklingskostnaderna på lämpligt sätt.
Lämna ett svar