Accueil » IAS 38

Capitalisation des logiciels développés en interne

12 août 2010 10,157 vues 11 Commentaires

Ma société développe des logiciels pour usage interne (bien qu'il puisse également être vendus à d'autres entreprises similaires). Il remplace presque toujours le logiciel que nous avons acheté à une date antérieure, de sorte qu'il génère des avantages économiques visibles en réduisant les coûts. Pouvons-nous tirer de notre logiciel développé en interne?

Related Posts

  1. Emprunt obligataire liée coût
  2. Révision du fichier logiciel utile
  3. Changement dans la vie de l'ordinateur le logiciel IAS 16, IAS 8
  4. La capitalisation des logiciels / charges à
  5. Comptabilité analytique et de logiciels
  6. Date de production comercial
  7. Software Revenue Recognition selon les IFRS et SOP 97 -
  8. Logiciel de vérification
  9. Logiciel de vérification interne
  10. La capitalisation des logiciels
1 Star2 Stars3 Stars4 Stars5 Stars (Pas de votes)
Loading ... Chargement en cours ...

11 commentaires »

  • ifrslist
    ifrslist dit:

    [Post New] Capitalisation des logiciels développés en interne - http://www.ifrslist.com/2010/08/capitali .. .
    via Twitoaster

  • Mládek dit:

    Malheureusement, contrairement aux PCGR américains ( ASC 350-40 ). Les normes IFRS ne traitent pas spécifiquement avec le logiciel. IAS 38 ne, cependant, faire face à des actifs incorporels générés en interne (qui comprennent les logiciels).

    IAS 38 indique 6 critères qui doivent être remplies si les coûts de développement doivent être capitalisés. Parmi ceux-ci, ce qui démontre (IAS 38.57.d) «comment l'immobilisation incorporelle générera des avantages économiques futurs probables ...» est la plus onéreuse.

    À mon avis, si l'entité envisage d'utiliser l'actif à l'intérieur, il n'aurait aucun problème à démontrer "l'utilité de l'actif incorporel", de sorte qu'il pourrait capitaliser.

    Malheureusement, ce n'est pas la seule vue. Par exemple Epstein pense qu'il n'est pas possible de démontrer comment la SW va générer des avantages économiques et que (même si les IFRS reconnaît à la fois les actifs incorporels séparables juridiques et) l'absence d'une licence achetée empêche la capitalisation.

    Personnellement, je pense Barry est un idiot, mais, mais cela ne change rien au fait que ses options ne portent beaucoup de poids (beaucoup plus que la mienne).

    Heureusement, ils ne sont pas définitifs.

    IAS 8.12 Etats »dans le jugement décrit au paragraphe 10, la direction peut également considérer les positions les plus récentes d'autres organismes de normalisation qui utilisent un cadre conceptuel similaire pour élaborer des normes comptables, ..." ce qui signifie que (depuis IFRS ne traite pas explicitement avec la question), il est acceptable de considérer la pertinence des PCGR américains.

    Que les PCGR américains (ASC 350-40-25) est très explicite: «Les coûts -1 internes et externes engagés durant la phase préliminaire du projet doit être passés en charges dès qu'ils sont engagés. -2 Coûts internes et externes engagés pour développer des logiciels à usage interne au cours de la phase de développement d'application doivent être capitalisés. Coûts -3 à développer ou obtenir un logiciel qui permet l'accès à ou la conversion de données anciennes par de nouveaux systèmes doivent également être capitalisés. Les coûts de formation ne sont pas -4 à usage interne des coûts de développement de logiciels et, si elles sont engagées au cours de cette étape, doit être passés en charges lorsqu'ils sont engagés. 5Les données des coûts de conversion, sauf comme indiqué au paragraphe 350-40-25-3, doit être passés en charges lorsqu'ils sont engagés. -6 Coûts de formation internes et externes et les coûts d'entretien pendant la phase de postimplementation-opération doit être passés en charges lorsqu'ils sont engagés. "

    Donc, autant que je suis concerné, les coûts de développé en interne SW sont adaptés à la capitalisation en normes IFRS et, si je ne courir dans la résistance, je ne peux toujours se rabattre sur les US GAAP.

    Cependant, je dois également souligner une plus petite chose.

    US GAAP (350-40-35) affirme également: "-7 Si, après le développement de logiciels à usage interne est terminée, une entité décide de commercialiser le logiciel, produit de la licence du logiciel d'ordinateur ... doivent être appliquées contre les la valeur comptable de ce logiciel. -8 Aucun bénéfice n'est reconnue que produit net global de licences et d'amortissement ont réduit la valeur comptable du logiciel à zéro. ... "

    Ainsi, si l'on utilise-t-US GAAP pour justifier jugement oen comme par les normes IFRS, et son entreprise ne décide de vendre le logiciel, il ne sera pas en mesure d'enregistrer les recettes éventuelles que l'actif est entièrement capitalisé décomptabilisé.

    Cela rend les normes US GAAP une épée à deux tranchants. D'une part, il fait justifiant l'arrêt de capitaliser facilement, de l'autre, il s'oppose à la reconnaissance d'un grand nombre de recettes. Mais c'est juste la façon dont il va.

  • patriciawalters dit:

    Je conviens que la norme IAS 38 vous permet de capitaliser les coûts de développement aussi longtemps que les critères sont remplis. Selon le paragraphe 57 d'IAS 28, vous devez être en mesure de démontrer toute la suite avant de pouvoir commencer la capitalisation des frais:

    (1) la faisabilité technique d'achever l'actif incorporel pour qu'il sera disponible pour utilisation ou vente
    (2) son intention d'achever l'immobilisation incorporelle et utiliser ou le vendre.
    (3) sa capacité à utiliser ou vendre l'immobilisation incorporelle
    (4) la façon dont l'immobilisation incorporelle générera des avantages économiques futurs probables. Entre autres choses, l'entité peut démontrer l'existence d'un marché pour la sortie de l'immobilisation incorporelle ou pour l'immobilisation incorporelle elle-même ou, si elle doit être utilisée en interne, l'utilité de l'actif incorporel.

    Alors, bien sûr, que cela vous permette de capitaliser une partie des coûts associés au développement de logiciels à usage interne. Vous ne serez pas en mesure de capitaliser les frais que vous avez passés en charges avant de rencontrer ces critères. Vous ne serez pas en capitalisant l'ensemble de vos dépenses.

    Astra Zeneca est une société qui divulgue "coûts de développement de logiciels" en tant que classe d'actifs distincte dans la note 9, actifs incorporels ».

    J'ai vu d'autres aussi.

    Hope this helps.

    Patricia Walters

  • patriciawalters dit:

    Je voulais ajouter.

    Il n'ya aucune raison d'aller à des États-Unis exigences des PCGR du ou des contraintes.

    Les normes IFRS ne traitent avec une capitalisation des coûts de développement pour les actifs incorporels à être utilisés en interne. Le fait que la norme ne disent: "Oh, soit dit en passant, le logiciel est un bien immatériel que vous pouvez développer en interne", n'est pas pertinente.

    Le logiciel est un bien immatériel qui peut être (et est souvent) mis au point en interne et la décision de capitalisation est couverte par la norme IAS 38.

    US GAAP n'est pas pertinent. À mon avis, il serait inapproprié de se tourner vers les PCGR américains pour l'orientation, car la norme IAS 38 explique clairement ce que les critères de capitalisation sont.

    Patricia Walters

  • patriciawalters dit:

    "Ne dis" devrait être "ne dit pas" dans mon post précédent. Désolé.
    Patricia

  • Mládek dit:

    Je suis d'accord (comme je l'ai dit dans mon premier post) que la norme IAS 38 ne s'oppose pas développés à l'interne en capitalisant SW, l'application du paragraphe 57 (dans la pratique) est tout sauf claire et simple.

    Si c'était le cas, largement lu les publications (telles que l'interprétation et l'application de WILEY International Financial Reporting ... Par Barry J. Epstein, Eva K. Jermakowicz) ne serait pas venu à la conclusion opposée.

    Si c'était le cas, les vérificateurs signer sur les entreprises en capitalisant tout, y compris l'évier de la cuisine.

    Si c'était le cas, je n'aurais pas pris la peine citant les normes US GAAP.

    En tout état de cause, je ne dis pas qu'il est impossible de convaincre un auditeur sceptique que l'on a rempli tous les critères énoncés au paragraphe 57. Qu'est-ce que je dis, c'est qu'il ne peut pas être un slam-dunk.

    Cela est particulièrement le cas en Europe continentale, où l'on ne rencontrez auditeurs que, bien que d'experts dans l'application de leurs propres normes comptables nationales ", ont peu d'expérience de première main l'interprétation et l'application des normes IFRS (ou systèmes, tels que les PCGR américains ou UK GAAP, mis au point par les organismes de normalisation à l'aide des cadres conceptuels similaires).

    Quant à US GAAP étant sans pertinence, il serait, si les IFRS n'a pas explicitement le contraire.

    IAS 8.12: «En rendant le jugement décrit au paragraphe 10, la direction peut également considérer les positions les plus récentes d'autres organismes de normalisation qui utilisent un cadre conceptuel similaire pour élaborer des normes comptables, la littérature comptable et les pratiques reconnues de l'industrie, dans la mesure où ceux-ci n'entrent pas en conflit avec les sources dans le paragraphe 11 ",

    Le paragraphe 10 stipule «En l'absence d'une IFRS qui s'applique spécifiquement à une transaction, un autre événement ou condition, la direction doit utiliser son jugement pour développer et appliquer une méthode comptable ...».

    Maintenant, corrigez-moi si je me trompe, mais je n'ai jamais remarqué une IFRS qui (comme l'ASC 350-40) s'applique spécifiquement à logiciels à usage interne.

    Cela implique que, si quelqu'un à la question que mon jugement logiciels à usage interne est capitalisable, en plus de la norme IAS 38.57, je pourrais aussi pointer vers un standard (fixé par un organisme de normalisation qui utilisent un cadre conceptuel similaire pour élaborer des normes comptables ) qui indique que mon jugement est conforme aux PCGR.

    En outre, comme un avantage supplémentaire, les normes US GAAP fournit explicites, claires et faciles à suivre les instructions sur la façon de mettre en place une procédure comptable pour accomplir cette tâche.

    Les seules raisons que je peux voir pourquoi quelqu'un ne voudrait pas se prévaloir d'une telle opportunité:

    1. on n'est pas conscient du fait que les normes US GAAP existe

    2. on n'est pas conscient de son contenu

    3. on ne se rend pas compte qu'il peut être utilisé pour compléter les normes IFRS (en particulier dans les situations où l'orientation parfois vague, abstraite et théorique de la norme IFRS est difficile à traduire en jour le jour la pratique).

  • patriciawalters dit:

    Je n'ai jamais dit de prendre ces décisions a été facile. A peine toute décision de l'information financière ces jours-ci est facile. Comme je l'ai dis à mes étudiants, si ces décisions étaient faciles et il y avait toujours une réponse claire, ils ne seraient pas chercher à faire les "grands mâles" sur l'obtention du diplôme.

    Cependant, la philosophie derrière l'approche IFRS "principes de l'information financière est que la norme ne fournit pas une liste de chaque élément spécifique à cette norme s'applique ou ne s'applique pas aux.

    Le logiciel est un actif incorporel. Par conséquent, la norme IAS 38 s'applique.
    IAS 38 couvre actifs incorporels développés à l'interne pour leur propre usage. Par conséquent, les coûts de développement associés aux logiciels développés en interne peuvent être capitalisées selon la norme IAS 38, si les critères de capitalisation sont remplies.

    Certaines entreprises ne peuvent pas besoin de regarder à l'orientation au-delà de ce qui est disponible dans la norme IAS 38 pour déterminer si ces critères sont remplis et il n'est pas nécessaire de le faire.

    En fait, il ya un danger au immédiatement sauter aux orientations fournies par d'autres normalisateurs (US GAAP) ou en voie de développement une habitude de le faire. Une telle orientation n'est pas toujours compatible avec les IFRS ou de son cadre conceptuel et les préparateurs doivent être vigilants en utilisant les directives très détaillées fournies par les PCGR américains qu'il produira des résultats conformément aux normes IFRS.

    Enfin, actuellement disponibles des documents écrits tels que le livre que vous citez ne sont pas des conseils faisant autorité sur les normes IFRS ou US GAAP. Quelque chose d'écrit dans ce livre, peu importe la façon dont le bien-respecté les auteurs, est purement leur avis pris en considération. Ce sont des hommes (et femmes), non des dieux ou de l'IASB ou l'IFRIC. Par conséquent, je me sens libre d'être en désaccord avec les auteurs de ces livres. Et, le font souvent. Tout comme nous sommes en désaccord ici.

    Si vous croyez que des directives supplémentaires sont nécessaires concernant la manière de juger si un critère particulier dans les IFRS est insuffisante et doit être clarifiée, l'endroit où aller pour que des directives supplémentaires est soit l'interprétation IFRIC ou l'IASB. Non US GAAP.

    Sinon, vous êtes essentiellement dire aux gens d'apprendre un minimum de deux ensembles de normes comptables, plutôt que celui qu'ils sont censés appliquer. Quel est le point de cette recommandation?

    Patricia Walters

  • Mládek dit:

    Je suis d'accord avec vous.

    Principes sur la base des moyens étant permis d'atteindre son propre jugement professionnel. Mais ce jugement ne vit pas dans un vide. Jugement doit être justifiée (à ses supérieurs, ses auditeurs, peut-être du régulateur et, si le pire arrive au pire, à la cour).

    En ce qui concerne les personnes ayant «d'apprendre un minimum de deux ensembles de normes comptables, plutôt que celui qu'ils sont censés appliquer."

    À quel moment exactement moins de connaissances deviennent supérieurs à plus de connaissances?

    En outre, je ne recommande pas rien. Il s'agit d'une discussion ouverte. Je ne suis pas payé pour mes services. Je un pas demandé à prendre la responsabilité de mon jugement. Les gens peuvent lire ce que j'ai écrit, utiliser les informations fournies, ou non. Je ne pouvais vraiment pas s'occuper moins de quel côté ils décident.

    Je veux simplement faire remarquer que, tandis que les IFRS ne traite pas clairement le sujet à portée de main, les normes US GAAP ne.

    Je suis également remarquer que, tandis que les entreprises IFRS ne sont pas obligés de suivre cette orientation, il n'est pas (depuis IFRS ne fournissent pas de directives contradictoires) rejetée.

    Oh, BTW, ce n'était pas moi qui a ouvert la porte soit les PCGR américains ou non-autorisée la littérature. L'IASB a réussi à le faire par lui-même en déclarant: «En rendant le jugement décrit au paragraphe 10, la direction peut également considérer ... la littérature comptable et les pratiques reconnues de l'industrie, dans la mesure où ceux-ci n'entrent pas en conflit ...".

    Cela signifie également, autoritaire ou non, une telle littérature a une influence sur la pratique. Il suffit de vouloir n'en était pas ainsi, ne fera pas pas le cas.

    En ce qui concerne les conseils du genre: «Si vous croyez que des directives supplémentaires sont nécessaires concernant la manière de juger si un critère particulier dans les IFRS est insuffisante et doit être clarifiée, l'endroit où aller pour que des directives supplémentaires est soit l'interprétation IFRIC ou l'IASB".

    Ce conseil est sur place, mais (bien évidemment) pertinente que dans les situations où l'IASB ou l'IFRIC a décidé de fournir de telles orientations.

    Pour autant que je sais, la seule "autorité" indications fournies sur le sujet à la main sont ces trois mots (en gras): «IAS 38.62 Une entité systèmes coûtant permettent souvent d'évaluer de façon fiable le coût pour générer une immobilisation incorporelle en interne, comme le salaire et les autres dépenses entraînées par la mise droits d'auteur ou des licences ou pour développer des logiciels. "

    Cueillettes Jolie rares.

    Bien sûr, le SIC vieux livre publié SIC 32, mais une analogie d'une interprétation relative aux dépens de sites Web de logiciels en général est un tronçon assez loin (si elle est autorisée à tous).

    Hmmm, peut-être je devrais essayer d'écrire l'IASB / IFRIC une lettre? Peut-être ils vont même écrire de nouveau. Ou, mieux encore, peut-être ils vont ajouter un projet de logiciel développé en interne à leur ordre du jour. N'était-ce pas chouette.

    Bien sûr, si tout ce que j'avais à traiter étaient des étudiants, de tels conseils serait suffisante. Si je donnais des conseils à un client par exemple de payer, il voudrait récupérer son argent (si il ne m'a pas intenter des poursuites pour incompétence procession qui est).

    Bien que j'ai aussi (le temps o temps) beaucoup avec les étudiants, mes clients du monde réel besoin pour résoudre les problèmes du monde réel. Et, dans le monde réel, les choses se salir. Et quand les choses ne se salir, ayant plus de trois mots est très pratique.

    Certes, personne n'a l'obligation de connaître les normes US GAAP afin d'appliquer les normes IFRS (ou vice versa). Mais il ne fait pas mal (surtout depuis l'IASB et le FASB travaillent loin avec tant de diligence à leur convergence).

    Lorsque que l'orientation correspond aussi à mon propre jugement professionnel. Hey, C'est ce que j'appelle le nirvana de comptabilité dans mon livre.

    Et le couteau à double tranchant.

    Mes clients sont des compagnies américaines GAAP (cotation primaire aux États-Unis), EU-IFRS des sociétés (en utilisant les normes IFRS en raison de CE 1606/2002) et l'IASB-IFRS des sociétés (la plupart du temps les émetteurs privés étrangers avec une écoute secondaire aux États-Unis profitent de la de la SEC détendu exigences des IFRS).

    Ils constatent que quand il s'agit de traiter avec les auditeurs particuliers ou les organismes de réglementation (surprise, surprise), ceux-ci ont tendance à se laisser influencer par leurs normes à domicile.

    Et puis il ya les raisons prosaïques.

    Si, par exemple, une société américaine avec des opérations importantes dans l'UE veut doter son département de la comptabilité avec les ressortissants européens (plutôt que cher aux États-Unis d'expatriés), il vaut mieux avoir une certaine connaissance des IFRS. Et si elle ne l'a pas, il vaut mieux l'avoir (sinon, c'est à peu près vissé).

    Mais, je m'éloigne.

    Eh bien.

    Je suppose que c'est parce que sa pleut dehors et je suis coincé ici avec rien de mieux à faire que d'écouter me parler (euh, ... écriture).

  • patriciawalters dit:

    Mládek:

    Vos réponses sont exactement ce que font répondre à des questions sur cette liste vaut la peine. Je souhaite que plus questionneurs seraient de s'impliquer dans une discussion ou un débat sur les questions, en particulier celles où il ya des divergences de vues.

    L'IASB a ouvert la porte à l'aide des déclarations d'autres vues similaires normalisateurs de la norme IAS 8 par rapport à la hiérarchie. Mon but n'est pas d'y aller en premier. Après tout, certaines personnes sont à venir à cette liste pour obtenir des conseils et nous ne sommes pas d'autorité, par tout moyen.

    Si vous aimez débattre des questions de comptabilité, vous devriez vous joindre à la liste de diffusion AECM aecm@listserv.loyola.edu~~HEAD=NNS Beaucoup de discussion vigoureuse-t-il.

    Alors, s'il vous plaît ne prenez pas mes commentaires personnellement. J'aime un débat agressif, même quand je suis profondément battu à plate couture. J'espère clôture de nouveau avec vous sur une autre question et peut-être nous serons d'accord.

    Et, je fais plus que simplement apprendre ....

    Patricia Walters

  • Mládek dit:

    Je n'ai pas.

    Et j'aime un bon débat trop (surtout sur un après-midi pluvieux samedi).

    Rendez-vous la prochaine fois.

    Robert

    PS, si je pouvais faire un enseignement vivant seule, je ne ferais rien, mais.

  • Sarun a déclaré:

    En plus de l'examen valeur économique future, le coût total de la création ces logiciels doit être jugé. Si elle n'est pas matérielle, je crois que la capitalisation ne sera pas ajouter de la valeur pour vous.

Laissez votre réponse!

Vous devez être connecté pour poster un commentaire.