Capitalização de software desenvolvido internamente
12 de agosto de 2010 9,855 visualizações 11 Comentários
Minha empresa desenvolve software para uso interno (embora possa também ser vendido para outras empresas similares). É quase sempre substitui o software que comprou na hora mais cedo, assim que ele gera benefícios econômicos visíveis, reduzindo os custos. Podemos aproveitar nosso software desenvolvido internamente?
Posts Relacionados
- Emissão de obrigações relacionadas com o custo
- Revisão de arquivo de software útil
- Mudança de vida de software de computador IAS 16, IAS 8
- Capitalização Software / contabilizadas fora
- Contabilidade de Custos e Software
- Data de produção comercial
- Software de reconhecimento de receitas segundo as IFRSs e SOP 97 -
- Software de auditoria
- Software de auditoria interna
- Capitalização Software


















[RESOLVIDO] Capitalização de software desenvolvido internamente - http://www.ifrslist.com/2010/08/capitali .. .
via Twitoaster
Infelizmente, ao contrário de EUA GAAP ( ASC 350-40 ). IFRS não tratam especificamente de software. IAS 38, no entanto, lidar com ativos intangíveis gerados internamente (o que inclui software).
IAS 38 apresenta 6 critérios que devem ser cumpridas se os custos de desenvolvimento estão a ser capitalizado. Destes, demonstrando (IAS 38.57.d) "como o ativo intangível gerará prováveis benefícios económicos futuros ..." é a mais onerosa.
Na minha opinião, se a entidade pretende utilizar o recurso internamente, ele não teria nenhum problema demonstrando "a utilidade do ativo intangível", para que ele pudesse capitalizar.
Infelizmente, este não é o único ponto de vista. Por exemplo Epstein acha que não é possível demonstrar como o SW irá gerar benefícios económicos e que (mesmo apesar de 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 não carregar muito peso (muito mais do que meu).
Felizmente, eles não são definitivos.
IAS 8.12 afirma "Ao fazer os julgamentos descritos no parágrafo 10, a gerência pode também considerar os pronunciamentos mais recentes de outros órgãos normalizadores que usem uma estrutura conceptual semelhante para desenvolver normas de contabilidade, ..." o que significa que (desde IFRS não trata explicitamente com a questão) é aceitável considerar o GAAP dos EUA pertinente.
Que os EUA GAAP (ASC 350-40-25) é bastante explícito: "Os custos -1 internos e externos incorridos durante a fase de projeto preliminar deve ser contabilizados como despesas conforme são incorridas. -2 Custos internos e externos incorridos para desenvolver software de uso interno do computador durante o estágio de desenvolvimento da aplicação devem ser capitalizados. Custos -3 para desenvolver ou obter software que permite o acesso ou a conversão de dados antigos por novos sistemas devem também ser capitalizado. Os custos de formação -4 não são de uso interno custos de desenvolvimento de software e, se incorridas durante esta fase, serão imputados como incorridos. 5Data de custos de conversão, exceto conforme indicado no parágrafo 350-40-25-3, deve ser resultado quando incorridos. -6 Custos de formação internos e externos e custos de manutenção durante a fase de postimplementation operação serão imputados como incorridos. "
Assim, tanto quanto eu estou preocupado, os custos de SW desenvolvido internamente são adequadas para a capitalização em IFRS e, se eu correr em resistência, eu posso sempre voltar a cair GAAP dos EUA.
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 de uso interno estiver concluída, uma entidade decide comercializar o software, os montantes recebidos a partir da licença do software de computador ... deve ser aplicada contra a quantia escriturada desse software. -8 Lucro Não deve ser reconhecido até agregar receita líquida de licenças e amortização ter reduzido a quantidade de carga do software para zero. ... "
Assim, se alguém faz uso GAAP dos EUA para justificar o julgamento oen como por IFRS, e uma companhia se decidir vender o software, não será capaz de registar as receitas até que o ativo capitalizado é totalmente anulada.
Isso faz com que EUA GAAP uma espada de dois gumes. Por um lado, faz justificar o julgamento de capitalizar fácil, por outro, impede o reconhecimento de um monte de receitas. Mas isso é apenas a maneira que vai.
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 ALL de seguir antes de começar a capitalizar os custos:
(1) viabilidade técnica de concluir o activo intangível afim de que ele estará disponível para uso ou venda
(2) a sua intenção de concluir o activo intangível e usar ou vender.
(3) a sua capacidade para usar ou vender o ativo intangível
(4) como o ativo intangível 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 o próprio activo intangível ou, se é para ser usado internamente, a utilidade do activo intangível.
Então, certamente, isso permite-lhe capitalizar alguns dos custos associados ao desenvolvimento de software para uso interno. Você não será capaz de capitalizar os custos que você imputadas antes de conhecer esses critérios. Você não vai se capitalizando todos os seus gastos.
Astra Zeneca é uma empresa que divulga os "custos de desenvolvimento de software" como um tipo separado de ativo na Nota 9, Ativos Intangíveis ".
Eu vi os outros também.
Espero que isso ajude.
Patricia Walters
Eu queria adicionar.
Não há nenhuma razão para ir às exigências do US GAAP ou restrições.
IFRS faz acordo com a capitalização de custos de desenvolvimento de ativos intangíveis a serem utilizados internamente. O fato de que a norma faz dizer: "Ah, a propósito, o software é um bem intangível que você pode desenvolver internamente", não é relevante.
Software é um intangível que pode ser (e muitas vezes é) desenvolvido internamente ea decisão de capitalização é coberto pela IAS 38.
GAAP dos EUA é irrelevante. Na minha opinião, seria inapropriado de olhar para EUA GAAP para orientação porque IAS 38 explica claramente quais são os critérios de capitalização são.
Patricia Walters
"Diz" deve ser "não diz" no meu post anterior. Desculpe.
Patricia
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, muito lido publicações (como WILEY Interpretação e Aplicação de Normas Internacionais de Relato ... Por Barry J. Epstein, Eva K. Jermakowicz) não chegaram à conclusão oposta.
Se fosse, os auditores poderia assinar em empresas capitalizando tudo, incluindo a pia da cozinha.
Se fosse, eu não teria incomodado citando GAAP dos EUA.
Em qualquer caso, eu não estou dizendo que é impossível convencer um cético que um auditor tenha cumprido todos os critérios, conforme descrito no parágrafo 57. O que estou dizendo é que não pode ser um slam dunk.
Este é especialmente o caso na Europa continental, onde um é executado em auditores que, enquanto especialista em aplicar as suas próprias "GAAP nacionais", ter experiência mãozinha primeira interpretar e aplicar as IFRS (ou sistemas, como o GAAP dos EUA ou UK GAAP, desenvolvido por órgãos normalizadores que utilizam marcos conceituais semelhantes).
Quanto ao GAAP dos EUA sendo irrelevante, seria, se IFRS não declarar explicitamente o contrário.
IAS 8.12: "Ao fazer os julgamentos descritos no parágrafo 10, a gerência pode também considerar os pronunciamentos mais recentes de outros órgãos normalizadores que usem uma estrutura conceptual semelhante para desenvolver normas de contabilidade, a literatura contábil outro 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á julgamentos no desenvolvimento e aplicação de uma política contabilística ...".
Agora, me corrija se eu estiver errado, mas eu nunca ter percebido que uma IFRS (como ASC 350-40) se aplique especificamente a software de uso interno.
Isto implica que, se alguém se questionar meu julgamento que software de 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 juízo é 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. não está ciente de que existe GAAP dos EUA
2. um não tem conhecimento de seu conteúdo
3. não se 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).
Eu nunca disse que tomar essas decisões foi fácil. Dificilmente qualquer decisão relatórios financeiros hoje em dia é fácil. Como eu digo aos meus alunos, se essas decisões são fáceis e sempre havia uma resposta clara, que não estaria procurando para fazer as "chorudas" sobre a graduação.
No entanto, a filosofia por trás da abordagem IFRS "princípios para relatórios financeiros é que a norma não fornece uma lista de cada item específico que a norma aplica-se ou não se aplicam.
Software é um activo intangível. Assim, a IAS 38 se aplica.
IAS 38 abrange intangíveis desenvolvidos internamente para uso próprio. Assim, os custos de desenvolvimento associados com software desenvolvido internamente pode ser capitalizado segundo a IAS 38, se os critérios de capitalização, são 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 estes critérios estão preenchidos e não há nenhuma exigência para o fazer.
Na verdade, existe o perigo de imediato pulando para orientação fornecida por outro padrão-setters (EUA GAAP) ou desenvolver um hábito de fazê-lo. Tal orientação nem sempre é consistente com as IFRS, ou o seu quadro conceptual e os preparadores têm que estar vigilantes no uso da orientação muito detalhada fornecida pelo GAAP dos EUA que produzirá resultados de acordo com as IFRS.
Por fim, atualmente disponíveis materiais escritos, como o livro que você cita não são uma orientação confiável sobre as IFRS ou GAAP dos EUA. Qualquer coisa escrita no livro, não importa quão bem-respeitado os autores, é puramente a sua opinião considerada. Eles são homens (e mulheres), e não deuses ou do IASB ou IFRIC. Daí, eu me sinto livre para discordar com os autores desses livros. E, muitas vezes fazemos. Assim como estamos discordando aqui.
Se você acredita que é necessária orientação adicional sobre como julgar se um critério específico em IFRS é inadequada e precisa de esclarecimentos, o lugar para ir para essa orientação adicional é ou IFRIC ou o IASB. Não GAAP dos EUA.
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 aplicar. Qual é o ponto de que a recomendação?
Patricia Walters
Eu concordo com você.
Princípios baseados significa ser permitido alcançar seu julgamento profissional. Mas esse julgamento não vive num vácuo. Julgamento tem que ser justificado (para os superiores, um de auditores, possivelmente um de regulador e, se pior vem a pior, no tribunal).
Como para pessoas que tenham a "aprender um mínimo de dois conjuntos de normas de contabilidade, ao invés do que se espera para aplicar."
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 um ser convidado a assumir a responsabilidade para o meu julgamento. As pessoas podem ler o que escrevi, use as informações fornecidas, ou não. Eu realmente não poderia me importar menos maneira que eles decidem.
Estou simplesmente apontando que, enquanto IFRS não abordar claramente o tema em apreço, EUA GAAP faz.
Também estou apontando que, enquanto as empresas IFRS não são obrigados a seguir esta orientação, não é (desde IFRS não fornecer orientações conflitantes) não permitido.
Ah, BTW, não fui eu quem abriu a porta para qualquer GAAP dos EUA ou não-autorizada da literatura. O IASB conseguiu fazer isso por si só, afirmando "Ao fazer os julgamentos descritos no parágrafo 10, a gerência pode também considerar ... outra literatura contábil e práticas aceites do sector, na medida em que estes 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 orientação adicional sobre como julgar se um critério específico em IFRS é inadequada e precisa de esclarecimentos, o lugar para ir para essa orientação adicional é ou IFRIC ou o IASB".
Este conselho está no local, mas (obviamente) pertinente apenas nas situações em que o IASB ou IFRIC decidiu prestar essa orientação.
Tanto quanto eu sei, a única orientação "oficial" 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 outros dispêndios incorridos para assegurar copyrights ou licenças ou para desenvolver software de computador. "
Colheitas muito escassa.
SIC a certeza de idade publicado SIC 32, mas analogias de uma interpretação lidar com os custos do Web site de software em geral, é um trecho muito longe (se é permitido em todos).
Hmmm, talvez eu deveria tentar escrever o IASB / IFRIC uma carta? Talvez eles até escrever de volta. Ou, melhor ainda, talvez eles adicionar um projeto de software desenvolvido internamente, a sua agenda. Não seria bacana.
Claro, se tudo que eu tinha de lidar com os alunos eram, 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 (hora o tempo) com os alunos, os meus clientes do mundo real necessidade de resolver os problemas do mundo real. E, no mundo real, as coisas ficam confusas. 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 GAAP dos EUA, 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 a sua convergência).
Quando essa orientação também corresponde ao meu próprio julgamento profissional. Hey, eu chamo isso de nirvana contabilidade no meu livro.
E a faca de dois gumes.
Meus clientes estão empresas US GAAP (listagem primária em os EUA), UE-IFRS empresas (usando IFRS devido à CE 1606/2002) e IASB-IFRS empresas (principalmente emissores privados estrangeiros com uma escuta secundária em os EUA aproveitando a da SEC relaxado 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 o seu pessoal departamento de contabilidade com os cidadãos europeus (em vez de EUA caro ex-pats), é melhor ter algum conhecimento IFRS. E se não tiver, é melhor obtê-lo (caso contrário, ele é muito bonito de rosca).
Mas, eu discordo.
Oh bem.
Eu acho que é porque está chovendo lá fora e eu fico aqui sem nada melhor para fazer do que ouvir-me falar (err ... escrita).
Mladek:
Suas respostas são exatamente o que fazer responder a perguntas sobre esta lista 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 da mesma standard-setters na IAS 8, com respeito à hierarquia. Meu ponto não é ir lá primeiro. Afinal, algumas pessoas estão vindo a esta lista para o conselho e nós não somos autorizada, por qualquer meio.
Se você gosta de debater questões de contabilidade, você deve se juntar ao listserv AECM em aecm@listserv.loyola.edu~~HEAD=NNS 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 arrasado. Espero que a cerca com você novamente em outro assunto e talvez a gente vai concordar.
E, eu faço mais do que apenas ensinar ....
Patricia Walters
Eu não.
E eu adoro um bom debate também (especialmente em uma tarde de sábado chuvoso).
Vejo você na próxima vez.
Robert
PS, se eu pudesse fazer um ensino vivo só, eu não faria nada.
Além de uma consideração do valor económico futuro, o custo total de criar os software tem de ser julgado. Se não é material, acredito que a capitalização não vai agregar valor para você.
Deixe sua resposta!
Você deve estar logado para postar um comentário.
Boas-vindas
Cursos IFRS ao redor do mundo
Membro recente
27 de abril de 2012
27 de abril de 2012
25 de abril de 2012
24 de abril de 2012
20 de abril de 2012
19 abr 2012
19 abr 2012
18 de abril de 2012
18 de abril de 2012
Abril 17, 2012
16 abr 2012
14 de abril de 2012
Comentários Recentes
Etiquetas
Saudações
Categorias
Contribuintes
Ajude a manter IFRSLIST LIVRE
IFRS CURSOS
IFRS RECURSOS
Quem sou eu
Arquivo
Links Úteis
Tradutor
Mensagens recentes
Mais Comentadas
Mais Vistos