Unnlatelse av å ta denne innledende handling kan gjøre det vanskelig å riktig separate kostnader mellom de som skal aktiveres og de som skal resultatføres. Dette kan føre til feil i anvendelsen av GAAP, samt feil i mengden av netto inntekt eller tap enheter rapporten., Denne artikkelen er utformet for å hjelpe leserne med å svare på dette spørsmålet: hvilken programvare Som kostnadene skal aktiveres og hvilke kostnader skal resultatføres når en enhet bygger ekstern-bruke programvare ved hjelp av et fleksibelt utviklingsmiljø?
trenden mot smidig utvikling
programvare utviklingen metode som kalles smidige har blitt populært i software bransjen i de siste årene., Fordi smidig tilnærming (se «Smidig Tilnærming» diagram) er allment oppfattet å være raskere og mer responsiv til raskt skiftende krav, mange selskaper nå bruker det som et foretrukket alternativ til den tradisjonelle foss utvikling tilnærming.
Den konvensjonelle foss utvikling tilnærming innebærer å organisere et prosjekt inn i en serie av tradisjonelle faser, slik som conception, initiering, analyse, design, konstruksjon, testing, produksjon og implementering og vedlikehold., Disse fasene er preget av aktiviteter, som veiledning bruker som et rammeverk for å lage en konklusjon på når teknologiske mulighetene er oppnådd og utvikling av programvare-prosjekt kostnadene kan bli aktivert.
Under en smidig modell, på den annen side, et prosjekt som er organisert i separate moduler, og utvikling og testing arbeid på disse modulene er ferdig i korte spurter., Identifisere når den tradisjonelle aktiviteter av fossen tilnærming oppstå krever betydelige analyse og vurdering i smidig utvikling, noe som kan gjøre det mer vanskelig å bruke GAAP veiledning for balanseføring av utgifter.
til Slutt, både smidig og foss-modeller kan produsere et vellykket prosjekt, men å bestemme punktet i software utvikling til å starte og avslutte utnytte kostnader kan være mer utfordrende med den smidige modellen.,
2 sett med programvaren, bruk av store bokstaver regler
Som et utgangspunkt til å kunne kapitalisere programvare utvikling kostnader, er det viktig å finne riktig veiledning. Under US GAAP, to potensielle sett av viktige regler gjelder når man skal avgjøre om software development kostnadene skal aktiveres eller kostnadsføres.
Ett sett med regler (FASB regnskapsstandarder Kodifisering (ASC) Emne 985, – Programvaren) er designet for software kostnader som foretaket har til hensikt å selge eller leie ut., Disse reglene, som ofte referert til som programvaren store bokstaver regler for ekstern-bruke programvare, det primære fokus i denne artikkelen. Det andre sett av regler (ASC Emnet 350, immaterielle eiendeler — Goodwill og Andre) regulerer programvare som enheten ikke har til hensikt å selge eller leie ut. Disse reglene ofte blir referert til som programvaren store bokstaver regler for intern-bruke programvare.
Det er viktig å merke seg at terskelen for bruk av store bokstaver er lavere for intern-bruke programvare., Under den interne-bruke programvare regler, utvikling kostnader generelt kan aktiveres etter slutten av forprosjektet scenen. Terskelen for utvikling av programvare kostnader for eksterne salg eller lisensiering — fokus i denne artikkelen er mer strenge, noe som betyr mer analyse er nødvendig for å fastslå hvilke utviklingskostnader som skal være aktivert.
Hvor GAAP og smidig ikke justerer
Under Emnet 985, det avgjørende spørsmålet i vurderingen av om ekstern-bruke programvare utvikling kostnadene skal aktiveres dreier seg om begrepet «teknologisk gjennomførbarhet.,»Noen programvare utvikling kostnader som er påløpt før det punktet hvor prosjektet har vist at det er teknologisk gjennomførbarhet skal resultatføres når de påløper.
Når teknologiske mulighetene har blitt etablert, de fleste (men ikke alle) utviklingskostnader kan aktiveres. Til slutt, når utviklingen er fullført, og programvaren er gjort tilgjengelig for utslipp til kunder, store og små bokstaver ikke lenger er hensiktsmessig fordi eventuelle gjenværende kostnader er vurdert kontinuerlig vedlikehold og støtte. Disse kostnadene må alltid bli kostnadsført når de påløper.,
definisjonen av «teknologisk gjennomførbarhet» er derfor en kritisk faktor i å bestemme når et selskap skal begynne å utnytte sine utviklings kostnader. Emnet 985 sier, «de teknologiske mulighetene for en datamaskin programvare produkt er etablert når foretaket har fullført all planlegging, design, koding og testing aktiviteter som er nødvendig for å fastslå at produktet kan produseres for å møte sin design spesifikasjoner, inkludert funksjoner, funksjoner og tekniske krav til ytelse.,»Det er også viktig å merke seg at utvikling av programvare kostnader er i henhold til disse regler, uavhengig av om kostnadene var generert internt (slik som ansatt tid) eller eksternt (for eksempel leverandør gebyrer).
I konvensjonell programvare utviklingsprosjekter med godt definert, etterfølgende faser, teknologisk gjennomførbarhet generelt er demonstrert gjennom enten en detaljert program design eller, når et mer detaljert program design er fraværende, en fungerende modell som er klare for kunden testing. Disse er kjent milepæler for prosjekter ved hjelp av fossen tilnærming.,
I et smidig prosjekt miljøet, men enkelte funksjoner er utviklet separat i en serie av sprinter. Hver sprint eller modul er tenkt, planlagt, finansiert, utviklet og testet individuelt for å bli innlemmet i prosjektet som sådan når den er klar.
I et slikt miljø, omfattende program design eller arbeider modeller ofte er upraktisk eller irrelevant., Selskaper som bruker en smidig tilnærming for å utvikle programvare kan inngå feilaktig at teknologiske mulighetene har ikke blitt møtt betydelig før programvaren ekstrautstyr er tilgjengelig for kunder, noe som resulterer i kostnader blir kostnadsført når de påløper i stedet for å bli aktivert. Hvis det er vesentlige kostnader påløper mellom når teknologisk gjennomførbarhet faktisk var nådd og når programvaren er tilgjengelig for kundene, noe som resulterer regnskap kan være i strid med god regnskapsskikk.,
Søker GAAP i et fleksibelt miljø
Selv om gjeldende GAAP veiledning for eksterne-bruke programvare er ikke tilpasset fleksibelt miljø, det betyr ikke at smidig utvikling kostnader kan ikke være aktivert til alle. Det er, tross alt, varierende grad av smidighet. Mens en ren smidig prosjekt kan begynne med bare en idé, og relativt lite design-arbeid, noen smidige prosjekter har detaljert program design med i dybden storyboard (dreiebok), markedsaksept studier, og andre design dokumenter, sette sammen før den faktiske utviklingen starter., Slike dokumenter kan brukes til å hjelpe til med å vurdere de teknologiske mulighetene.
Det kritiske punktet å huske er at for å kunne vurdere kostnader som skal aktiveres, må det være tilstrekkelig prosjektet planlegger å demonstrere at kriteriene for en «detaljert program design» har blitt møtt. Risikoen er at prosjektgruppen kan ikke gjøre nok front-end planlegging eller beholde tilstrekkelig dokumentasjon for å vise at de har møtt denne terskelen., Viser teknologisk gjennomførbarhet er sannsynlig å kreve prosjektgruppen til å gjøre mer planlegging og innhente mer dokumentasjon enn det som er typisk i de fleste smidige prosjekter.
Andre viktige hensyn å ta når man skal avgjøre teknologiske mulighetene knyttet til høy risiko for utvikling funksjoner. For eksempel er prosjektet en helt ny programvare-plattformen, eller er det en utvidelse eller rekonstruksjon av noe som har blitt gjort før? Er selskapet utvikler programvare fra bakken og opp, eller er det å sette sammen ulike komponenter som allerede finnes?, Høy risiko for utvikling funksjoner kan kreve ekstra analyse av når teknologiske mulighetene er nådd, og i noen tilfeller, kostnadsføring av tidligere balanseførte kostnader.
produktforbedringer som ikke regnes som vedlikehold aktiviteter noen ganger kan møte de teknologiske mulighetene terskelen lettere fordi utviklerne er å legge til funksjoner til et allerede vellykket produkt. Avgjørende faktorene i slike tilfeller er hvilken type programvare, graden av endring som kreves, og nivået av design arbeid som ble fullført før starten av utviklingen.,
Selv når teknologiske mulighetene er etablert, er det ikke alle smidig utviklingskostnader kan aktiveres. I de fleste tilfeller bare noen av kostnadene i hver sprint kan være aktivert. Kostnader som ikke skal balanseføres inkluderer forhånd analyse, tilegnelse av kunnskap, første prosjekt planlegging, prototyping, og sammenlignbare design arbeid som må gjøres for å oppnå en forståelse av produktet ønskede funksjoner og gjennomførbarhet.
Men store deler av de kostnader som påløper for å utvikle og teste slike funksjoner ofte bør bli balanseført hvis teknologiske mulighetene er oppnådd., Disse kostnadene inkluderer faktiske koding, testing, og tilhørende lønnskostnader.
husk, imidlertid, at alle vedlikeholds-relatert eller feil-korrigering kostnader som er påløpt under sprint kan trenge å bli kostnadsført snarere enn balanseført, som mange aktiviteter under sprint-kan ikke være koding og testing, men kan være aktiviteter som feilsøking og discovery. Videre er bruk av store bokstaver avsluttes når prosjektet er fullført og at programvaren er klar for bruk.,
å Skille mellom kostnader som ikke kan aktiveres og de som ikke kan bli aktivert kan komplisere prosjektet regnskap, rapportering og dokumentasjon trinn innenfor hver sprint noe. Men de ekstra administrative arbeidet behøver ikke å være tung. I de fleste tilfeller de ulike oppgaver og leveranser innenfor hver sprint kan være opp i kategorier, slik at alle kostnader forbundet med at oppgaven kan være enten betalt eller aktivert.,
Forberedelse og kommunikasjon: Den kritiske trinn
å Bestemme hvilke eksterne-bruke programvare utviklingskostnader kan aktiveres i et smidig prosjekt miljø innebærer en viss grad av skjønn. I mange tilfeller er de konkrete fakta og omstendigheter rundt den typen programvare som er utviklet vil drive behandling av kostnader. Grundig planlegging kan være til hjelp i analysen av hvilke kostnader for å dra nytte versus kostnader.,
på grunn av dette, er det vanligvis lurt å diskutere regnskapsmessig behandling med prosjekt ledelse og gjenstand eksperter før du starter noen stor utvikling prosjekt. Det er også viktig å forstå fra begynnelsen av et prosjekt nivået av støtte og dokumentasjon som vil være nødvendig for å muliggjøre den nødvendige beslutninger om balanseføring av kostnader. I tillegg, en klar forståelse er nødvendig for graden av dokumentasjon som må opprettholdes for revisor å vurdere og bekrefter den store bokstaver og utgiftsføre beslutninger.,
For eksempel, prosjektgruppen bør grundig dokument hver persons rolle i prosjektet, slik at bokføringen kan skille mellom de individer som har tid og aktiviteter kan potensielt bli utsatt for store bokstaver, og de som har aktiviteter som ville aldri falle inn i denne kategorien. Det er også viktig å opprettholde flere interne kontroller som månedlige vurderinger av aktiviteter, aktivert og kostnadsført beløp, og kommunikasjon maler som prosjektledere kan fylle ut for å bekrefte at de ansattes tid er kodet på riktig måte.,
Selv om noen industrien diskusjon av å oppdatere gjeldende standarder til å gjøre dem mer egnet til smidige rammeverk som har skjedd, slik oppdateringer vanligvis innebære flere år med planlegging, diskusjon, forslag og industri tilbakemeldinger. Det betyr at i overskuelig fremtid, selskaper som bruker en smidig modell for å utvikle programvare for ekstern salg eller lisensiering trenger for å fortsette å koordinere tett med sine regnskap lagene til å anvende eksisterende GAAP veiledning og kapitalisere utviklingskostnader på en hensiktsmessig måte.
Legg igjen en kommentar