Portão de limite de crédito para pedidos B2B e termos de pagamento por cliente

O que um portão de limite de crédito resolve (em linguagem simples)

Pedidos B2B podem parecer saudáveis no papel e ainda assim causar aperto de caixa. Ao contrário de pagamentos com cartão, muitos clientes empresariais pagam depois. Se você continua enviando enquanto faturas se acumulam, um pagador lento pode prender silenciosamente uma grande parte do seu capital de giro.

Um portão de limite de crédito é uma verificação de segurança simples antes que um pedido seja totalmente aceito. Ele compara o que o cliente já deve (e o que está prestes a dever) com um limite de crédito acordado. Se o novo pedido os colocaria acima do limite, o sistema não rejeita o pedido para sempre. Ele pausa o pedido para revisão.

Manter um pedido em espera geralmente significa que o pedido é registrado, mas etapas chave ficam bloqueadas até que alguém o libere. Você ainda pode confirmar detalhes com o comprador, e pode reservar estoque se essa for sua política. O que normalmente não se faz é enviar, faturar ou alocar estoque permanentemente até que a retenção seja liberada.

Os termos de pagamento mudam o risco porque alteram por quanto tempo seu dinheiro fica preso. Pré-pagamento é baixo risco porque o caixa entra primeiro. Net 30 pode ser aceitável se os gastos ficarem dentro do limite e as faturas forem pagas no prazo. Net 60 (ou termos personalizados) aumenta a exposição por mais tempo.

Um portão também reduz confusão entre equipes porque transforma “podemos enviar isto?” em um status visível e consistente para vendas, financeiro e operações.

Defina o que você armazena por cliente (limites, termos, exposição)

O portão só funciona se o registro do cliente contiver alguns campos em que sua regra de backend possa confiar. Mantenha a lista curta e faça cada valor fácil de explicar.

Comece pelo limite de crédito: o valor do limite e a moeda em que ele está definido. Se você vende em várias moedas, escolha uma regra e mantenha-a. Ou converta tudo para uma moeda base antes de comparar, ou armazene limites por moeda.

Em seguida, armazene os termos de pagamento como dados estruturados, não como texto livre. Use um tipo claro (Pré-pagamento, COD, Net 15, Net 30, Net 60) e guarde o número de dias net quando relevante. Assim sua lógica de pedidos pode ramificar sem adivinhações.

Um conjunto prático por cliente parece com:

• Valor do limite de crédito e moeda
• Tipo de termos de pagamento e dias net (se relevante)
• Um valor de override temporário (opcional) com timestamp de expiração
• Uma nota de override (por que foi concedido e por quem)
• Um interruptor manual de retenção (um botão de “stop”)

Defina “exposição” de um modo que corresponda à forma como você realmente assume risco. Muitas equipes incluem faturas não pagas mais pedidos em aberto que não foram pagos, e às vezes envios pendentes se você fatura após o envio.

Por fim, mantenha um pequeno conjunto de status de pedido para que retenções sejam visíveis e acionáveis. Por exemplo: Approved, On hold, Released, Cancelled.

Modelo de dados necessário para limites, termos e retenções de pedidos

Seu modelo de dados deve facilitar responder três perguntas: quem está comprando, em quais termos e quanto eles já devem.

Comece com um registro de Customer que carregue as entradas de decisão: limite de crédito, termos de pagamento padrão e uma política de retenção (por exemplo, auto-hold quando acima do limite, permitir mas sinalizar, ou bloquear checkout).

Os pedidos devem capturar tanto o gatilho quanto o resultado. Armazene o método de pagamento, o total do pedido e um status que possa representar “On hold” sem sobrecarregar “Pending”. Adicione um motivo de retenção para que as pessoas consigam distinguir “excedeu limite de crédito” de outras questões (como verificação de endereço).

Um esquema mínimo costuma incluir:

• Customers: credit_limit, payment_terms_code, hold_policy, credit_status
• Orders: total_amount, payment_method, status, hold_reason, held_at
• Invoices / AR: invoice_total, open_balance, due_date, status (open/paid/void)
• Credit overrides: customer_id, override_amount_or_limit, expires_at, approved_by
• Audit log: entity_type, entity_id, changed_fields, changed_by, changed_at, note

Para calcular exposição de forma confiável, você precisa de dados de contas a receber (faturas ou uma sincronização externa) para que saldos não pagos não sejam estimados a partir de pedidos. Se você ainda não tem faturamento, armazene um snapshot de “open balance” no cliente e atualize-o a partir de pagamentos lançados.

Mantenha overrides em uma tabela separada. Isso evita edições confusas no limite principal e fornece uma trilha de aprovação.

Como calcular exposição de crédito e crédito disponível

A matemática precisa ser combinada e documentada, depois usada consistentemente pelo app e relatórios do financeiro.

Uma linha de base comum é:

Exposição de crédito = faturas não pagas + valor de pedidos em aberto

Então:

Crédito disponível = limite de crédito - exposição de crédito

Antes de implementar, defina o que “valor” significa. Muitas equipes usam os totais dos produtos menos descontos e depois decidem explicitamente se incluem impostos e frete. Se incluir impostos e frete, as retenções disparam mais cedo. Se excluí-los, você corre o risco de aprovar pedidos que passam do limite quando a fatura é finalizada.

Alguns ajustes evitam surpresas:

• Pagamentos parciais reduzem faturas não pagas somente quando o caixa é realmente recebido (não quando um pagamento é “iniciado”).
• Notas de crédito e reembolsos reduzem exposição somente quando emitidos e aprovados para uso.
• Pedidos cancelados devem sair do valor de pedidos em aberto imediatamente.
• Devoluções normalmente reduzem exposição após a nota de crédito ser aprovada, não quando a devolução é solicitada.

O tempo importa tanto quanto a fórmula. Escolha pontos claros de atualização para que os números sejam previsíveis:

• Na criação do pedido ou na aprovação do pedido (escolha um e seja consistente)
• Na emissão da fatura (mova o valor de pedidos em aberto para faturas não pagas)
• No lançamento do pagamento (libere exposição)

Se você vende em múltiplas moedas, converta a exposição para a moeda de crédito do cliente usando uma taxa consistente (por exemplo, a taxa diária na data da fatura). Se você suporta contas parent ou subsidiárias, decida se os limites são por entidade legal ou compartilhados pelo grupo, e deixe isso visível no registro do cliente.

Passo a passo: construa a regra de backend que retém pedidos

O portão funciona melhor quando roda automaticamente toda vez que um pedido é criado ou alterado.

1. Salve o pedido como rascunho primeiro, mesmo que o comprador o envie em um clique. Capture o ID do cliente, o total do pedido, a moeda e um snapshot dos termos de pagamento para que edições posteriores no perfil do cliente não reescrevam o histórico.

2. Busque a exposição atual do cliente (com base na sua definição). Calcule a exposição projetada somando o novo total do pedido.

3. Aplique uma decisão simples:

• Se a exposição projetada estiver dentro do limite de crédito, marque o pedido como Approved.
• Se a exposição projetada exceder o limite, defina o pedido como On hold.

4. Ao reter o pedido, registre detalhes que facilitem explicar a decisão depois:

• Motivo da retenção (por exemplo, “Credit limit exceeded by $2,450”)
• Próximo responsável pela ação (por exemplo, “AR team” ou um gerente específico)
• Um registro de auditoria com as entradas usadas (limite no momento, componentes da exposição, quem acionou a verificação, timestamp)

5. Reavalie a exposição nos eventos que mudam os números, não apenas na criação. Gatilhos comuns são edições que alteram totais, expedição (se sua política considerar expedição como compromisso), faturamento e lançamento de pagamento.

Aprovações e notificações para que pedidos retidos não fiquem presos

Uma retenção só é útil se levar a uma decisão rápida e rastreável.

Defina quem pode liberar uma retenção. Muitas equipes usam financeiro para decisões de crédito e um gerente de vendas como backup para casos urgentes. Deixe isso explícito com papéis e permissões, e registre sempre quem aprovou (ou rejeitou) e por quê.

O que mostrar na tela de aprovação

Mantenha a tela curta, mas inclua os números que um aprovador precisa:

• Limite de crédito, exposição atual, crédito disponível
• Total do pedido e quanto acima do limite isso representa
• Termos de pagamento no arquivo e termos solicitados (se diferentes)
• Um pequeno conjunto de notas de status do cliente (por exemplo, “conta nova” ou “uma vez em atraso”)
• Um campo de comentário obrigatório

Após a decisão, registre uma entrada de log de aprovação (ID do pedido, decisão, aprovador, timestamp, comentário). Isso vira a trilha de auditoria e ajuda a explicar atrasos.

Notificações e prazos

Notifique as pessoas certas no momento em que um pedido for retido, usando canais que sua equipe realmente lê (email, SMS ou Telegram). Adicione lembretes e escalonamentos para que retenções não fiquem silenciosas. Um padrão prático é um lembrete após 2 horas, escalonamento após 24 horas e cancelamento automático após 72 horas se ninguém revisar.

Se uma liberação total for muito arriscada, permita liberações condicionais (envio parcial, depósito obrigatório, termos de pagamento mais curtos) e registre a condição para que cumprimento e faturamento sigam o mesmo plano.

Acompanhe algumas métricas para manter o portão saudável: número de pedidos retidos, percentual liberado em 24 horas, tempo médio para liberação e principais motivos de retenção.

Fluxo operacional: o que acontece depois que um pedido é retido

Trate um pedido retido como um pedido normal com uma diferença clara: ele não pode avançar até que a retenção seja resolvida.

Vendas, operações e financeiro devem ver todos o mesmo sinal de retenção. Use um status como “On credit hold” mais um campo de motivo (por exemplo, “Exposure exceeds limit by $1,240”). Adicione uma nota interna curta para que as pessoas não tenham que adivinhar.

As regras do armazém devem ser estritas: pedidos em retenção não são separados, embalados ou alocados. Se você reservar estoque, reserve-o somente após a liberação, ou use uma janela curta de reserva para que um pedido retido não bloqueie pedidos pagos.

Para a comunicação com o cliente, mantenha a mensagem neutra e prática, com um próximo passo claro. Por exemplo:

• “Seu pedido está temporariamente pausado para uma revisão de conta de rotina. Responda para confirmar o cronograma de pagamento ou solicite um envio parcial.”
• “Podemos enviar assim que o pagamento for recebido ou o limite de crédito for ajustado. Qual opção funciona melhor?”
• “Podemos dividir o pedido e enviar os itens que cabem no seu crédito disponível.”

Quando o pagamento chega, escolha entre liberação automática e manual. A liberação automática funciona bem quando pagamentos correspondem de forma confiável às faturas. A liberação manual é mais segura quando os pagamentos são parciais ou pouco claros. Um compromisso comum é liberação automática somente quando o pagamento cobre totalmente o saldo vencido; caso contrário, encaminhe para financeiro.

Cenário de exemplo: um pedido atacadista que excede o limite

Um cliente atacadista, BrightSide Supplies, tem termos Net 30 e um limite de crédito de 50.000.

Suas faturas não pagas totalizam 38.000. Eles fazem um novo pedido de 15.000.

A exposição projetada é 38.000 + 15.000 = 53.000. Como 53.000 está acima do limite de 50.000, o pedido é colocado em retenção e encaminhado ao financeiro para revisão. Vendas ainda pode ver o pedido, mas ele não pode ser embalado, enviado ou faturado até que o risco seja reduzido.

O financeiro normalmente tem algumas opções: solicitar um depósito para que a exposição caia abaixo do limite, reduzir o pedido para caber no crédito disponível, ou aprovar um override temporário com data de expiração e uma nota de motivo.

Checklist rápido antes de ativar

Antes de habilitar o portão em produção, faça um curto teste pré-implantação. Algumas horas de testes podem economizar dias de limpeza depois.

Comece com um conjunto pequeno e variado de testes (5 a 10 clientes): um com Net 30 e limite baixo, um com limite alto, um pré-pago, um com várias faturas abertas e um que frequentemente edita pedidos após o checkout.

Verifique duas coisas:

• A matemática da exposição bate com o que a contabilidade espera (incluindo o que você conta e o que não conta).
• A regra de retenção roda nos momentos corretos: criação do pedido e qualquer edição que aumente a exposição (mudança de quantidade, alteração de preço, adição de frete, remoção de desconto).

Percorra um pedido retido de ponta a ponta e confirme que o motivo da retenção é claro, que envio e faturamento se comportam exatamente como pretendido, que notificações chegam às pessoas corretas e que uma reversão de pagamento pode reter novamente (ou sinalizar) com segurança.

Erros comuns e como evitá-los

A maioria dos problemas não é técnica. Acontecem quando a regra verifica o número errado ou quando as pessoas aprendem a contorná-la.

Pontos de falha comuns:

• Tratar o total bruto do pedido como “exposição” em vez de valores não pagos e compromissados.
• Ignorar pedidos aprovados que ainda não foram expedidos, permitindo que clientes façam vários pedidos grandes em um dia antes de existir qualquer fatura.
• Permitir edições que mudem dinheiro após aprovação sem reexecutar a verificação de crédito.
• Permitir overrides sem trilha de auditoria clara.
• Adicionar tantas exceções que o portão se torna opcional.

Mantenha a prevenção simples: defina exposição em uma frase, reexecute o portão em qualquer edição que mude dinheiro, exija motivo e aprovador para overrides e mantenha os tipos de exceção curtos.

Próximos passos: implemente o portão no seu app de pedidos e itere

Comece com a menor versão que previne risco real: “Se a exposição após este pedido exceder o limite do cliente, defina o pedido como On hold.” Rode por uma semana e depois adicione exceções somente quando você puder nomeá-las claramente (por exemplo, overrides temporários aprovados pelo financeiro).

Se você está construindo o app de pedidos sem codificação manual, AppMaster (appmaster.io) pode ser uma opção prática: você pode modelar clientes, pedidos, faturas e overrides visualmente e então implementar a lógica de retenção como um processo de backend que recalcula a exposição na criação, edição, faturamento e pagamentos.

Mantenha a primeira versão entediante e previsível. Melhore-a com base no que financeiro e operações realmente veem todo dia.