Hjem » IAS 38

Balanseføring av egenutviklet programvare

12 august 2010 8,325 views 11 kommentarer

Mitt firma som utvikler programvare for internt bruk (selv om det kunne også bli solgt til andre lignende selskaper). Det nesten alltid erstatter den programvaren vi kjøpt på tidligere tidspunkt, slik at det genererer synlige økonomiske fordeler ved å redusere kostnadene. Kan vi utnytte vår internt utviklet programvare?

Relaterte innlegg

  1. Obligasjonslån knyttet kostnader
  2. Revisjon av programvaren nyttig fil
  3. Endring i livet av dataprogrammer 16 IAS, 8 IAS
  4. Programvare bokstaver / Kostnadsført ut
  5. Kostnadsregnskap og programvare
  6. Dato for Comercial produksjon
  7. Software inntektsføring i henhold til IFRS og SOP 97 -
  8. Audit programvare
  9. Intern revisjon programvare
  10. Programvare kapitalisering
1 Star2 Stars3 Stars4 Stars5 Stars (Ingen stemmer enda)
Loading ... Loading ...

11 Kommentarer »

  • ifrslist
    ifrslist sa:

    [Ny Post] Balanseføring av internt utviklet software - http://www.ifrslist.com/2010/08/capitali .. .
    via Twitoaster

  • Mladek sa:

    Dessverre, i motsetning til US GAAP ( ASC 350-40 ). IFRS ikke spesifikt håndtere programvare. IAS 38 gjør imidlertid håndtere internt utviklede immaterielle eiendeler (som inkluderer software).

    IAS 38 skisserer 6 kriterier som må oppfylles dersom utbyggingskostnadene skal balanseføres. Av disse demonstrerte (IAS 38.57.d) "hvordan eiendelen vil generere fremtidige økonomiske fordeler ..." er den mest tapsbringende.

    I min mening, hvis foretaket planlegger å bruke eiendelen internt, ville det ikke ha noen problem å demonstrere "nytten av den immaterielle eiendelen", så det kunne kapitalisere.

    Dessverre er dette ikke den eneste utsikten. For eksempel Epstein mener det ikke er mulig å demonstrere hvordan SV vil generere økonomiske fordeler og at (selv selv om IFRS anerkjenner både juridiske og separable immaterielle eiendeler) fravær av en kjøpt lisens utelukker bokstaver.

    Jeg personlig tror Barry er en idiot, men, men det forandrer ikke det faktum at hans valg ikke bære mye vekt (mye mer enn min).

    Heldigvis er de ikke definitive.

    IAS 8.12 stater "Ved å gjøre dommen beskrevet i punkt 10, kan ledelsen også vurdere de nyeste uttalelser fra andre standardsettende organer som bruker en lignende konseptuelt rammeverk for å utvikle regnskapsstandarder, ...", som betyr at (siden IFRS ikke forholde eksplisitt med problemet) det er akseptabelt å vurdere relevant US GAAP.

    At US GAAP (ASC 350-40-25) er ganske eksplisitt: "-1 Interne og eksterne kostnader som påløper i løpet av forprosjektet scenen skal kostnadsføres når de påløper. -2 Interne og eksterne kostnader som påløper for å utvikle intern bruk dataprogram under søknaden utviklingsfasen skal aktiveres. -3 Kostnader å utvikle eller anskaffe programvare som gir mulighet for tilgang til eller ombygging av gamle data av nye systemer skal også balanseføres. -4 Training kostnadene er ikke intern bruk programvare utviklingskostnader, og hvis påløpt i denne fasen, skal kostnadsføres løpende. -5Data konverteringskostnader, unntatt som angitt i punkt 350-40-25-3, skal kostnadsføres løpende. -6 Interne og eksterne opplæring kostnader og vedlikeholdskostnader under postimplementation-operasjonen scenen skal kostnadsføres når de påløper. "

    Så, så vidt jeg er bekymret, kostnader ved internt utviklede SW er egnet for balanseføring under IFRS, og hvis jeg får motstand, kan jeg alltid falle tilbake på US GAAP.

    Men jeg må også påpeke en mer liten ting.

    US GAAP (350-40-35) sier også: "-7 Dersom det etter utbygging av intern bruk programvaren er ferdig, bestemmer et foretak å markedsføre programvaren, fortsetter mottatt fra lisens av dataprogram ... skal anvendes mot balanseført verdi av den programvaren. -8 Ingen fortjeneste skal anerkjennes inntil samlet netto proveny fra lisenser og amortisering har redusert den balanseførte verdien av programvaren til null. ... "

    Dermed, hvis man gjør bruk US GAAP å rettferdiggjøre Oen dom som per IFRS, og ens selskapet ikke bestemme seg for å selge programvaren, vil det ikke være i stand til å spille inn noen inntekter til den store fortrinn er fullt fraregnet.

    Dette gjør US GAAP en tveegget sverd. På den ene siden, gjør det rettferdiggjøre dommen å kapitalisere lett, på den andre, utelukker det erkjenner mye av inntektene. Men det er bare slik det går.

  • patriciawalters sa:

    Jeg er enig i at IAS 38 tillater deg å kapitalisere utviklingskostnader så lenge kriteriene er oppfylt. Ifølge paragraf 57 i IAS 28, må du kunne vise til ALLE følgende før du kan begynne å utnytte kostnader:

    (1) teknisk gjennomførbarhet av å fullføre den immaterielle eiendelen slik at den vil være tilgjengelig for bruk eller salg
    (2) sin intensjon om å fullføre den immaterielle eiendelen og bruke eller selge den.
    (3) sin evne til å bruke eller selge den immaterielle eiendelen
    (4) hvordan den immaterielle eiendelen vil generere fremtidige økonomiske fordeler. Blant annet kan foretaket demonstrere eksistensen av et marked for produksjon av den immaterielle eiendelen eller den immaterielle eiendelen selv eller, hvis det skal brukes internt, nytten av den immaterielle eiendelen.

    Så absolutt, tillater dette deg til å kapitalisere noen av kostnadene forbundet med utvikling av intern bruk programvare. Du vil ikke kunne kapitalisere eventuelle kostnader du har kostnadsført før møte disse kriteriene. Du vil ikke bli capitalizing alle dine utgifter.

    Astra Zeneca er en bedrift som avdekker "Programvare utbyggingskostnadene" som en egen aktivaklasse i note 9, Immaterielle eiendeler ".

    Jeg har sett andre også.

    Håper dette hjelper.

    Patricia Walters

  • patriciawalters sa:

    Jeg mente å legge til.

    Det er ingen grunn til å gå til US GAAP krav eller begrensninger.

    IFRS gjør avtale med kapitalisering av utbyggingskostnader for immaterielle eiendeler som skal brukes internt. Det faktum at standarden ikke si: "Å, forresten, er programvare en immateriell som du kan utvikle internt", ikke er relevant.

    Programvare er en immateriell som kan være (og ofte er) utviklet internt og kapitalisering vedtaket er omfattet av IAS 38.

    US GAAP er irrelevant. Etter mitt syn ville det være upassende å se til US GAAP for veiledning fordi IAS 38 forklarer tydelig hva kriteriene for balanseføring er.

    Patricia Walters

  • patriciawalters sa:

    "Sier" bør "ikke si" i mitt forrige innlegg. Unnskyld.
    Patricia

  • Mladek sa:

    Selv om jeg er enig (som jeg nevnte i mitt første innlegg) at IAS 38 ikke utelukker utnytte internt utviklet SW, anvendelsen av nr. 57 (i praksis) er alt annet enn klar og enkel.

    Hvis det var, leste publikasjoner (som WILEY tolkning og anvendelse av International Financial Reporting ... Av Barry J. Epstein, Eva K. Jermakowicz) ikke ville komme til motsatt konklusjon.

    Hvis det var, ville revisor signere på selskaper capitalizing alt, inkludert kjøkkenvasken.

    Hvis det var, ville jeg ikke ha brydd siterer US GAAP.

    I alle tilfelle, jeg sier ikke at det er umulig å overbevise en skeptisk revisor at man har oppfylt alle kriteriene som er skissert i punkt 57. Det jeg sier er at det ikke kan være en Slam-dunk.

    Dette er særlig tilfelle i kontinental-Europa, hvor man ikke kjøre inn revisorer som, mens ekspert i å bruke sine egne "nasjonale GAAPs", har liten førstehånds erfaring tolke og anvende IFRS (eller systemer, for eksempel US GAAP eller britisk GAAP, utviklet av standardsettende organer med lignende konseptuelle rammeverk).

    Som til US GAAP være irrelevant, ville det være, hvis IFRS ikke eksplisitt oppgir det motsatte.

    IAS 8.12: "Ved å gjøre dommen beskrevet i punkt 10, kan ledelsen også vurdere de nyeste uttalelser fra andre standardsettende organer som bruker en lignende konseptuelt rammeverk for å utvikle regnskapsstandarder, andre regnskap litteratur og aksepterte bransjepraksis, i den grad disse ikke strider med kildene i punkt 11 ",

    Paragraf 10 sier: "I mangel av en IFRS som spesifikt gjelder for en transaksjon, annen hendelse eller tilstand, skal ledelsen bruke skjønn i å utvikle og anvende et regnskapsmessig policy ...".

    Nå, korrigere meg hvis jeg tar feil, men jeg har aldri lagt merke til en IFRS at (som ASC 350-40) spesifikt gjelder interne brukervennlig programvare.

    Dette innebærer at dersom noen skulle spørre min dom at Intern brukervennlig programvare er capitalizable, i tillegg til IAS 38.57, kunne jeg også peke på en standard (angitt av en standard-innstilling kroppen som bruker en lignende konseptuelt rammeverk for å utvikle regnskapsstandarder ) som sier at min dom er GAAP.

    Også, som en ekstra fordel, gir US GAAP eksplisitt, tydelig og lett å følge instruksjonene på hvordan du setter opp et regnskap prosedyre for å utføre denne oppgaven.

    De eneste grunnene til at jeg kan se hvorfor noen ikke ønsker å benytte seg av en slik mulighet:

    1. en er ikke klar over at US GAAP eksisterer

    2. en er ikke kjent med innholdet

    3. en innser ikke at det kan brukes til å supplere IFRS (spesielt i situasjoner hvor IFRS er noen ganger uklar, abstrakt og teoretisk veiledning er vanskelig å oversette til dag-til-dag praksis).

  • patriciawalters sa:

    Jeg sa aldri noe som gjør disse beslutningene var lett. Knapt noen finansiell rapportering avgjørelse i disse dager er enkelt. Som jeg sier til mine studenter, hvis disse avgjørelsene var lett og det var alltid et klart svar, ville de ikke være ute etter å lage "big bucks" på konfirmasjonen.

    Imidlertid er filosofien bak IFRS 'prinsipper tilnærming til finansiell rapportering for at standarden ikke gir en liste over alle bestemt element som standard gjelder eller ikke gjelder.

    Programvare er en immateriell eiendel. Derfor gjelder IAS 38.
    IAS 38 omfatter immaterielle eiendeler utviklet internt for eget bruk. Derfor kan utviklingskostnader forbundet med internt utviklet programvare skal balanseføres i henhold til IAS 38 dersom kriteriene for balanseføring er oppfylt.

    Noen selskaper trenger kanskje ikke å se til veiledning utover hva som er tilgjengelig i IAS 38 for å avgjøre om disse kriteriene er oppfylt og det er ingen krav om å gjøre det.

    Faktisk er det en fare i umiddelbart hoppe til veiledning gitt av andre standard-settere (US GAAP) eller utvikler en vane å gjøre det. Slik veiledning er ikke alltid forenlig med IFRS eller dets begrepsapparat og preparers må være årvåken i å bruke den svært detaljerte retningslinjer gitt av US GAAP at det vil gi resultater i samsvar med IFRS.

    Til slutt, for tiden tilgjengelig skriftlig materiale som for eksempel den boken du sitere er ikke autoritativ veiledning på enten IFRS eller US GAAP. Alt som er skrevet i den boka, uansett hvor godt respekterte forfattere, er rent deres vurderes mening. De er menn (og kvinner), ikke guder eller IASB eller IFRIC. Derfor føler jeg fri til å være uenig med forfatterne av slike bøker. Og ofte gjør. Akkurat som vi er uenige her.

    Hvis du mener at ytterligere veiledning er nødvendig om hvordan å bedømme hvorvidt en bestemt kriterium i IFRS er utilstrekkelig og trenger avklaring, stedet å gå for at ytterligere veiledning er enten IFRIC eller IASB. Ikke US GAAP.

    Ellers er du i utgangspunktet fortelle folk til å lære et minimum av to sett med regnskapsstandarder, snarere enn den de er forventet å søke. Hva er poenget med at anbefaling?

    Patricia Walters

  • Mladek sa:

    Jeg er enig med deg.

    Prinsipper basert betyr å få lov til å nå ens eget faglige skjønn. Men at dommen ikke lever i et vakuum. Dom må være begrunnet (til ens overordnede, en revisor, eventuelt en regulator, og dersom verre kommer til verre, ved hoffet).

    Som mennesker har til å "lære et minimum av to sett med regnskapsstandarder, snarere enn den de er forventet å søke."

    På hvilket punkt akkurat ikke blitt mindre kunnskap overlegen til mer kunnskap?

    Også er jeg ikke anbefale noe. Dette er en åpen diskusjon. Jeg er ikke blitt betalt for mine tjenester. Jeg en ikke blir bedt om å ta ansvar for min dom. Folk kan lese hva jeg skrev, bruke informasjonen, eller ikke. Jeg kunne ikke vare mindre hvilken vei de bestemmer.

    Jeg bare påpeker at mens IFRS omhandler ikke klart emnet på hånden, gjør US GAAP.

    Jeg er også peke på at, mens IFRS selskaper ikke er forpliktet til å følge denne veiledningen, er det ikke (siden IFRS ikke gir motstridende veiledning) til følge.

    Å, BTW, var det ikke jeg som åpnet døren til enten US GAAP eller ikke-autoritative litteratur. IASB klarte å gjøre det helt av seg selv ved å si "Ved å gjøre dommen beskrevet i punkt 10, kan ledelsen også vurdere ... annen regnskapsinformasjon litteratur og akseptert bransjepraksis, i den grad disse ikke strider ...".

    Dette betyr også, autoritative eller ikke, ikke slik litteratur har en innflytelse på praksis. Bare ønsker det ikke var slik, vil ikke gjøre ikke det.

    Når det gjelder råd som: "Hvis du mener at ytterligere veiledning er nødvendig om hvordan å bedømme hvorvidt en bestemt kriterium i IFRS er utilstrekkelig og trenger avklaring, er stedet å gå for at ytterligere veiledning enten IFRIC eller IASB".

    Dette rådet er spot on, men (ganske åpenbart) relevant kun i de situasjoner hvor IASB eller IFRIC har besluttet å gi slik veiledning.

    Så vidt jeg vet, den eneste "autoritative" veiledning gitt på temaet for hånden er disse tre ordene (fet skrift): "IAS 38.62 Et foretaks koster systemer kan ofte måle pålitelig kostnaden for å generere en immateriell eiendel internt, slik som lønn og andre utgifter som påløper i å sikre opphavsrett eller lisenser eller utvikle programvare. "

    Pretty knappe pickings.

    Sure gamle SIC publisert SIC 32, men analogizing fra en tolkning håndtere nettsted kostnader til programvare generelt er en ganske langt strekk (hvis det er lov i det hele tatt).

    Hmmm, kanskje jeg skulle prøve å skrive IASB / IFRIC et brev? Kanskje de vil selv skrive tilbake. Eller enda bedre, kanskje de vil legge til en internt utviklet software prosjekt til sin dagsorden. Ville ikke det være kjekk.

    Jada, hvis alt jeg hadde å forholde seg til var studenter, ville slike råd være tilstrekkelig. Hvis jeg ga slike råd til en betalende kunde, ville han ønsker pengene sine tilbake (hvis han ikke saksøke meg for prosesjonskorset inkompetanse det er).

    Selv om jeg også (tid o tid) avtale med studentene, mine reelle kunder trenger for å løse reelle problemer. Og i den virkelige verden, det blir rotete. Og når ting får rotete, ha mer enn tre ord kommer godt med.

    Riktignok har ingen plikt til å vite US GAAP for å anvende IFRS (eller vice versa). Men det skader ikke (spesielt siden IASB og FASB jobber borte så hardt på konvergens deres).

    Når det veiledning svarer også til min egen faglig skjønn. Hei, jeg kaller det regnskapsmessig nirvana i min bok.

    Og kniven skjærer begge veier.

    Mine klienter inkluderer US GAAP selskaper (primærnotert i USA), EU-IFRS selskaper (med IFRS på grunn av EC 1606/2002) og IASB-IFRS selskaper (hovedsakelig utenlandske private utstedere med en sekundær lytting i USA som benytter seg av SECs slappet IFRS).

    De finner at når det gjelder å håndtere spesielle revisorer eller regulatorer (overraskelse), disse har en tendens til å la seg påvirke av sine hjem standarder.

    Og så er det prosaiske grunner.

    Hvis for eksempel ønsker et amerikansk selskap med betydelig virksomhet i EU for å bemanne sin økonomiavdeling med europeiske statsborgere (snarere enn kostbar US ex-pats), det bedre har litt IFRS kunnskap. Og hvis den ikke har det, det bedre å få det (ellers er det ganske mye skrudd).

    Men, digress jeg.

    Oh well.

    Jeg antar det er fordi det regner ute og jeg sitter fast her med noe bedre å gjøre enn å høre på meg selv snakke (err, ... write).

  • patriciawalters sa:

    Mladek:

    Dine svar er akkurat det som gjør besvare spørsmål på denne listen verdt. Jeg skulle ønske flere utspørrerne ville bli involvert i en diskusjon eller debatt på sakene, spesielt de hvor det er forskjeller i synspunkter.

    IASB åpnet døren for å bruke uttalelser fra andre likesinnede standard-settere i IAS 8 med hensyn til hierarkiet. Mitt poeng er ikke å gå dit først. Tross alt, er noen mennesker kommer til denne listen for råd og vi er ikke myndig, på noen måte.

    Hvis du liker å diskutere regnskapsmessige spørsmål, bør du bli med AECM Listserv på aecm@listserv.loyola.edu~~HEAD=NNS Masse energisk diskusjon der.

    Så vennligst ikke ta mine kommentarer personlig. Jeg elsker en aggressiv debatt, selv når jeg soundly trounced. Jeg håper å gjerde med deg igjen på en annen sak, og kanskje vi enige.

    Og gjør jeg mer enn bare lære ....

    Patricia Walters

  • Mladek sa:

    Jeg gjorde det ikke.

    Og jeg elsker en god debatt for (spesielt på en regntung lørdag ettermiddag).

    Ser deg neste gang.

    Robert

    PS, om jeg kunne lage en levende bare undervisning, ville jeg ikke gjøre noe, men.

  • Sarun sa:

    I tillegg til fremtidig økonomisk verdi betraktning, har de totale kostnadene ved å lage dem programvare for å bli dømt. Hvis det ikke er vesentlig, tror jeg at kapitalisering vil ikke legge verdi for deg.

Legg igjen din respons!

Du må være innlogget for å skrive en kommentar.