Pagina iniziale » IAS 38

Capitalizzazione di software sviluppato internamente

12 agosto 2010 10.102 visualizzazioni 11 Commenti

La mia azienda sviluppa software per uso interno (anche se potrebbe anche essere venduti ad altre società simili). E 'quasi sempre sostituisce il software abbiamo acquistato al momento della prima, così si genera evidenti benefici economici, riducendo i costi. Possiamo sfruttare il nostro software sviluppato internamente?

Related Posts

  1. Prestito obbligazionario relativo costo
  2. Revisione del file Software utili
  3. Modifica della durata di computer software IAS 16, IAS 8
  4. Capitalizzazione Software / spesati out
  5. Contabilità dei costi e Software
  6. Data di produzione comercial
  7. Software rilevazione dei ricavi in base agli IFRS e SOP 97 -
  8. Audit software
  9. Revisione del software interno
  10. Software capitalizzazione
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Caricamento in corso ...

11 commenti »

  • ifrslist
    ifrslist ha detto:

    [Nuovo messaggio] Capitalizzazione di software sviluppato internamente - .. http://www.ifrslist.com/2010/08/capitali .
    via Twitoaster

  • Mladek ha detto:

    Purtroppo, a differenza US GAAP ( ASC 350-40 ). IFRS non affronta concretamente con il software. IAS 38, tuttavia, che fare con attività immateriali generate internamente (che comprendono software).

    IAS 38 delinea 6 criteri che devono essere soddisfatti se i costi di sviluppo devono essere capitalizzati. Di questi, dimostrando (IAS 38.57.d) "come l'attività immateriale genererà probabili benefici economici futuri ..." è il più oneroso.

    A mio parere, se l'entità prevede di utilizzare il bene internamente, non avrebbe alcun problema dimostrando "l'utilità del bene immateriale", in modo che potesse capitalizzare.

    Sfortunatamente, questo non è l'unica visualizzazione. Per esempio Epstein pensa che non è possibile dimostrare come la SW produrrà benefici economici e che (anche se IFRS riconosce entrambi i beni giuridici immateriali e separabile) l'assenza di una licenza acquistata preclude capitalizzazione.

    Personalmente penso che Barry è un idiota, ma, ma questo non cambia il fatto che le sue opzioni siano portatori di un sacco di peso (molto più del mio).

    Fortunatamente, non sono definitive.

    IAS 8.12 stabilisce "Nell'esprimere un giudizio descritto nel paragrafo 10, la direzione può anche prendere in considerazione i pronunciamenti più recenti di altri organismi di normazione che utilizzano un quadro sistematico concettualmente simile per sviluppare gli standard contabili, ..." il che significa che (dato IFRS non si occupa espressamente con il problema) è accettabile considerare la pertinente US GAAP.

    Questo US GAAP (ASC 350-40-25) è molto esplicito: "I costi -1 interni ed esterni sostenuti durante la fase di progetto preliminare deve essere spesati quando sono sostenuti. -2 Costi interni ed esterni sostenuti per lo sviluppo software per uso interno del computer durante la fase di sviluppo di applicazioni devono essere capitalizzati. I costi da -3 a sviluppare o ottenere un software che consente l'accesso o la conversione di vecchi dati da parte di nuovi sistemi sono inoltre essere capitalizzati. I costi di formazione -4 non sono uso interno i costi di sviluppo software e, se sostenuti in questa fase, devono essere spesati quando sostenuti. 5Data i costi di conversione, ad eccezione di quanto indicato nel paragrafo 350-40-25-3, devono essere spesati quando sostenuti. -6 Costi di formazione interni ed esterni e costi di manutenzione durante il postimplementation-operation fase devono essere spesati quando sostenuti. "

    Quindi, per quanto mi riguarda, le spese di SW sviluppato internamente sono adatti per la capitalizzazione secondo gli IFRS e, se si esegue in resistenza, posso sempre ripiegare su US GAAP.

    Tuttavia, ho anche far notare una cosa più piccola.

    US GAAP (350-40-35) afferma inoltre: "-7 Se, dopo lo sviluppo di software per uso interno è completato, l'entità decide di commercializzare il software, gli utili percepiti dalla licenza del software di computer ... si applichino alle il valore contabile di tale software. -8 No profit deve essere riconosciuto fino aggregati proventi netti da licenze e gli ammortamenti hanno ridotto il valore contabile del software a zero. ... "

    Quindi, se si fa uso US GAAP per giustificare il giudizio OEN come per IFRS, e una compagnia decide di vendere il software, non sarà in grado di registrare le eventuali entrate fino a quando l'attività è completamente in maiuscolo cancellate.

    Questo rende gli US GAAP un'arma a doppio taglio. Da un lato, rende giustificare il giudizio di capitalizzare facile, dall'altro, esso osta a riconoscere un sacco di entrate. Ma è proprio così che va.

  • patriciawalters ha detto:

    Sono d'accordo che lo IAS 38 permette di capitalizzare i costi di sviluppo fino a quando i criteri sono soddisfatti. Secondo il punto 57 dello IAS 28, si deve essere in grado di dimostrare ALL di seguire prima di iniziare a capitalizzare i costi:

    (1) la fattibilità tecnica di completare l'attività immateriale in modo che sia disponibile per l'uso o la vendita
    (2) la sua intenzione di completare l'attività immateriale e usarla o venderla.
    (3) la sua capacità di usare o vendere l'attività immateriale
    (4) come l'attività immateriale genererà probabili benefici economici futuri. Tra le altre cose, l'entità può dimostrare l'esistenza di un mercato per l'uscita del immateriale o per l'attività immateriale stessa o, se è per uso interno, l'utilità del bene immateriale.

    Quindi, certamente, questo permette di capitalizzare alcuni dei costi associati allo sviluppo di software per uso interno. Non sarà in grado di capitalizzare tutti i costi hai spesati prima di aver soddisfatto questi criteri. Non sarà capitalizzando tutte le spese.

    Astra Zeneca è una società che svela "i costi di sviluppo software", come una classe di attività a sé stante nella nota 9, attività immateriali ".

    Ho visto anche altri.

    Spero che questo aiuti.

    Patricia Walters

  • patriciawalters ha detto:

    Volevo aggiungere.

    Non c'è motivo di andare a US GAAP esigenze o vincoli.

    IFRS si occupa di capitalizzazione dei costi di sviluppo per le attività immateriali da utilizzare internamente. Il fatto che la norma fa dire: "Oh, a proposito, il software è un bene intangibile che si può sviluppare internamente", non è rilevante.

    Il software è un bene intangibile che può essere (ed è spesso) sviluppato internamente e la decisione di capitalizzazione è coperto dallo IAS 38.

    US GAAP è irrilevante. A mio avviso, sarebbe opportuno guardare a US GAAP per la guida, perché IAS 38 spiega chiaramente quali sono i criteri per la capitalizzazione sono.

    Patricia Walters

  • patriciawalters ha detto:

    "Dice" dovrebbe essere "non dice" nel mio post precedente. Mi dispiace.
    Patricia

  • Mladek ha detto:

    Pur essendo d'accordo (come ho affermato nel mio primo post) che lo IAS 38 non osta capitalizzando sviluppato internamente SW, applicazione del paragrafo 57 (in pratica) è tutt'altro che chiara e semplice.

    Se così fosse, molto letto le pubblicazioni (come ad esempio WILEY Interpretazione e applicazione degli International Financial Reporting ... By Barry J. Epstein, Eva K. Jermakowicz) non sarebbe giunto alla conclusione opposta.

    Se così fosse, avrebbe firmato revisori delle società off capitalizzando tutto, compreso il lavello della cucina.

    Se così fosse, non avrei preso la briga citando gli US GAAP.

    In ogni caso, non sto dicendo che è impossibile convincere un revisore dei conti uno scettico che soddisfano tutti i criteri di cui al punto 57. Quello che sto dicendo è che non può essere una slam-dunk.

    Questo vale in particolare in Europa continentale, dove viene eseguito in uno revisori dei conti che, pur esperto nell'applicazione delle loro proprie "GAAP nazionali", hanno poca esperienza di prima mano l'interpretazione e l'applicazione degli IFRS (o sistemi, quali US GAAP e UK GAAP, sviluppato da organismi di normazione che utilizzano simili strutture concettuali).

    Come a US GAAP, è irrilevante, sarebbe, se IFRS non ha esplicitamente il contrario.

    IAS 8.12: "Nell'esprimere un giudizio descritto nel paragrafo 10, la direzione può anche prendere in considerazione i pronunciamenti più recenti di altri organismi di normazione che utilizzano un quadro sistematico concettualmente simile per sviluppare gli standard contabili, altra letteratura contabile e prassi consolidate nel settore, nella misura in cui questi non sono in contrasto con le fonti di cui al paragrafo 11 ",

    Il paragrafo 10 stabilisce "In assenza di un IFRS che si applichi specificatamente a una operazione, altro evento o circostanza, la gestione deve usare il proprio giudizio nello sviluppare e applicare un principio contabile ...".

    Ora, correggimi se sbaglio, ma non ho mai notato un IFRS che (come ASC 350-40) vale in particolare per uso interno Software.

    Ciò implica che, se qualcuno dovesse mettere in discussione il mio giudizio che per uso interno Software è capitalizzabile, in aggiunta a IAS 38.57, potrei anche puntare a uno standard (impostato da una definizione di standard che utilizzano un quadro sistematico concettualmente simile per sviluppare i principi contabili ) che afferma che il mio giudizio è GAAP.

    Inoltre, come ulteriore vantaggio, US GAAP fornisce esplicito, chiaro e facile da seguire le istruzioni su come impostare una procedura contabile per eseguire questa operazione.

    Le uniche ragioni che posso vedere perché qualcuno non vorrebbe avvalersi di tale opportunità:

    1. uno non è consapevole del fatto che US GAAP esiste

    2. non è a conoscenza del suo contenuto

    3. non si rende conto che può essere utilizzato per integrare IFRS (in particolare nelle situazioni in cui la guida a volte vago, astratto e teorico IFRS è difficile da tradurre in giorno per giorno la pratica).

  • patriciawalters ha detto:

    Non ho mai detto queste decisioni è stato facile. Quasi ogni decisione finanziaria in questi giorni è facile. Come dico ai miei studenti, se queste decisioni erano facili e c'era sempre una risposta chiara, non dovrebbe cercare di fare il "bucks grandi" al momento della laurea.

    Tuttavia, la filosofia che sta dietro l'approccio principi IFRS 'di informativa finanziaria è che lo standard non fornisce una lista di ogni elemento specifico che la norma si applica o non si applica a.

    Il software è un bene immateriale. Quindi, lo IAS 38 si applica.
    IAS 38 riguarda beni immateriali sviluppate internamente per uso personale. Di conseguenza, i costi di sviluppo legate al software sviluppato internamente possono essere capitalizzati in base allo IAS 38 se i criteri per la capitalizzazione sono soddisfatte.

    Alcune aziende non può avere bisogno di guardare al di là di quanto la guida è disponibile in IAS 38 per determinare se tali criteri sono soddisfatti e non vi è alcun obbligo di farlo.

    In realtà, vi è un pericolo in saltare immediatamente alle linee guida fornite da altri organismi di normazione (US GAAP) o in via di sviluppo l'abitudine di farlo. Tale guida non è sempre conforme agli IFRS o il suo quadro concettuale e redattori devono essere vigili in usando la guida molto dettagliata fornita dalla US GAAP che produrrà risultati in base agli IFRS.

    Infine, i materiali scritti attualmente disponibili, come il libro che citi non sono una guida autorevole su entrambi IFRS o US GAAP. Tutto scritto in quel libro, non importa quanto bene rispettato gli autori, è puramente il loro parere. Sono uomini (e donne), non dèi o dello IASB o dell'IFRIC. Quindi, mi sento libero di essere in disaccordo con gli autori di questi libri. E, spesso lo fanno. Proprio come ci sono in disaccordo qui.

    Se credi che una guida aggiuntiva è necessaria per la procedura di giudicare se un determinato criterio degli IFRS è insufficiente e deve essere chiarito, il posto dove andare per questo ulteriori indicazioni o è o IFRIC dello IASB. Non US GAAP.

    In caso contrario, si sta praticamente dicendo alle persone di imparare un minimo di due set di principi contabili, piuttosto che uno ci si aspetta che da applicare. Qual è il punto di tale raccomandazione?

    Patricia Walters

  • Mladek ha detto:

    Sono d'accordo con te.

    Principi di base significa essere permesso di raggiungere il proprio giudizio professionale. Ma tale sentenza non vive nel vuoto. Giudizio deve essere motivata (ai propri superiori, i propri revisori dei conti, forse proprio regolatore e, se di male in peggio, a corte).

    Per quanto riguarda le persone che hanno a "imparare un minimo di due set di principi contabili, piuttosto che uno ci si aspetta che l'applicazione".

    A che punto esattamente meno conoscenza diventano superiori a più conoscenza?

    Inoltre, io non sto raccomandando nulla. Si tratta di una discussione aperta. Io non mi viene pagato per i miei servizi. Non uno viene chiesto di assumersi la responsabilità per il mio giudizio. La gente può leggere quello che ho scritto, utilizzare le informazioni fornite, oppure no. Io davvero non potrebbe importare di meno che modo decidono.

    Sto semplicemente sottolineando che, pur IFRS non affrontare l'argomento in modo chiaro a portata di mano, US GAAP fa.

    Sono inoltre notare che, mentre le aziende IFRS non sono obbligati a seguire questa guida, non è (IFRS in quanto non fornisce indicazioni in conflitto) non consentito.

    Oh, BTW, non sono stato io ad aprire la porta a uno US GAAP e non-autorevole letteratura. Lo IASB è riuscito a fare tutto da solo, affermando "Nell'esprimere un giudizio descritto nel paragrafo 10, la direzione può anche considerare ... la letteratura di contabilità e prassi consolidate nel settore, nella misura in cui questi non siano in conflitto ...".

    Questo significa anche, autorevole o meno, tale letteratura ha un influenza sulla pratica. Basta volerlo non fosse così, non farà non è così.

    Per quanto riguarda consigli come: "Se credi che una guida aggiuntiva è necessaria per la procedura di giudicare se un determinato criterio degli IFRS è insufficiente e deve essere chiarito, il posto dove andare per questo ulteriori indicazioni o è IFRIC o IASB".

    Questo consiglio è a posto, ma (evidentemente) pertinenti solo in quelle situazioni in cui lo IASB o dell'IFRIC ha deciso di fornire tali indicazioni.

    Per quanto ne so, l'unica guida "autorevole" fornito sul tema in questione sono queste tre parole (in grassetto): "IAS 38.62 sistemi di contabilità analitica dell'entità possono spesso determinare in modo attendibile il costo di generare internamente un'attività immateriale, come il salario e altre spese sostenute per garantirsi diritti d'autore o licenze o per sviluppare software. "

    Piuttosto scarsi guadagni.

    Certo il SIC vecchia pubblicato SIC 32, ma questa analogia da un'interpretazione che fare con i costi del sito web al software in generale è un tratto abbastanza lontano (se è consentito a tutti).

    Hmmm, forse dovrei provare a scrivere i IASB / IFRIC una lettera? Magari anche scrivere di nuovo. O, meglio ancora, forse verrà aggiunto un progetto di software sviluppato internamente alla loro agenda. Non sarebbe carino.

    Certo, se tutto quello che avevo a che fare con gli studenti erano, tale parere sarebbe sufficiente. Se ho dato tale consulenza ad un cliente pagante, che avrebbe voluto i suoi soldi indietro (se non mi causa per incompetenza processionale che è).

    Anche se ho anche (tempo o il tempo) trattano con gli studenti, i miei clienti del mondo reale bisogno di risolvere i problemi del mondo reale. E, nel mondo reale, le cose si fanno disordinato. E quando le cose si ottiene disordinato, con più di tre parole viene in aiuto.

    È vero, nessuno ha l'obbligo di conoscere US GAAP, al fine di applicare l'IFRS (o viceversa). Ma non fa male (soprattutto dopo l'IASB e FASB stanno lavorando via così diligentemente al loro convergenza).

    Quando questo orientamento corrisponde anche al mio giudizio professionale. Hey, io lo chiamo nirvana contabile nel mio libro.

    E il coltello taglia in entrambi i modi.

    I miei clienti sono imprese statunitensi GAAP (quotazione primaria negli Stati Uniti), UE-IFRS le società (in base agli IFRS a causa della CE 1606/2002) e IASB-IFRS le società (emittenti private per lo più straniere, con un ascolto secondaria negli Stati Uniti approfittando della SEC rilassati requisiti IFRS).

    Scoprono che quando si tratta di trattare con i revisori particolari o regolatori (sorpresa, sorpresa), questi tendono a lasciarsi influenzare dai loro standard di casa.

    E poi ci sono le ragioni prosaiche.

    Se, per esempio, una società statunitense con attività significative in l'UE vuole disporre di personale proprio reparto contabilità con i cittadini europei (Stati Uniti, piuttosto che costosi ex-PATS), meglio avere qualche conoscenza IFRS. E se non ce l'ha, è meglio avere (in caso contrario, è più o meno avvitata).

    Ma sto divagando.

    Oh bene.

    Credo che sia perché il suo fuori piove e mi sono bloccato qui con niente di meglio da fare che ascoltare me parlare (err, scrittura ...).

  • patriciawalters ha detto:

    Mladek:

    Le vostre risposte sono esattamente ciò che rende rispondendo alle domande in questo elenco vale la pena. Desidero che più interlocutori sarebbero coinvolti in una discussione o un dibattito sui temi, soprattutto quelli dove ci sono differenze di vedute.

    Lo IASB ha aperto la porta ad utilizzare i pronunciamenti di altri la pensano come organismi di normazione in IAS 8 rispetto alla gerarchia. Il mio punto non è quello di andarci prima. Dopo tutto, alcune persone stanno arrivando a questa lista per il consiglio e non siamo autorevole, con qualsiasi mezzo.

    Se vi piace discutere questioni contabili, è necessario aderire al listserv AECM a aecm@listserv.loyola.edu~~HEAD=NNS sacco di acceso dibattito lì.

    Quindi, per favore non prendete i miei commenti personali. Mi piace un dibattito aggressivo, anche quando sono sonoramente sconfitto. Spero di recinzione di nuovo con te su un altro problema e forse saremo d'accordo.

    E, faccio più che insegnare ....

    Patricia Walters

  • Mladek ha detto:

    Non l'ho fatto.

    E mi piace un dibattito troppo buono (soprattutto in un pomeriggio piovoso Sabato).

    Ci vediamo la prossima volta.

    Robert

    PS, se potessi fare un unico insegnamento vivente, non farei altro che.

  • Sarun ha detto:

    Oltre alla futura considerazione il valore economico, il costo totale della creazione di tali software deve essere giudicato. Se non è materiale, credo che la capitalizzazione non sarà un valore aggiunto per voi.

Lascia la tua risposta!

Devi essere loggato per lasciare un commento.