Conciliar nada mais é que comparar duas bases distintas, garantindo exatidão dos números apresentados ao fisco e aos acionistas.

Mas como fazer essa comparação de maneira eficiente, minimizando multas fiscais, fraudes e erros?

Tendo em vista que a contabilidade é a principal provedora de informações para governo e gestores, uma conciliação eficiente do Balanço Patrimonial garante a ACURÁCIA dos números apresentados.

Porém, para conferir os valores contábeis, é necessário que os setores (financeiro, estoque, fiscal, folha, jurídico, produção, etc) forneçam relatórios de suporte CONSISTENTES!

O post de hoje aborda exatamente isso.

Um manual prático e didático para garantir informação 100% CORRETA na sua organização, tanto na origem (relatório auxiliar de suporte), quanto no destino (contabilidade).

Um abraço e boa leitura.

Lucas


Sabemos que a conciliar nada mais do que comparar duas informações – no nível mais detalhado possível.

Veja por exemplo o processo de conciliação contábil do contas a pagar e receber. O objetivo, neste caso, é a comparação entre o valor do balancete (módulo contábil) e o valor na origem (módulo financeiro). Da seguinte forma:

Figura 1: Conciliação Interna ERP (entre módulos)

Para que a conciliação contábil seja efetiva, no entanto, é imprescindível que a informação no módulo origem esteja CORRETA.

No exemplo acima, caso a base do financeiro não seja confiável, será necessário buscar uma terceira fonte de comparação, validando o saldo a pagar do seu ERP, com o saldo a receber do seu próprio fornecedor.

Esta validação é chamada de circularização de fornecedores e clientes. Veja:

Figura 2: Circularização (comparação com base externa)

Ocorre que a circularização tal qual praticada pelas empresas de auditoria atualmente, ainda é um processo extremamente manual, com baixa taxa de retorno e assertividade, que só será resolvida com a disseminação da tecnologia BLOCKCHAIN – o que, aliás, é assunto tratado neste outro post aqui.

Voltemos então ao ponto inicial: como conciliar os valores internamente, dentro do próprio sistema de gestão?

Enumeramos abaixo alguns pontos para responder essa pergunta:

PONTO 1: Saldo Histórico x Saldo Último Lançamento

Por definição, os saldos patrimoniais (na contabilidade) são históricos. Ou seja, representam a soma de todos movimentos, desde a criação da empresa.

Ocorre que diversos ERPs não calculam o saldo histórico em tempo de execução.

Observe o seguinte exemplo: Uma empresa emitindo 100.000 notas fiscais por dia, cada uma parcelada em 10 vezes, tem 1.000.000 de títulos/parcelas/dia, correto?

Vocês já pensaram como seria o processamento do saldo histórico (desde a criação da empresa) a cada emissão de um novo relatório?

Justamente por este motivo, os ERPs trabalham com o conceito de “Saldo do Último Lançamento”.

Da seguinte forma: a cada novo registro (entrada, saída, transferência, renegociação, etc) o sistema grava o saldo a pagar (ou a receber) daquele movimento.

Tal prática pode ser observada nos seguintes ERPs:

ERPContas a Pagar
(tabela.campo)
Contas Receber
(tabela.campo)
Senior Gestão Empresarial
(Sapiens)
E501TCP.VlrAbeE301TCR.VlrAbe
Totvs (Protheus)SE2.E2_SaldoSE1.E1_Saldo
Totvs (RM)FLAN.SaldoFLAN.Saldo

Trabalhando desta maneira, caso o usuário solicite em Outubro/2020 um relatório do saldo em MAIO/2020, ao invés de:

Figura 3: Saldo Histórico

os ERPs calculam o saldo de qualquer data base, subtraindo (ou somando) ao saldo atual a movimentação do período. Da seguinte forma:

Figura 4: Saldo Último Lançamento

É justamente este processamento, embora mais rápido, que causa as diferenças na conciliação.

Afinal, como o ERP é um sistema transacional, onde os valores são dinâmicos e mudam a todo momento – é comum haver ruptura entre a movimentação histórica e o último lançamento – este último, uma fotografia estática.

Surge, portanto, a dúvida: Qual é o valor correto? O Saldo Histórico ou o Saldo do Último Lançamento?

Como regra geral, o saldo histórico é o valor correto.

Por um motivo simples: ele retrata efetivamente a soma de todos os movimentos da empresa desde o início de suas atividades.

Porém, é inviável para o ERP atualizar o saldo histórico on line.

Justamente por este motivo que a BSUITE calcula o valor histórico comparando-o com o último lançamento, e disponibiliza essa informação na Conciliação do Módulo Financeiro.

Afinal, para a BSUITE, tão importante quanto a conciliação contábil (que compara financeiro x contabilidade), é a conciliação do financeiro em si, que corrige as inconsistências lá na origem, de tal maneira que a área de finanças se responsabilize pelas suas próprias informações antes de enviar os relatórios de suporte para o setor contábil.

Da seguinte forma:

Figura 5: Repare que há uma diferença interna no próprio módulo financeiro que deve ser sanada antes de iniciar o processo de conciliação contábil em si.

Uma vez identificado o problema, como resolvê-lo?

Para corrigir o erro da Figura 5 acima, os ERPs disponibilizam uma rotina chamada “Refaz Cálculos” ou “Recalcula Acumulado” ou “Concilia Saldos” justamente para atualizar o “Último Lançamento”, corrigindo assim a diferença entre R$1,5MM e R$1,4MM.

A correção deste problema, aliás, não é de responsabilidade da contabilidade (e sim do financeiro!)

Vale ressaltar, no entanto, que essas rotinas de recálculo devem ser utilizadas com o devido acompanhamento técnico, pois o uso incorreto poderá afetar todos os valores da área financeira – inclusive saldos já conciliados.

Uma vez sanadas as diferenças entre saldo histórico e último lançamento, surge então o segundo ponto que gera grandes diferenças: impostos.

PONTO 2: Impostos retidos na fonte

Alguns impostos RF são devidos pela competência. Outros, pelo regime de caixa. Essa diferença, caso não haja consenso entre a área financeira e contábil, é outro ponto de grande transtorno para a conciliação dos valores do seu ERP.

Os exemplos mais comuns são o IRRF (competência) e o PCC RF (caixa). Mas também é comum ocorrer em outros impostos.

Tomemos como exemplo então o ISS RF. Sabe-se que é exigida a retenção na fonte de alguns prestadores de serviço, correto?

Porém, dependendo da legislação de cada prefeitura, o valor é devido somente no ato do pagamento ao fornecedor (regime de caixa).

Desta forma em uma Nota Fiscal no valor de R$ 12.000,00 (com 5% de ISS retido) emitida na Competência Janeiro, com pagamento em duas parcelas (30/60), a prefeitura só fará jus ao valor retido em Fevereiro e Março.

Pensando na gestão do fluxo de caixa, é comum a área financeira visualizar os valores a pagar (e a receber) já líquido de impostos – desde a emissão da nota fiscal. Da seguinte forma:

Data BaseRelatório da área financeira
31/01
(Emissão)
Saldo a pagar para o fornecedor: 11.400,00
Saldo a pagar para a prefeitura: 600,00

Já a área contábil controla o contas a pagar pelo valor bruto (afinal, pela norma fiscal, o ISS RF só é devido após o pagamento da NF). Da seguinte forma:

Data BaseRelatório da área contábil
31/01 (Emissão)Saldo a pagar para o fornecedor: 12.000,00
Saldo a pagar para a prefeitura: 0,00
(o ISS RF permanece somado no contas a pagar e só será transferido para ISS RF a pagar quando do pagamento da NF)

Ao comparar os valores acima, observa-se:

  • Na área contábil o saldo é de R$ 12.000,00 (valor bruto, com o ISS embutido)
  • Para o financeiro, o valor é R$ 11.400,00 (valor líquido a pagar, sem ISS)

É uma diferença de critério, onde um setor apropria os impostos pelo regime de competência e o outro, pelo caixa.

Como solucionar este impasse entre financeiro e contábil?

Em  primeiro lugar, é legítimo ao financeiro controlar seus valores pelo líquido (a pagar ou a receber). Na contabilidade, também é correto apropriar as retenções pelo regime de caixa (controlando o saldo a pagar e receber pelo bruto).

Além disso, é compreensível a dificuldade do ERP em gerenciar este tipo de situação, haja vista que cada empresa possui um critério de diferente, sem contar, claro, a infinidade de combinações e parâmetros do fisco brasileiro.

Justamente pelos motivos acima, é que a BSUITE introduziu o conceito de “Análise das Variações” no processo de conciliação.

Herdada da análise de desempenho empresarial, nas duas variações mais conhecidas “efeito mix de venda” e o “efeito volume”, procura-se responder à seguinte pergunta: “qual seria o meu lucro hipotético, ao considerar no cenário realizado o mix orçado”.

Trata-se, portanto, de uma simulação “What If”, correto?

É justamente esta mesma análise o BSUITE faz, ajustando o financeiro à contabilidade. Da seguinte forma:

“E se eu retirar o PCC RF do saldo a receber? Qual o novo saldo ? ”

“E se eu voltar com ISS RF para o saldo a pagar? Qual o novo saldo? ”

“E se desconsiderar o IRRF? Qual o novo valor?”

Com este artifício, a contabilidade fica com o saldo idêntico ao financeiro, possibilitando, finalmente, a conciliação das duas bases, conforme observado nestes painéis de conciliação contábil da BSUITE.

PONTO 3: Processos internos

a) Baixa antes da emissão

Em qualquer situação, é condição de existência: primeiro lançar o título para, em seguida baixá-lo. Afinal não tem como baixar algo que ainda não exista no sistema.

Com essa premissa em mente, não deveria ser possível lançar um documento em 05/Out e baixá-lo em 30/Set, correto?

Mas este tipo de situação é muito comum em diversos ERPs. Veja:

Figura 6: Data da Baixa anterior à Emissão

Afinal, qual problema que isso pode gerar?

Primeiramente é um erro qualitativo (e não quantitativo).

Diferentemente dos casos anteriores, a baixa antes da emissão não gera divergências de valores entre a contabilidade e o financeiro. Ou seja, quantitativamente, o número é o mesmo.

Os erros portanto são qualitativos, tal como explicado a serguir:

O primeiro: ao baixar uma Nota Fiscal (antes da sua emissão) a conta de fornecedores a pagar por exemplo, fica devedora, o que não pode ocorrer pelos critérios contábeis.

O segundo erro: uma conta de fornecedores a pagar virada pode ser indício de pagamentos em duplicidade – o que deve ser tratado com a urgência e a gravidade que o assunto requer.

PONTO 4: Erros de customização

Sabemos que os ERPs modernos permitem diversas APIs, não é mesmo?

a) Tomemos como exemplo os registros inseridos no TOTVS PROTHEUS via integração EIC (Easy Import Control).

Conforme demonstrado na figura 7 abaixo, sabe-se que o campo E2_VLCRUZ é o valor na moeda corrente (normalmente real).

Logo, se o lançamento é feito em outra moeda, obrigatoriamente deve haver:

E2_VALOR (na moeda original), E2_VLCRUZ (na moeda corrente) e E2_TXMOEDA, identificando a taxa utilizada para conversão entre as duas moedas.

Porém, como se trata de integração externa (outro sistema), a regra acima foi quebrada. Tal como evidenciado abaixo:

Figura 7: Erro de Integração (conversão de moeda)

b) Outro caso – também de integração via EIC – pode ser demonstrado pela figura 8.

Observe que o saldo a pagar é zero. Mas como pode não haver saldo a pagar (SE2) se não houve nenhuma movimentação de baixa (SE5)?

Figura 8: Erro de Integração via EIC (saldo a pagar)

NOTAS DO AUTOR:

Nota 01: Estas são apenas algumas observações realizadas durante a implantação do BSUITE em diversas empresas que utilizam TOTVS (PROTHEUS, RM ou DATASUL), SENIOR (SAPIENS), MEGA SISTEMAS ou SANKHYA, visando sobretudo, orientar clientes e consultores durante o processo de conciliação e auditoria de dados.

Nota 02: O texto acima é constantemente modificado a nosso exclusivo critério, conforme novas constatações de milhões de registros diariamente, não sendo portanto nenhuma crítica à qualidade dos softwares ERPs citados ao longo do texto.

Mais informações em www.bsuite.com.br

Leave a Reply

Your email address will not be published. Required fields are marked *