IFRS List.com: Capitalização de software desenvolvido internamente

A Comunidade sobre o IAS / IFRS, International Accounting

Amazon.com Widgets

Início » IAS 38

Capitalização de software desenvolvido internamente

12 agosto de 2010 14.131 exibições 11 Comentários

Minha empresa desenvolve software para uso interno (embora ele também poderia ser vendido para outras empresas similares). É quase sempre substitui o software que comprou na época anterior, de modo que gera visíveis benefícios econômicos, reduzindo os custos. Podemos aproveitar o nosso software desenvolvido internamente?

(Sem votos ainda)

Carregando ...

11 Comentários »

ifrslist disse:

[Post New] Capitalização de software desenvolvido internamente - http://www.ifrslist.com/2010/08/capitali .. .
via Twitoaster

# 12 Agosto 2010 às 11:19

Mladek disse:

Infelizmente, ao contrário de EUA GAAP ( ASC 350-40 ). IFRS não lida especificamente com o software. IAS 38, no entanto, lidar com ativos intangíveis gerados internamente (que incluem software).

IAS 38 define seis critérios que devem ser cumpridos, se os custos de desenvolvimento estão a ser capitalizado. Destes, demonstrando (IAS 38.57.d) "como o ativo intangível irá gerar prováveis benefícios econômicos futuros ..." é a mais onerosa.

Na minha opinião, se a entidade pretende usar o ativo internamente, ele não teria nenhum problema demonstrando "a utilidade do ativo intangível", para que ele pudesse capitalizar.

Infelizmente, isto não é a única visão. Por exemplo Epstein acha que não é possível demonstrar como o SW irá gerar benefícios econômicos e que (mesmo embora IFRS reconhece ambos os bens jurídicos e separáveis intangíveis) a ausência de uma licença adquirida impede capitalização.

Eu pessoalmente acho que Barry é um idiota, mas, mas isso não muda o fato de que suas opções se transportar uma grande quantidade de peso (muito mais do que a minha).

Felizmente, eles não são definitivos.

IAS 8,12 estados "Ao fazer o julgamento descrito no parágrafo 10, a gerência pode também considerar as mais recentes de outros órgãos normalizadores que usem uma estrutura conceptual semelhante para desenvolver normas de contabilidade, ..." o que significa que (uma vez que o IFRS não trata explicitamente com a questão), é aceitável considerar pertinente EUA GAAP.

Isso EUA GAAP (ASC 350-40-25) é bastante explícito: "Os custos -1 internos e externos incorridos durante a fase de projeto preliminar deve ser debitados em que são incorridos. -2 Custos internos e externos incorridos para desenvolver software de uso interno do computador durante a fase de desenvolvimento de aplicações, devem ser capitalizados. Custos de -3 para desenvolver ou obter o software que permite o acesso ou conversão de dados antigos por novos sistemas devem também ser capitalizados. Os custos de formação -4 não são de uso interno custos de desenvolvimento de software e, se forem efectuadas durante esta fase, devem ser contabilizados como despesas quando incorridos. -5Data custos de conversão, exceto conforme indicado no parágrafo 350-40-25-3, devem ser contabilizados como despesas quando incorridos. -6 Custos de treinamento internos e externos e custos de manutenção durante a fase de postimplementation-operação deve ser resultado quando incorridas. "

Assim, tanto quanto eu estou preocupado, custos de SW desenvolvido internamente são adequados para a capitalização em IFRS e, se eu correr em resistência, sempre posso voltar a cair EUA GAAP.

No entanto, também deve apontar mais uma coisinha.

EUA GAAP (350-40-35) também afirma: "-7 Se, após o desenvolvimento de software para uso interno é concluída, uma entidade decidir comercializar o software, os montantes recebidos da licença do software de computador ... deve ser aplicada contra o valor contábil do software. -8 Lucro Não serão reconhecidas até agregar recursos líquidos provenientes licenças e amortização ter reduzido a quantidade de carga do software para zero. ... "

Assim, se a pessoa faz uso EUA GAAP para justificar o julgamento oen como por IFRS, e uma companhia se decidir vender o software, ele não será capaz de registar as receitas até que o ativo capitalizado é totalmente baixado.

Isso faz com que EUA GAAP uma espada de dois gumes. Por um lado, faz justificar o julgamento de capitalizar fácil, por outro lado, se opõe o reconhecimento de um monte de receitas. Mas isso é apenas a maneira que vai.

# 13 Agosto 2010 às 08:36

patriciawalters disse:

Concordo que a IAS 38 permite-lhe capitalizar os custos de desenvolvimento, desde que os critérios sejam cumpridos. De acordo com o parágrafo 57 da IAS 28, você deve ser capaz de demonstrar tudo seguir, antes de começar a capitalizar custos:

(1) viabilidade técnica para concluir o ativo intangível de forma que ele estará disponível para uso ou venda
(2) a sua intenção de concluir o ativo intangível e usar ou vender.
(3) a sua capacidade de usar ou vender o ativo intangível
(4) como o ativo intangível irá gerar prováveis benefícios econômicos futuros. Entre outras coisas, a entidade pode demonstrar a existência de um mercado para a produção do activo intangível ou para o próprio activo intangível ou, se for para ser usado internamente, a utilidade do activo intangível.

Então, certamente, isso permite-lhe capitalizar alguns dos custos associados com o desenvolvimento de software de uso interno. Você não será capaz de capitalizar os custos que você imputados antes de conhecer esses critérios. Você não vai se capitalizando todos os seus gastos.

Astra Zeneca é uma empresa que divulga "custos de desenvolvimento de software" como uma classe de ativos em separado na Nota 9, Ativos Intangíveis ".

Eu vi os outros também.

Espero que isso ajude.

Patricia Walters

# 13 Agosto 2010 às 09:01

patriciawalters disse:

Eu queria adicionar.

Não há nenhuma razão para ir aos requisitos do US GAAP ou constrangimentos.

IFRS faz acordo com a capitalização de custos de desenvolvimento de ativos intangíveis a serem utilizados internamente. O fato de que o padrão faz dizer: "Ah, a propósito, o software é um bem intangível que você pode desenvolver internamente", não é relevante.

O software é um bem intangível que pode ser (e geralmente é) desenvolvido internamente ea decisão de capitalização é cobertos pela IAS 38.

EUA GAAP é irrelevante. Em minha opinião, seria inapropriado para olhar para EUA GAAP para orientação, porque IAS 38 explica claramente quais os critérios para capitalização são.

Patricia Walters

# 13 Agosto 2010 às 09:06

patriciawalters disse:

"Diz que" deve ser "não dizer" no meu post anterior. Desculpe.
Patricia

# 13 Agosto 2010 às 09:07

Mladek disse:

Embora concorde (como eu disse no meu primeiro post) que a IAS 38 não impede a capitalização SW desenvolvido internamente, aplicar o parágrafo 57 (na prática) não é nada clara e simples.

Se fosse, lido publicações (como WILEY Interpretação e Aplicação da International Financial Reporting ... Por Barry J. Epstein, Eva K. Jermakowicz) não chegar à conclusão oposta.

Se fosse, os auditores que assinar a empresas capitalizando tudo, inclusive a pia da cozinha.

Se fosse, eu não teria incomodado citando EUA GAAP.

De qualquer forma, eu não estou dizendo que é impossível convencer um cético de que um auditor cumpriu todos os critérios, conforme descrito no parágrafo 57. O que estou dizendo é que ele não pode ser um slam dunk.

Este é especialmente o caso na Europa continental, onde se corre em auditores que, enquanto especialista na aplicação dos seus próprios "GAAP nacionais", ter experiência mãozinha primeira interpretação e aplicação do IFRS (ou sistemas, como o GAAP dos EUA ou do Reino Unido GAAP, desenvolvido por organismos de normalização, utilizando estruturas conceituais semelhantes).

Quanto aos EUA GAAP sendo irrelevante, seria, se IFRS não mencionar explicitamente o contrário.

IAS 8.12: "Ao fazer o julgamento descrito no parágrafo 10, a gerência pode também considerar as mais recentes de outros órgãos normalizadores que usem uma estrutura conceptual semelhante para desenvolver normas de contabilidade, outra literatura contabilística e práticas aceites do sector, na medida em que estes não entrar em conflito com as fontes do parágrafo 11 ",

Parágrafo 10 estados "Na ausência de uma IFRS que se aplique especificamente a uma transacção, outro acontecimento ou condição, a gerência fará seu julgamento no desenvolvimento e aplicação de uma política contabilística ...".

Agora, me corrija se eu estiver errado, mas eu nunca ter notado uma IFRS que (como ASC 350-40) especificamente se aplica Software para Uso Interno.

Isto implica que, se alguém se questionar meu julgamento que Software para Uso Interno é capitalizáveis, além de IAS 38,57, eu também poderia apontar para um padrão (definido por um corpo de definição de padrões que usam uma estrutura conceptual semelhante para desenvolver normas de contabilidade ), que estipula que o meu julgamento é GAAP.

Além disso, como um benefício adicional, EUA GAAP fornece explícita, clara e fácil de seguir instruções sobre como configurar um procedimento contábil para realizar essa tarefa.

As únicas razões que eu posso ver por que alguém não gostaria de aproveitar-se de uma oportunidade como essa:

1. um não tem conhecimento que os EUA GAAP existe

2. um não tem conhecimento do seu conteúdo

3. um não percebe que ele pode ser usado para complementar IFRS (especialmente em situações onde a orientação às vezes vaga, abstrata e teórica IFRS é difícil de traduzir para o dia-a-dia da prática).

# 14 Agosto 2010 às 09:42

patriciawalters disse:

Eu nunca disse que estas decisões foi fácil. Dificilmente qualquer decisão relatório financeiro nos dias de hoje é fácil. Como eu digo aos meus alunos, se essas decisões foram fáceis e sempre havia uma resposta clara, não estaria procurando para fazer as "chorudas" na graduação.

No entanto, a filosofia por trás da abordagem IFRS "princípios de relatório financeiro é de que a norma não fornecer uma lista de cada item específico que a norma se aplica ou não se aplica a.

Software é um ativo intangível. Assim, aplica-se a IAS 38.
IAS 38 cobre intangíveis desenvolvidos internamente para uso próprio. Assim, os custos de desenvolvimento associados com software desenvolvido internamente podem ser capitalizados nos termos da IAS 38, se os critérios para a capitalização sejam atendidas.

Algumas empresas não pode precisar de olhar para além da orientação que está disponível no IAS 38 para determinar se esses critérios forem cumpridos e não há necessidade de fazê-lo.

Na verdade, há um perigo de imediato saltando para orientação fornecida por outros standard-setters (EUA GAAP) ou o desenvolvimento de um hábito de fazê-lo. Tal orientação nem sempre é consistente com o IFRS ou seu quadro conceptual e preparadores precisa estar vigilante em usar a orientação muito detalhada fornecida por EUA GAAP que irá produzir resultados de acordo com o IFRS.

Finalmente, atualmente disponíveis materiais escritos, como o livro que você cita não são uma orientação confiável sobre ou IFRS ou GAAP dos EUA. Qualquer coisa escrita no livro, não importa o quão bem-respeitado os autores, é puramente sua opinião considerada. Eles são homens (e mulheres), não deuses ou do IASB ou IFRIC. Por isso, sinto-me livre de discordar com autores de tais livros. E, muitas vezes, fazer. Assim como estamos discordando aqui.

Se você acredita que é necessária uma orientação adicional sobre como julgar se um critério específico em IFRS é inadequado e precisa de esclarecimentos, o lugar para ir para essa orientação adicional ou é IFRIC ou o IASB. EUA não GAAP.

Caso contrário, você está basicamente dizendo que as pessoas aprendam um mínimo de dois conjuntos de normas de contabilidade, ao invés do que se espera para aplicar. Qual é o ponto de que a recomendação?

Patricia Walters

# 14 Agosto 2010 às 12:41

Mladek disse:

Eu concordo com você.

Princípios baseados significa ser permitido alcançar um seu próprio julgamento profissional. Mas esse acórdão não viver em um vácuo. Julgamento tem que ser justificado (para os superiores, um de auditores, possivelmente um de regulador e, se o pior vem a pior, quadra de menos).

Como para as pessoas que têm que "aprender um mínimo de dois conjuntos de padrões de contabilidade, em vez do que a que se espera que se aplicam."

Em que ponto exatamente menos conhecimento tornar-se superior a mais conhecimento?

Além disso, eu não estou recomendando nada. Esta é uma discussão aberta. Eu não estou sendo pago para os meus serviços. Eu não o que está sendo solicitado a assumir a responsabilidade por meu julgamento. As pessoas podem ler o que eu escrevi, utilizar a informação fornecida, ou não. Eu realmente não poderia me importar menos maneira que eles decidem.

Estou simplesmente apontando que, enquanto o IFRS não abordar claramente o tema em apreço, EUA GAAP faz.

Também estou apontando que, enquanto as empresas de IFRS não são obrigados a seguir essa orientação, não é (uma vez que o IFRS não fornecer orientações conflitantes) anulado.

Oh, BTW, não fui eu que abriu a porta para qualquer GAAP dos EUA ou não-autorizada literatura. O IASB conseguiu fazer isso por si mesmo, afirmando "Ao fazer o julgamento descrito no parágrafo 10, a gerência pode também considerar ... outra literatura contabilística e práticas aceites do sector, na medida em que estas não entrem em conflito ...".

Isto significa também, autoritário ou não, tal literatura tem uma influência sobre a prática. Simplesmente desejando que não fosse, não vai fazer não é assim.

Quanto aos conselhos, como: "Se você acredita que é necessária uma orientação adicional sobre como julgar se um critério específico em IFRS é inadequado e precisa de esclarecimentos, o lugar para ir para essa orientação adicional ou é IFRIC ou o IASB".

Este conselho é local, mas (obviamente) pertinente apenas nas situações em que o IASB ou IFRIC decidiu fornecer tal orientação.

Tanto quanto eu sei, a única orientação "autoritária" fornecido no tópico em questão são estas três palavras (em negrito): "IAS 38,62 de uma entidade de sistemas de custeio podem muitas vezes mensurar com fiabilidade o custo de gerar internamente um activo intangível, tais como salário e outras despesas incorridos para assegurar copyrights ou licenças ou para desenvolver software de computadores. "

Colheitas muito escassos.

SIC a certeza de idade publicou SIC 32, mas analogias a partir de uma interpretação lidar com os custos do site web para software em geral é um trecho muito longe (se é permitido a todos).

Hmmm, talvez eu devesse tentar escrever o IASB / IFRIC uma carta? Talvez eles até mesmo escrever de volta. Ou, melhor ainda, talvez eles adicionar um projeto de software desenvolvido internamente para a sua agenda. Não seria bacana.

Claro, se tudo o que eu tinha de lidar com os alunos foram, tal conselho seria suficiente. Se eu desse tal conselho a um cliente pagar, ele quer seu dinheiro de volta (se ele não me processar por incompetência processional que é).

Embora eu também acordo (tempo o tempo) com os alunos, meus clientes do mundo real necessidade de resolver problemas do mundo real. E, no mundo real, as coisas ficam confuso. E quando as coisas não ficar confuso, com mais de três palavras vem a calhar.

É verdade, ninguém tem a obrigação de conhecer EUA GAAP, a fim de aplicar a IFRS (ou vice-versa). Mas não faz mal (especialmente desde que o IASB eo FASB estão trabalhando fora tão diligentemente na sua convergência).

Quando essa orientação também corresponde ao meu próprio julgamento profissional. Ei, eu chamo de que o nirvana contabilidade em meu livro.

E a faca de dois gumes.

Meus clientes incluem empresas de US GAAP (listagem primária em os EUA), UE-IFRS empresas (usando IFRS devido a CE 1606/2002) e IASB-IFRS empresas (principalmente emissores privados estrangeiros com uma escuta secundário em os EUA aproveitando a da SEC relaxou requisitos IFRS).

Eles acham que, quando se trata de lidar com os auditores particulares ou reguladores (surpresa, surpresa), estes tendem a deixar-se influenciar pelos padrões de sua casa.

E depois há as razões prosaicas.

Se, por exemplo, uma empresa dos EUA com operações significativas na UE quer ao pessoal do seu departamento de contabilidade com cidadãos europeus (em vez de EUA caro ex-mf), é melhor ter algum conhecimento IFRS. E se não tem, é melhor obtê-lo (caso contrário, ele é muito bonito de rosca).

Mas, eu discordo.

Oh bem.

Eu acho que é porque está a chover lá fora e eu fico aqui sem nada melhor para fazer do que me ouvir falar (err ... gravação).

# 14 Agosto 2010 às 15:32

patriciawalters disse:

Mladek:

Suas respostas são exatamente o que fazer responder a perguntas sobre esta lista que vale a pena. Desejo mais questionadores teria se envolvido em uma discussão ou debate sobre as questões, especialmente as que existem diferenças de pontos de vista.

O IASB abriu a porta para o uso dos pronunciamentos de outros que pensam como padrão-setters na IAS 8, com respeito à hierarquia. O meu ponto não é ir lá primeiro. Afinal, algumas pessoas estão vindo para esta lista para o conselho e não estamos de autoridade, por qualquer meio.

Se você gosta de debater questões de contabilidade, você deve se juntar a listserv AECM em aecm@listserv.loyola.edu Muita discussão vigorosa lá.

Então, por favor, não leve meus comentários pessoalmente. Eu adoro um debate agressivo, mesmo quando estou profundamente golpeados. Espero cerca com você novamente em outro assunto e talvez nós vamos concordar.

E, eu faço mais do que apenas ensinar ....

Patricia Walters

# 14 Agosto 2010 às 05:19

Mladek disse:

Eu não.

E eu adoro um bom debate também (especialmente em uma tarde chuvosa de sábado).

Até a próxima.

Robert

PS, se eu pudesse fazer um ensino vivo só, eu não faria nada.

# 14 de agosto de 2010 às 5:43 pm

Sarun disse:

Além de considerar o valor econômico futuro, o custo total de criar os softwares tem que ser julgado. Se não é material, eu acredito que a capitalização não vai acrescentar valor para você.

# 16 Agosto 2010 às 07:02