FALANDO SOBRE…

CONTAS A PAGAR E OS ERP

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 haviam 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.

41
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

42
informações 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 nem tanto. 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.

43
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 pode ter um preço a ser pago.
É 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

44
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 a customização
necessária (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,
gerando a nota fiscal no mesmo dia. 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

45
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” (que neste caso é um custo não financeiro de apropriação) de uma taxa
definida de R$1,50/dia, de cada celular. Antes disso esse “gasto” (que se refere a
depreciação do ativo) 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.

46
47