Publicação: 22/03/2019
Área:Gestão e Gerenciamento de Projetos
Quero começar este artigo detalhando dois casos.
Caso 01: Um amigo meu, dono de uma pequena empresa Prestadora de Serviços Técnicos, foi contratado por uma grande empresa nacional para realizar um serviço, que, na época, tinha um valor de R$15.000,00.
O serviço foi realizado a contento e a empresa emitiu a Nota Fiscal, sendo que o pagamento iria ocorrer por Depósito Bancário, num prazo de 10 dias úteis. Ela já era fornecedora habitual desta empresa e os pagamentos sempre eram feitos assim.
Dentro deste prazo a empresa fez o pagamento de R$1,5 milhões (cem vezes o valor contratado). Esse meu amigo verificou o fato e ficou aguardando um posicionamento da empresa.
Duas semanas havia se passado e ninguém da empresa cliente (de grande porte, com um excelente ERP implantado há anos) percebeu essa falha.
Esse meu amigo notificou o erro a empresa, e percebeu, ao relatar o fato, que ninguém viu isso como um grande problema… parecia que era um “pequeno ajuste” a ser feito.
Caso 02: O Chefe Financeiro de uma pequena softhouse de ERP tirou férias, e o Diretor da empresa ficou no lugar dele.
Aproveitando a situação, esse Diretor decidiu “passar o pente fino” nas contas da empresa e descobriu vários erros acontecendo com uma certa frequência, tais como: contas sendo pagas duas vezes; contas sendo pagas atrasadas, gerando multas e juros, mesmo quando a empresa tinha dinheiro em caixa disponível; contas recorrentes importantes com interrupções de pagamento (conta não paga há meses atrás e contas recentes sendo pagas); e assim por diante.
Um ponto relevante nisso tudo é que o ERP da softhouse era muito bom, com recursos muito interessantes na Gestão Financeira, e o Diretor da softhouse, mesmo tendo um bom conhecimento sobre o assunto, com o passar do tempo, não percebeu os pontos de risco que a própria empresa dele tinha e que estava ocorrendo uma erosão de uso do ERP.
Ao ver esses dois casos conseguimos perceber alguns pontos relevantes sobre os Contas a Pagar (e quase todos os outros processos) das empresas, que são:
=> Ter um ERP bom é importante, mas não é garantia de sucesso no processo;
=> Tão importante quanto ter um bom ERP é implantá-lo adequadamente;
=> Você tem várias formas de fazer um processo acontecer com o mesmo ERP;
=> Por melhor que você tenha implantado um processo no ERP, sempre pode ocorrer erosão de uso;
=> Mesmo com tantas automações possíveis e sendo realizadas, as pessoas são fundamentais para o sucesso dos processos.
Com um grau maior ou menor de riscos, com maior ou menor volume trafegado, todas as empresas precisam executar o processo de Contas a Pagar, e, de acordo com a realidade da empresa e o ERP que ela tem, existe uma série de possibilidades de trabalho que precisam ser analisadas, escolhidas e implementadas.
Contas a Pagar é um processo que, a princípio, deveria estar plenamente dominado pelas empresas… mas, “deveria” não significa que está. Vemos muitas empresas vivendo esse processo com algum grau de risco de erro ou de dano intencional, sendo feito com práticas inadequadas e/ou com eficácia menor do que poderia ser. Vamos falar sobre isso!!!
Como Funciona Um Processo de Contas a Pagar?
Em linhas gerais, funciona da seguinte forma: uma necessidade real, planejada ou potencial de pagamento surge devido algum motivo (compras, indenizações, impostos, etc.), essa necessidade de pagamento é inserida automaticamente ou manualmente no Contas a Pagar dentro do ERP. Com base em regras de negócio estabelecidas, decisões são tomadas, tais como se vai pagar ou não uma determinada obrigação financeira, quanto vai ser pago, quando, de que forma, quem vai fazer o pagamento, em qual(quais) conta(s) (financeira, gerencial, orçamentária e/ou contábil) vai ser debitado o valor, etc. Depois disso a obrigação de pagamento pode ser encerrada ou ser tratada devido a eventuais divergências encontradas ou geradas (pelo não pagamento ou pagamento parcial).
A essência é muito simples, mas existem várias nuances que precisam ser analisadas em cada caso.
Por exemplo, numa distribuidora que só faz compra de materiais para atender às vendas previamente realizadas e pagas, o processo de Contas a Pagar é muito simples, pois, a princípio, sempre vai ter caixa disponível para atender.
Já num curso profissionalizante, que trabalha com treinamentos de parceiros, onde a remuneração do parceiro é mensal, mas os seus treinamentos são pagos em até dez parcelas e é totalmente baseado em resultados, a definição de quanto tem que ser pago é uma informação sensível e sujeito a falhas.
Em uma empresa de Consultoria, onde a equipe utiliza cartões de crédito próprios e da empresa para o pagamento das despesas do dia a dia em viagens, onde as regras mudam de acordo com cada projeto ou região geográfica, o processo de Contas a Pagar precisa ter uma etapa bem consolidada de verificação das informações e das disponíveis, sem contar que cada pagamento efetuado tem uma alocação orçamentária muito rígida.
E assim por diante, cada empresa tem características próprias para o mesmo processo de Contas a Pagar.
E Como o ERP Suporta (ou Deveria Suportar) Este Processo?
Até em empresas do mesmo segmento, encontramos no mercado muitos gestores financeiros com ideias muito diferentes de como a sua empresa deveria trabalhar com o Contas a Pagar. Às vezes eles estão bem embasados, outras vezes não. Da mesma forma encontramos ERP melhores do que outros, com recursos diversos, bons agrupamentos e possibilidades interessantes de visualização das informações, ajustes de campos e de regras. Vamos falar sobre algumas características que considero como mais relevantes.
01) Autorizações de Pagamento
A possibilidade de colocar no processo bloqueios de pagamentos conforme regras é muito interessante e nem sempre é bem explorado pelas empresas e pelos fornecedores de ERP.
Pagamentos podendo ser realizados em datas específicas e/ou variadas conforme as características da obrigação financeira ou de sua origem; autorizações de pagamento sendo realizadas por mais de uma pessoa conforme o valor a ser pago e autorizações de pagamento sendo feitas por uma ou mais pessoas específicas conforme a origem da obrigação (se veio de um determinado projeto/contrato, se está relacionada a uma determinada conta orçamentária, etc.), são as mais requisitadas.
Sem contar as situações onde obrigações estouraram limites orçamentários ou gerenciais e que precisam ter uma aprovação diferenciada para ser paga.
Entretanto, é muito comum vermos ERP somente com as funções mais básica de autorização por uma ou mais pessoas e encontramos um número razoável de sistemas com recursos de assinatura eletrônica para efetivar tais pagamentos.
Já me deparei com vários casos onde o ERP tinha alguns dos recursos descritos, mas os gestores decidiram não colocar no processo qualquer bloqueio (indiferente do valor, se está planejado e tem dinheiro no caixa o funcionário pode pagar).
02) Alocação das Obrigações a Pagar em Diversas Contas de Classificação
De uma maneira em geral, vemos empresas bem geridas chegando até a trabalhar simultaneamente as classificações de pagamentos das suas obrigações em Contas Financeiras, Contas Contábeis, Centros de Custos/Resultados, Contas Orçamentárias, Contas Gerenciais e Contas de Contratos/Projetos.
Essas empresas bem geridas utilizam todos (ou quase todos) esses controles nas suas operações, mas a grande maioria… posso estimar em mais de 50%, trabalha, no máximo com Centros de Custos/Resultados e os outros quase 50%, trabalham com dois ou três tipos de alocações simultâneas, mesmo quando os ERP oferecem mais opções de alocações.
Pode ser que a decisão de não classificar de forma detalhada os pagamentos realizados seja a mais assertiva para um determinado momento da empresa, mas isso tem um preço.
É muito comum ver esses gestores de empresas que não alocam tempo e energia do pessoal para classificar melhor os pagamentos falarem, em algum momento, que precisavam ter mais controle sobre as suas operações, que isso estava levando-os a tomarem decisões ruins, mas não sabem como fazer isso.
Também é muito comum conversar sobre o assunto com os donos de softhouses de ERP e eles falarem que não colocam esses recursos porque ninguém usa.
Para ambos quero dizer que empresas bem geridas financeiramente utilizam intensamente as classificações das obrigações, e os principais e melhores ERP de mercado disponibilizam as várias opções de classificação das obrigações. Vocês estão em algum desses grupos? Querem estar neles?
03) Pagamentos de Obrigações Com Várias Obrigações Associadas
No momento que você paga uma fatura de cartão de crédito com vários itens distintos como papelaria, passagem aérea e restaurante, ou quando você paga um boleto vinculado a uma Ordem de Compras, que foi gerada por várias Requisições de Materiais distintas e com inúmeros fins, você precisa garantir que sejam feitas as classificações certas de cada proporcionalidade de valor da obrigação paga.
Quando falamos de uma obrigação com origem no sistema (uma Ordem de Compras, por exemplo), imaginamos que o ERP já vai se encarregar de todo o processo, mas infelizmente isso não ocorre na maioria dos sistemas do mercado.
As devidas vinculações das Ordens de Compra e das Requisições de Materiais podem até ocorrer… reforço o “pode ocorrer”. Já vi várias falhas grotescas neste sentido em muitos sistemas, mas não significa que tais informações vão ser colocadas nos lançamentos das obrigações à pagar, na realidade quase nunca isso ocorre automaticamente.
Em condições ideais, os ERP tem que ter meios de fragmentar cada linha de uma obrigação com vários lançamentos e fazer os devidos controles separados e em conjunto, tendo as suas classificações sugeridas automaticamente.
Mas mesmo sem este recurso, cabe ao pessoal do Contas a Pagar fazer os lançamentos manuais associados. Sei que isso dá trabalho, mas o pior é não ter as informações para controle e para as tomadas de decisão.
04) Pagamentos de Obrigações Com Outras Complexidades Associadas
Os pagamentos de faturas de cartões de crédito são sabidamente um processo complexo (uma parte foi descrita acima), mas existem outros tipos de pagamentos que também têm as suas peculiaridades, como pagamento de boletos com split de vendas (gerando duas ou mais Notas Fiscais associadas), pagamentos associados a permutas e pagamentos com títulos públicos, ações de empresas, criptomoedas, pontos de benefícios, etc., que além de ter flutuações significativas de valores cujas as fontes podem não ter padrões rigorosos ou confiáveis, podem ter critérios de uso e necessidades mais detalhadas de classificações.
Um grupo significativo de fornecedores de ERP respondem a essas situações afirmando que tem flexibilidade na sua camada de negócio e que pode ajustar (por um simbólico valor) tudo que o cliente quiser neste sentido… VAMOS PARAR COM ISSO!!! Esse tipo de transação tem que vir nativamente no ERP. Ao gerar esse tipo de customização (mesmo que não seja feita sem programação direta na parte central do sistema ainda é um tipo de customização), você está dependendo do conhecimento dos usuários em geral sobre o assunto, que, na grande maioria dos casos, eles têm menos condições de fazer isso que os profissionais de ERP.
05) Negociações de Pagamentos
No dia a dia das empresas, várias situações podem gerar a necessidade de negociar e renegociar pagamentos, seja por problemas de qualidade dos produtos/serviços comprados, falhas no prazo de entrega, crises da empresa, inadimplência de clientes, etc., e cabe aos ERP terem recursos para administrar isso.
Não estou falando só do recurso de abrir um campo texto para registrar a negociação feita e de campos textos (ou até mesmo com links) para acionar as novas obrigações a pagar geradas com a negociação. Isso funcionava no passado.
Precisa ter uma estrutura muito melhor articulada com a garantia da rastreabilidade das obrigações de origem (e dos seus fatos geradores), aprovações de negociações de forma rápida e assertiva utilizando fluxos de controle, a capacidade de gerar simulações diretas de fluxo de caixa e ainda meios diretos para administrar juros, multas, acréscimos e glosas (descontos).
Caso o seu ERP não tenha isso, abuse dos registros de textos e tome muito cuidado com as estruturas de classificações das obrigações resultantes das negociações. Um problema muito comum é a dificuldade de classificar (nas contas contábeis e gerenciais), de forma prática, as glosas obtidas.
06) Regime de Caixa, Competência ou Gerencial… Como Ver Isso nas Obrigações a Pagar?
É impressionante a dificuldade dos gestores das empresas e dos profissionais dos fornecedores de ERP de entender, controlar e aplicar as obrigações financeiras com base no seu regime (Caixa, Competência ou Gerencial).
Somente para ilustrar vou utilizar um exemplo. Uma determinada empresa que trabalha por contrato, comprou 10 smartphones para o seu pessoal no dia 20/04. O valor da compra foi de R$10.000,00. Ela efetuou a compra por cartão de crédito corporativo e pagou em 5 parcelas sem juros, com o primeiro pagamento de R$2.000,00 em 10/05. Esses smartphones foram para o estoque da empresa, e no dia 20/08 foi alocado no contrato que solicitou a compra. No que se refere ao Caixa, terá 5 saídas mensais de R$2.000,00 cada a partir de 10/05 (foi o serviço de Cartão de Crédito que pagou inicialmente a compra e não a empresa), por Competência, a empresa teve um “gasto” (podemos chamar aqui de compromisso de gasto) de R$10.000,00 no dia 20/04, mas, no Regime Gerencial, somente em 20/08 que o contrato gerador da obrigação teve o seu “gasto”, antes disso esse “gasto” era da empresa, inclusive quando vemos esta situação de forma contábil.
Como trabalhar essas informações facilmente dentro dos ERP? Todos os ERP trabalham nativamente o Regime de Caixa, uma quantidade razoável de ERP trabalha, de alguma forma, certa ou não, com as informações da Competência, e poucos ERP trabalham com o Regime Gerencial (até mesmo os ERP que se predispõem a trabalhar com a Gestão de Contratos/Projetos).
O problema é que a grande maioria dos ERP tem dificuldades de utilizar adequadamente essas informações nas suas ferramentas de gestão, seja de forma processual ou com meios eficazes de mitigar os riscos de erros operacionais, como no Fluxo de Caixa e nos DRE (Demonstrativos de Resultados do Exercício).
Poderia ficar aqui e falar contigo sobre inúmeras outras situações dos processos de Contas a Pagar que precisam ter um tratamento mais adequado para operar com mais segurança e praticidade, mas acredito que os pontos que descrevi acima já vão ser significativos o suficiente para que seja repensado alguns valores dos seus processos e sistemas. A intenção era essa.
Quero que você entenda algumas coisas:
=> O seu ERP pode não ser perfeito no suporte do seu Contas a Pagar, mas você precisa extrair o máximo do que tem para garantir a sua melhor gestão.
=> Fique atento as erosões de uso do ERP. O fato de você ter implantado o processo adequado num certo momento, não significa que ele esteja bem agora. O Contas a Pagar costuma apresentar frequentemente este tipo de problema.
=> As pessoas falham e tem pessoas que são mal-intencionadas. Não deixe de monitorar tudo.
=> Ajude o seu fornecedor de ERP a melhorar o seu sistema de Contas a Pagar (isso serve para todos os processos). Você também vai sair ganhando com isso.
Mãos e mentes à obra!!!
Gratuito: Curso EAD de Visão Geral de ERP
Faça a Pesquisa de Temas de Aprendizado de ERP e ganhe um Paper
Gratuito: Livro Falando Sobre ERP
Gratuito: Clube do ERP (LinkedIn)
Autor: Mauro Oliveira
mauro.oliveira@espacoerp.com.br
Perfil LinkedIn
(51) 3024-0730 - info@alfamidia.com.br - Porto Alegre/RS