Conceber um plano de contas

Para que serve um plano de contas

Um plano de contas é a lista de gavetas onde acaba cada transação de uma empresa. Determina o que as suas demonstrações financeiras podem dizer, a que perguntas o seu reporte consegue responder e quanto trabalho manual se interpõe entre uma transação lançada e um número útil. É a peça de configuração com mais consequências em qualquer sistema contabilístico, e quase sempre é concebida à pressa durante a implementação, por quem por acaso estava disponível.

Merece mais cuidado por causa da assimetria de custos. Concebê-lo bem exige alguns dias de reflexão. Corrigi-lo mais tarde custa a comparabilidade do histórico, um exercício de mapeamento em todas as integrações e uma conversa com o seu auditor. Quase todas as empresas que usam o mesmo sistema há mais de cinco anos carregam um plano de contas que não voltariam a desenhar assim e que não conseguem mudar com facilidade.

A questão central de desenho é enganadoramente simples: o que pertence ao código da conta e o que pertence a outro sítio? Quase todas as falhas de um plano de contas são uma resposta a essa pergunta que meteu demasiado no código da conta. Perceber porquê exige ter claro o que uma conta realmente é.

Uma conta responde à pergunta: que tipo de coisa é esta? Rendas. Clientes. Vendas de mercadorias. Descreve a natureza do montante, e é a única pergunta a que deve responder. Onde aconteceu, para quem foi, que projeto, que departamento, que linha de produto: são todas perguntas reais, e nenhuma delas é uma pergunta sobre a natureza do montante.

A falha da proliferação

O plano de contas mais comum do mundo é mais ou menos assim. Existe uma conta para rendas. Depois a empresa abre uma segunda loja, e passa a haver rendas da loja um e rendas da loja dois. Depois alguém quer ver as rendas por departamento, e cada uma divide-se outra vez. Depois surge um novo centro de custo e todas as contas da gama de gastos operacionais são duplicadas para ele. Em poucos anos há quatro mil contas, a maioria das quais só tem saldo em três meses do ano.

Isto não falha de forma visível. Falha tornando as coisas gradualmente impossíveis. O reporte consolidado exige somar centenas de contas, e cada nova loja obriga a reconstruir o relatório. Comparar lojas significa comparar códigos de conta diferentes, o que nenhum relatório-padrão faz. Fechar uma loja deixa vinte contas mortas que não podem ser apagadas porque têm histórico. Abrir uma loja significa criar vinte contas e lembrar-se de as acrescentar a todos os relatórios, orçamentos e mapeamentos. Um dia alguém lança a renda da loja dois na conta da loja um, e o erro fica invisível no total consolidado.

O custo mais profundo é que a estrutura gravou no razão, de forma rígida, um facto sobre o negócio. Lojas, departamentos e linhas de produto mudam. Fundem-se, dividem-se, mudam de nome e são reorganizados. Sempre que isso acontece, um plano de contas que os codifica estruturalmente tem de ser reconstruído, e o histórico torna-se incomparável precisamente no momento em que alguém o quer comparar.

O sintoma a vigiar é a repetição. Se olhar para a sua lista de contas e vir a mesma palavra repetida a intervalos, rendas, rendas, rendas, salários, salários, salários, então esse conceito repetido não é um tipo de gasto. É uma dimensão do negócio que foi forçada para dentro do código da conta por não haver outro sítio onde a pôr.

Contas versus dimensões

Quase todos os sistemas contabilísticos construídos nos últimos vinte anos suportam atributos de lançamento ao lado do código da conta, chamados consoante o caso dimensões, segmentos, códigos analíticos, etiquetas, centros de custo ou categorias de acompanhamento. Um lançamento leva uma conta mais um ou mais valores de dimensão, e os relatórios podem ser produzidos por conta, por dimensão ou por ambas.

Isto muda por completo o problema de desenho. Rendas é uma conta. Loja é uma dimensão com um valor para cada loja. A renda da loja dois não é uma conta separada; é a conta de rendas filtrada pela loja dois. Abrir uma loja acrescenta um valor de dimensão em vez de vinte contas. Fechar uma loja desativa um valor. Comparar lojas é um relatório-padrão com um agrupamento, não um desenvolvimento à medida. E a lista de contas mantém o tamanho que deve ter, que para a maioria das médias empresas é de algumas centenas de contas e não de alguns milhares.

O teste para saber se algo é uma conta ou uma dimensão é se altera a natureza do montante ou o seu contexto. A renda em Riade e a renda em Jidá são o mesmo tipo de custo em sítios diferentes, portanto o local é uma dimensão. Rendas e salários são tipos de custo diferentes, portanto são contas diferentes. Aplicar este teste de forma consistente elimina a maior parte da proliferação antes de ela começar.

Dois avisos sobre dimensões. Primeiro, só são úteis se forem obrigatórias onde fazem sentido, porque uma dimensão preenchida em oitenta por cento dos lançamentos produz relatórios com um resto inexplicado, e esse resto destrói a confiança no relatório mais depressa do que não haver relatório nenhum. Segundo, resista à tentação de definir dez dimensões só porque o sistema permite dez. Cada dimensão é um campo que alguém tem de preencher corretamente em cada transação, e uma dimensão por preencher é pior do que uma dimensão inexistente.

• Loja, local, instalação ou ponto de venda: uma dimensão. O custo é do mesmo tipo onde quer que ocorra.
• Departamento, centro de custo ou função: uma dimensão. Determina quem responde pelo gasto, não o que foi comprado.
• Projeto, obra ou contrato: uma dimensão, e muitas vezes a que tem mais valor para o reporte.
• Linha de produto, linha de serviço ou segmento de negócio: uma dimensão, e a base da maior parte do relato por segmentos.
• Cliente e fornecedor: de todo não são contas. Pertencem a subrazões, por trás de uma conta de controlo.
• Trabalhador: não é uma conta. O detalhe salarial pertence ao sistema de processamento salarial, resumido no razão.
• Entidade jurídica: normalmente um razão separado e não uma dimensão, embora alguns sistemas a tratem como segmento.

Numeração

A numeração das contas é menos importante do que o desenho das dimensões e mais discutida. O que um esquema de numeração tem de fazer é tornar o tipo de conta evidente pelo código, deixar espaço para inserir contas sem renumerar e ordenar-se numa sequência lógica de demonstrações sem um mapeamento à parte.

A estrutura convencional agrupa por classificação nas demonstrações: ativo, passivo, capital próprio, rendimentos, gastos, cada um com um dígito inicial ou uma gama, e subgamas dentro de cada um para as classes. Ativo corrente separado do não corrente. Custo das vendas separado dos gastos operacionais. Gastos de financiamento separados de ambos. As gamas concretas importam muito menos do que o facto de existirem e de os intervalos entre elas serem suficientemente largos para inserir contas.

Os nomes das contas merecem tanta atenção como os números e não recebem quase nenhuma. Um nome deve descrever o que pertence à conta com precisão suficiente para que duas pessoas a lançar a mesma transação escolham a mesma conta. Diversos, vários, gerais e outros são nomes que garantem que isso não acontece, e uma conta chamada Gastos gerais absorverá tudo aquilo sobre que alguém tenha dúvidas, que é exatamente a população que mais precisa de ver.

• Use um comprimento constante. Códigos de comprimentos mistos ordenam-se de forma imprevisível e estragam as exportações para qualquer ferramenta que os trate como texto.
• Deixe intervalos. Uma numeração sequencial sem espaço obriga, em menos de um ano, a renumerar ou a criar uma conta fora de sequência.
• Agrupe primeiro pela classificação nas demonstrações, para que a lista de contas se ordene pela ordem dos relatórios sem uma camada extra de mapeamento.
• Mantenha as subgamas com significado. Se uma conta está na gama do ativo corrente, deve ser ativo corrente, sem exceções mantidas por razões históricas.
• Não codifique dimensões no número. Um código que significa renda, loja dois, é uma dimensão disfarçada.
• Não renumere contas existentes. O custo recai sobre o histórico, as integrações e toda a gente que decorou um código, e o benefício é cosmético.

Contas de controlo e o que não pode ser lançado diretamente

Algumas contas do balanço resumem um subrazão. Clientes, fornecedores, inventários, ativos fixos e normalmente impostos têm, cada um, uma única conta no razão cujo saldo deve ser igual ao total de uma listagem detalhada mantida noutro sítio. São contas de controlo, e a decisão de desenho que importa é que não podem aceitar lançamentos diretos.

Quando um utilizador pode lançar um movimento manual diretamente na conta de controlo de clientes, a conta de controlo e o subrazão afastam-se, e o desvio só é descoberto quando alguém reconcilia. Tornar as contas de controlo não lançáveis, ou restringir o lançamento direto a um pequeno número de pessoas identificadas que estejam a corrigir um erro conhecido, converte um controlo detetivo mensal num controlo estrutural. É uma das melhorias mais baratas disponíveis na maioria das implementações, e muitas vezes não está configurada.

Um ponto estrutural relacionado é que nem todas as contas devem ser lançáveis. Um plano bem construído tem contas agregadoras ou de totalização, que existem para agrupar e reportar, e contas lançáveis por baixo delas. Lançar numa conta agregadora anula a hierarquia e produz um saldo que aparece num total mas em nenhuma das suas componentes, o que é das coisas mais confusas que um relatório pode fazer.

As contas transitórias precisam do mesmo desenho explícito. Mercadorias recebidas por faturar, transitória de salários, transitória intragrupo, stock em trânsito e liquidações de gateway devem ser definidas no momento em que o plano é concebido, com um saldo normal declarado e um responsável identificado, e não criadas avulso mais tarde por quem primeiro precisou de um sítio para pôr alguma coisa. As contas criadas avulso são as que nunca são revistas.

Desenhar para as demonstrações que tem de produzir

Um plano de contas deve ser concebido de trás para a frente, a partir dos resultados que tem de alimentar. Normalmente são quatro: as demonstrações financeiras legais, as contas de gestão, as declarações fiscais e o que quer que a empresa-mãe ou o financiador exijam. Cada um impõe um nível de detalhe, e o plano tem de suportar o mais fino deles.

A IAS 1 exige que certas rubricas sejam apresentadas na face das demonstrações principais e permite a agregação de itens imateriais, com mais detalhe nas notas. É um requisito de apresentação e não de plano de contas, mas gera um: qualquer rubrica que as demonstrações ou as notas tenham de divulgar separadamente tem de ser identificável separadamente no razão, seja como conta, seja como dimensão. Depreciações, gastos com benefícios dos empregados, gastos de financiamento e perdas por imparidade são exemplos comuns, e um plano que os mistura em categorias genéricas não consegue produzir a divulgação sem um exercício de análise todos os anos.

A fiscalidade acrescenta os seus próprios requisitos, e estes diferem dos contabilísticos. Os gastos não aceites fiscalmente, sendo as despesas de representação o exemplo habitual, são muito mais fáceis de identificar se tiverem sido lançados numa conta própria desde o início do que se tiverem de ser extraídos anualmente de uma conta genérica. O mesmo se aplica ao IVA não dedutível e a qualquer categoria com tratamento fiscal diferente.

O reporte de gestão costuma querer o contrário do reporte legal: menos estrutura, mais dimensões. Quer a margem bruta por linha de produto, o custo por departamento e a contribuição por loja, nada disso interessando às demonstrações legais. É precisamente por isso que a separação entre contas e dimensões é a arquitetura certa. As contas servem a visão legal, as dimensões servem a visão de gestão, e ambas vêm dos mesmos lançamentos, sem uma segunda contabilidade.

Várias entidades e consolidação

Quando um grupo tem várias entidades jurídicas, a posição mais sólida é um único plano de contas do grupo usado por todas, com contas específicas de uma entidade acrescentadas apenas onde a lei local verdadeiramente o exija. A consolidação passa então a ser uma questão de somar contas iguais e eliminar saldos intragrupo, e não um exercício de mapeamento que tem de ser mantido e reverificado em cada período.

A objeção habitual é que as entidades são diferentes, e são, mas menos do que se espera. Uma empresa comercial e uma empresa de serviços usam, em grande parte, a mesma estrutura de gastos. O que difere é quais contas usam, não o que as contas significam. Contas não usadas numa entidade não custam nada; significados de conta divergentes entre entidades custam uma reconciliação por mês e produzem números consolidados que ninguém consegue decompor.

Quando as entidades herdaram planos diferentes, e a maioria dos grupos que compram empresas herdará, a camada de mapeamento que os traduz é um passivo permanente. Tem de ser mantida sempre que qualquer dos planos muda, tem de ser verificada e é invisível no resultado consolidado, pelo que um erro nela produz um número consolidado errado de uma forma que nenhuma reconciliação de qualquer das entidades detetaria. Convergir para um plano comum é caro uma vez e mais barato daí em diante.

As contas intragrupo devem ser explícitas e emparelhadas: uma conta a receber e uma conta a pagar separadas por cada entidade contraparte, e não uma única conta intragrupo com um saldo líquido face a todas. A eliminação na consolidação depende de saber com que entidade é cada saldo, e um saldo líquido numa única conta não pode ser eliminado sem uma análise adicional que alguém tem de fazer à mão.

Como conceber um, na prática

O método é curto, e a disciplina está em segui-lo em vez de saltar diretamente para a lista de contas, que é o que costuma acontecer.

O sexto passo é o que encontra os erros de desenho, e é o mais vezes saltado, porque parece esforço duplicado. Não é. Produzir uma demonstração legal real, um pacote de gestão real e um apuramento fiscal real a partir de um mês real de transações revela, numa tarde, as três coisas sobre as quais não consegue reportar. Encontrá-las nesse momento não custa nada. Encontrá-las no quarto mês custa a mudança descrita a seguir.

• Liste primeiro os resultados: demonstrações legais, declarações fiscais, relatórios de gestão, requisitos do financiador ou da empresa-mãe. São eles que definem o detalhe mínimo.
• Identifique as dimensões. Percorra o negócio e dê nome a todas as formas como alguém vai querer fatiar um número. Cada uma é uma dimensão, a menos que altere a natureza do montante.
• Só então escreva a lista de contas, partindo da estrutura das demonstrações para baixo, e parando no nível em que uma nova divisão responderia a uma pergunta de dimensão e não a uma pergunta de natureza.
• Marque as contas de controlo e as contas agregadoras como não lançáveis, e defina deliberadamente cada conta transitória, com um estado normal e um responsável.
• Escreva as regras de lançamento: para que conta vai cada tipo de transação, porque é nesta camada de mapeamento que as pistas de auditoria realmente se perdem.
• Teste-o com o ano passado. Pegue num período de transações reais, lance-as na nova estrutura e produza os quatro resultados a partir daí.
• Ponha-o por escrito. Uma lista de contas sem um documento que diga o que pertence a cada conta será interpretada de forma diferente dentro de um ano.

Quanto custa mudá-lo mais tarde

Os planos de contas mudam, e o custo não é a mudança em si. Criar contas é trivial. O custo é tudo o que está ligado à estrutura antiga, e a maior parte disso não é visível a partir da lista de contas.

Por isso, a maioria das mudanças deve ser aditiva e não estrutural. Acrescentar uma conta, dividir uma conta em duas prospetivamente a partir do início de um exercício ou introduzir uma dimensão ao lado da estrutura existente são tudo mudanças geríveis. Renumerar todo o plano, fundir contas com histórico ou alterar o significado de uma conta existente não são, e a última é a pior, porque nada se parte visivelmente; o relatório simplesmente passa a estar errado.

O momento certo para uma mudança estrutural é o início de um exercício, de forma planeada, com a estrutura antiga e a nova documentadas, um mapeamento conservado permanentemente e o primeiro período após a mudança reconciliado nos dois sentidos. Fazê-lo a meio do ano para resolver um problema urgente de reporte produz um ano de contas que ninguém consegue comparar com nada.

• Histórico. As transações antigas estão nas contas antigas. Ou remapeia o histórico, o que altera períodos já lançados, ou aceita que os comparativos atravessam uma descontinuidade e que cada relatório ano contra ano precisa de uma ponte.
• Mapeamentos. Cada integração, cada regra de lançamento, cada regra de importação bancária, cada lançamento recorrente e cada modelo de importação referem códigos de conta e têm de ser encontrados e atualizados.
• Relatórios. Os formatos das demonstrações financeiras, os pacotes de gestão, os orçamentos, os dashboards e qualquer folha de cálculo que puxe um balancete por código deixam de funcionar, e deixam de funcionar em silêncio, omitindo uma conta nova em vez de darem erro.
• Orçamentos e previsões. Um orçamento construído na estrutura antiga não pode ser comparado com os valores reais na nova sem um mapeamento que é, ele próprio, fonte de erro.
• Pessoas. Toda a gente que classifica faturas decorou códigos, e o período de transição gera lançamentos errados que depois têm de ser corrigidos.
• Auditoria. O auditor precisa de compreender a mudança, de se assegurar de que os comparativos reexpressos são consistentes e de testar o mapeamento. É uma conversa a ter com antecedência e não no terreno.

Sinais de que o desenho está errado

A maioria das empresas não revê o seu plano de contas porque não há nenhum acontecimento que a obrigue a isso. Estes são os sinais de que lhe está a custar dinheiro, todos visíveis sem necessidade de um projeto.

Nenhum destes sinais é fatal por si só. Vários em conjunto significam que a estrutura codifica factos sobre o negócio que entretanto mudaram, e que cada relatório construído sobre ela está a suportar esse custo em silêncio.

• A mesma palavra aparece repetidamente ao longo da lista de contas, o que significa que uma dimensão está a ser transportada no código da conta.
• Uma grande parte das contas não tem transações no ano corrente, o que significa que a estrutura sobreviveu à organização que descrevia.
• Produzir o pacote de gestão exige uma folha de cálculo que mapeia contas para linhas do relatório, mantida por uma única pessoa.
• Uma conta de gastos gerais ou diversos tem um saldo material, o que significa que as pessoas não sabem onde as coisas pertencem.
• Responder a uma pergunta de rotina, como o custo por loja ou a margem por linha de produto, exige uma extração de dados e não um relatório.
• Abrir uma nova loja ou departamento é um projeto de configuração e não a adição de um valor de dimensão.
• Duas pessoas a quem se pergunta onde é lançado um determinado custo dão respostas diferentes.

Governação

Um plano de contas degrada-se através de pequenas decisões tomadas sob pressão de tempo. Alguém precisa de uma conta para um novo custo, cria uma, dá-lhe o nome do fornecedor e lança nela. Cinco anos depois há duzentas contas assim, e a estrutura concebida com cuidado foi diluída por coisas que ninguém decidiu.

O controlo é banal e eficaz: criar ou alterar uma conta exige a aprovação de uma pessoa identificada, face a uma definição escrita da estrutura, e a alteração fica registada. Esse aprovador faz uma única pergunta: a coisa nova é um tipo de montante diferente ou um contexto diferente para um montante que já existe? A maioria dos pedidos é do segundo tipo, e a resposta é um valor de dimensão e não uma conta.

O Skyline Nexus guarda a loja e o local na própria transação, e cada linha do razão liga-se ao documento que a originou, pelo que uma vista por loja é uma junção com a origem e não uma estrutura reconstruída a partir de códigos de conta. Vale a pena perguntar a qualquer sistema, incluindo este, exatamente que dimensões a LINHA do razão guarda e quais existem apenas no documento de origem: a diferença decide se um relatório por dimensão é uma leitura direta ou uma reconstrução, e se sobrevive quando um tipo de documento muda. Isto descreve o que um sistema guarda. Não decide o seu desenho, e nenhum sistema impede um plano de contas que codifique nos códigos de conta o que deveria ter sido uma dimensão.

• Um documento escrito do plano de contas que diga o que pertence a cada conta, mantido atualizado.
• Criação e alteração de contas restritas e aprovadas, com o motivo registado.
• Uma revisão anual das contas sem movimento e de qualquer conta que absorva itens diversos.
• Regras de lançamento e mapeamentos revistos sempre que um sistema de origem muda, porque é aí que as pistas se perdem.
• Valores de dimensão governados da mesma forma que as contas, porque uma lista de dimensões sem controlo torna-se a sua própria proliferação.

Uma predefinição razoável

Para uma empresa sem requisitos de reporte invulgares, a forma seguinte funciona, e só vale a pena afastar-se dela por um motivo declarado. Algumas centenas de contas, agrupadas por classificação nas demonstrações, com intervalos largos. Contas divididas apenas onde a natureza do montante difere ou onde uma divulgação legal ou fiscal o exige. Três a cinco dimensões, sendo loja ou local, departamento ou centro de custo, e projeto o conjunto habitual. Contas de controlo e agregadoras não lançáveis. Contas transitórias definidas e com responsável. E uma definição escrita do que pertence a cada sítio.

Essa estrutura produzirá demonstrações legais, um pacote de gestão fatiado de várias formas e um apuramento fiscal, a partir de um único conjunto de lançamentos e sem uma folha de cálculo de mapeamento. Sobreviverá a uma nova loja, a uma reorganização e a uma aquisição sem um projeto de reestruturação. E manterá a lista de contas suficientemente pequena para que quem classifica uma fatura encontre a conta certa, que é, no fim de contas, a restrição que determina se tudo o resto funciona.

O plano de contas é a única parte de um sistema financeiro em que uma hora de desenho poupa um ano de trabalho, e em que as consequências de errar aparecem tão devagar que ninguém as liga à causa. Se está a implementar um sistema, invista esses dias. Se já está em produção e reconhece os sintomas acima, planeie a mudança para um fim de exercício em vez de viver com ela, e torne-a aditiva sempre que puder.