XBRL... muito mais do que apenas conformidade

Após uma recente visita à 19.ª Conferência Internacional XBRL em Paris, não consigo deixar de pensar que muitas organizações simplesmente não compreendem a importância do assunto – e que, talvez, a exigência da SEC seja, em parte, responsável por isso. Acreditava-se (bem, eu acreditava, pelo menos) que, no ano seguinte à implementação das exigências de reporte XBRL pela maior economia do mundo, esta conferência estaria repleta de representantes de empresas ansiosos por aprender mais sobre como, e, acima de tudo, por que deveriam formatar os seus dados financeiros em XBRL. Mas, infelizmente, essa não foi a realidade.

Apenas posso especular que o baixo número de participantes – especialmente dos Estados Unidos – está relacionado ao facto de as organizações ainda considerarem o XBRL como um problema exclusivamente de conformidade, e continuarem a terceirizar a "marcação" das suas demonstrações financeiras para empresas de impressão financeira ou outras entidades que submetem documentos ao sistema EDGAR.

Portanto, o XBRL é uma questão de conformidade? Bem, claro que é, mas é muito mais do que isso. Posso afirmar isso com certeza, pois trabalho na Altova e nós simplesmente não nos focamos em software de conformidade. Desenvolvemos ferramentas que ajudam as empresas a maximizar a eficiência das suas interno Os processos devem ser otimizados com o objetivo de reduzir o tempo e o custo total do fluxo de trabalho de gestão de dados. E isso é perfeitamente possível para qualquer empresa que utilize o XBRL, mas implica uma análise proativa da forma como os seus dados são geridos.

"Etiquetagem" implica que as demonstrações financeiras são elaboradas da forma tradicional, num programa de cálculo ou software de contabilidade, e depois são marcadas retroativamente e minuciosamente com etiquetas XBRL para garantir a conformidade. Que horror... não é de admirar que a conformidade tenha uma conotação tão desagradável! Não temos trabalho suficiente? E esperem, não é isto apenas adicionar mais uma tarefa manual a outra, duplicando as chances de erro humano? Não sei exatamente quando a palavra "etiquetagem" se tornou tão popular para descrever a implementação do XBRL, mas tudo o que conseguiu foi simplificar em demasia algo que, originalmente, não era assim tão complicado (admito, provavelmente foi cunhada por alguém da área de marketing – e eu sou membro dessa área).

De qualquer forma, vamos deixar de lado a ideia de etiquetagem e ver se conseguimos encontrar algo um pouco mais inovador. Imagine que todos os dados financeiros da sua empresa estão armazenados num determinado repositório, seja uma base de dados, um sistema de contabilidade/ERP, XML, ou até mesmo uma combinação destes. E se pudessem simplesmente converter os seus dados para o formato XBRL internamente, em vez de recorrer a consultores externos para analisarem relatórios e etiquetarem cada linha? E se pudessem até reutilizar essa conversão na próxima vez que tivessem de produzir um relatório financeiro semelhante? E se o seu departamento de TI pudesse até automatizar os processos de submissão de dados no formato XBRL?

Mapeamento XBRL Altova MapForce é uma ferramenta de nível empresarial ferramenta de integração de dados que permite fazer exatamente isso. É utilizado por programadores e arquitetos de aplicações num nível avançado, mas a sua interface gráfica fácil de usar torna o MapForce acessível a qualquer pessoa que compreenda os dados que precisam de ser mapeados. Vamos analisar um exemplo parcial para ilustrar o quão fácil pode ser: o primeiro passo é carregar o componente de dados de origem – neste caso, uma base de dados – no painel de design do MapForce.

Note que o componente de mapeamento é uma representação das tabelas e colunas no banco de dados. Portanto, os dados subjacentes podem ser alterados a qualquer momento, e o mapeamento em si não será afetado. O mesmo se aplica a qualquer estrutura de mapeamento que utilize no MapForce – XML, bases de dados, ficheiros simples, EDI, Excel, XBRL ou serviços web. Em seguida, vamos adicionar o nosso componente de mapeamento de destino, neste caso, uma taxonomia básica de extensões XBRL construída sobre a norma US GAAP - Comercial e Industrial.

Agora, podemos começar o mapeamento simplesmente conectando linhas para associar os elementos. Haverá casos em que será necessário aplicar regras de processamento de dados para modificar ligeiramente o formato, filtrar dados ou até mesmo adicionar constantes para requisitos de relatório XBRL que não existem na base de dados. Tudo isto pode ser feito muito facilmente arrastando e soltando funções intermediárias da biblioteca MapForce na barra lateral.

Suponhamos, por exemplo, que a sua base de dados exige automaticamente um formato de data e hora para registar qualquer período contabilístico. Como a comunicação XBRL exige apenas a data, é necessário remover a informação da hora na nossa configuração. Para isso, basta arrastar uma função de extração da data a partir da hora da biblioteca e conectar as linhas entre a sua base de dados e o componente XBRL.

É claro que, provavelmente, também precisará adicionar uma variedade de outras funções matemáticas, lógicas ou de outros tipos aos seus dados, e encontrará uma longa lista destas já disponíveis na biblioteca de funções.

Também pode adicionar facilmente funções personalizadas, se necessário, utilizando um construtor de funções gráfico. No final, o seu mapeamento terá uma aparência semelhante a esta:

Agora, basta clicar na aba "Saída" para ver como é o formato XBRL. E pronto... tem um mapeamento de dados reutilizável e extensível que pode usar sempre que precisar de submeter dados em formato XBRL. Pode até integrar a interface de mapeamento noutra aplicação, ou pedir ao departamento de TI para gerar código que automatize a criação dos ficheiros XBRL sempre que um relatório for necessário. Para uma visão mais detalhada de como o mapeamento XBRL funciona no MapForce, consulte o nosso tutorial XBRL da Altova.

Aqui temos um exemplo muito rápido de como gerar XBRL diretamente a partir de um sistema de contabilidade: não é necessário voltar a introduzir informações, não é preciso criar um conjunto de demonstrações financeiras tradicionais, e certamente não é necessário "etiquetar" os dados. E o melhor de tudo é que tudo isto pode ser feito facilmente internamente e a uma fração do custo. Agora, não me entendam mal, a terceirização pode ter um papel na implementação do XBRL da sua empresa. Criar uma taxonomia de extensão XBRL, Por exemplo, pode ser algo que se sinta mais confortável em deixar a quem tem anos de experiência a trabalhar com a sintaxe XBRL e outras complexidades. Mas a conversão dos dados financeiros da sua organização para o formato XBRL... não deveria isso ser deixado a quem melhor conhece esses dados?

Para obter mais informações sobre o Altova MissionKit, consulte ferramentas para XBRL - que inclui suporte para Mapeamento e automatização XBRL, Validação XBRL e criação de taxonomias, e Renderização XBRL - por favor, visite https://www.altova.com/solutions/xbrl-tools.html ...ou Descarregue o Altova MissionKit hoje!