Uma compra pode ser autorizada corretamente e ainda resultar em pagamento divergente. O fornecedor entrega parte do pedido, envia uma cobrança com outra quantidade e a equipe financeira precisa reconstruir o contexto por mensagens. A conferência em três vias organiza a relação entre pedido, recebimento e cobrança para tornar essas divergências visíveis antes da decisão de pagar.
Este guia descreve como traduzir esse processo em software. Ele não define obrigações fiscais ou procedimentos contábeis universais. As regras de documentos, tributos e escrituração devem ser validadas pelos profissionais responsáveis. O foco é a integridade do fluxo operacional e a explicação das decisões.
1. Entenda o papel de cada documento
O pedido representa uma condição comercial aprovada. O recebimento registra o que efetivamente chegou e foi aceito. A cobrança apresenta o que o fornecedor espera receber. Nenhum dos três, sozinho, comprova toda a operação.
A documentação de conferência de faturas do Microsoft Dynamics 365 descreve a comparação de informações de pedido, recebimento e fatura, inclusive tolerâncias. Esse conceito pode orientar um sistema próprio sem obrigar a empresa a reproduzir todas as configurações de um ERP específico.
O primeiro trabalho é identificar onde esses registros existem hoje. Uma empresa pode ter pedidos aprovados em planilha, recebimentos em papel e cobranças em um ERP. Integrar exige referências comuns e responsáveis por cada etapa. Trocar a interface não resolve a ausência de vínculo entre os fatos.
2. Modele itens e recebimentos parciais
O vínculo precisa chegar ao nível em que a divergência pode ocorrer. Um pedido com dez itens não deve ser considerado integralmente recebido porque um documento menciona seu número. Quantidade, unidade e situação de cada linha precisam ser identificáveis.
Permita que uma linha de pedido tenha vários recebimentos e várias cobranças, quando o negócio exigir. Um fornecedor pode entregar em etapas e faturar separadamente. O sistema deve controlar quanto foi solicitado, aceito, devolvido, cobrado e já relacionado a uma decisão financeira.
Unidades diferentes exigem conversão explícita. Se o pedido usa caixas e a cobrança usa unidades, a comparação deve aplicar a relação aprovada para aquele item. Uma simples igualdade de números não é uma conferência válida quando as bases são diferentes.
3. Diferencie divergência de erro técnico
Uma divergência operacional significa que os fatos não correspondem à política esperada: preço diferente, quantidade acima da recebida ou encargo não previsto. Um erro técnico pode impedir a consulta ao pedido ou a importação da cobrança. A interface deve distinguir essas situações.
Sem essa separação, uma falha de integração pode parecer liberação automática por ausência de diferença. O estado correto para dados incompletos é pendente de conferência, conforme a regra da empresa, não “aprovado porque nada foi encontrado”.
| Situação | Interpretação inicial | Encaminhamento possível |
|---|---|---|
| Quantidade cobrada maior que aceita | Divergência de quantidade | Conferir entrega e cobrança |
| Preço diferente do pedido | Divergência comercial | Validar condição renegociada |
| Documento sem pedido localizado | Vínculo incompleto | Identificar compra ou exceção |
| API do recebimento indisponível | Informação não consultada | Reprocessar sem liberar por silêncio |
| Mesmo documento importado novamente | Possível repetição | Reconhecer identidade e evitar duplicidade |
4. Defina tolerâncias com responsabilidade
Uma tolerância evita que diferenças previstas interrompam a operação desnecessariamente. Entretanto, ela precisa ter escopo. Percentual, valor absoluto, categoria, fornecedor e natureza da diferença podem exigir tratamentos distintos.
Defina também a base do cálculo. Uma diferença de poucos centavos no total não deve ser comparada automaticamente com a mesma regra aplicada ao preço unitário de milhares de unidades. Documente arredondamento e precisão para que a conferência seja reproduzível.
Tolerância não significa autorização irrestrita. O sistema deve registrar qual política permitiu avançar e mostrar a diferença à pessoa responsável. Mudanças de política precisam de versão e data de vigência. Cobranças antigas não podem receber outra interpretação sem deixar rastro.
5. Desenhe a fila de exceções como trabalho real
Uma tela com cem alertas vermelhos não orienta a equipe. Cada exceção precisa de responsável, motivo, informação faltante e ação possível. Separar por fornecedor pode ajudar compras; separar por prazo pode ajudar o financeiro. A prioridade deve refletir risco e dependência, não apenas a ordem de chegada.
O analista deve conseguir solicitar correção, vincular um recebimento, apresentar renegociação documentada ou encaminhar para aprovação. O sistema não deve permitir alterar o pedido original silenciosamente para fazer os números coincidirem. Se houve mudança comercial legítima, ela precisa ser registrada como tal.
Inclua comunicação entre áreas com contexto do item e do documento. Anexos e comentários devem permanecer vinculados à exceção, respeitando acesso. Assim, uma pessoa que assume a tarefa consegue continuar a análise sem reconstruir toda a história por telefone.
6. Exemplo: entrega parcial e cobrança integral
Considere um pedido hipotético de trinta unidades a R$ 50 cada. A empresa recebe e aceita vinte. O fornecedor cobra trinta. A diferença não prova fraude nem autoriza pagar automaticamente. Ela indica que a cobrança precisa de uma decisão baseada na condição comercial e no recebimento registrado.
O sistema pode apresentar vinte unidades recebidas, dez ainda esperadas e a cobrança integral. A equipe decide se exige correção, se há condição contratual que admite antecipação ou se o recebimento está incompleto no sistema. Cada alternativa possui evidência e autoridade próprias.
Se as dez unidades restantes chegam depois, o novo evento atualiza a situação da conferência. O histórico deve mostrar que a cobrança esteve pendente e por que foi liberada posteriormente. Não é necessário apagar a divergência passada para indicar que o problema foi resolvido.
7. Separe conferência, aprovação e pagamento
Conferir documentos não equivale a executar uma transferência. A conferência reúne informações e aplica regras. A aprovação representa uma decisão. O pagamento utiliza outro fluxo, com permissões e controles apropriados.
Uma arquitetura pode publicar a situação da cobrança para o financeiro, com referência à versão aprovada. Se algo mudar depois, a atualização precisa ser conhecida antes de uma execução irreversível. Defina como cancelamentos, devoluções e correções afetam decisões já tomadas.
Mesmo quando uma integração automatiza etapas, preserve a separação de autoridade. Credenciais de consulta não precisam autorizar pagamentos. Um serviço que importa documentos não deve ganhar, por conveniência, permissão para alterar dados bancários ou remover aprovações.
8. Trate identidade e repetição nas integrações
Documentos podem chegar por importação, e-mail e API. Estabeleça critérios de identidade e verifique repetições antes de criar obrigações duplicadas. Não dependa somente do nome do arquivo, que pode mudar sem alterar o conteúdo operacional.
Guarde a origem e a referência externa. Se uma mensagem for reenviada após um timeout, o sistema deve reconhecer o estado já conhecido. Se houver conteúdo diferente com a mesma identidade, trate como conflito a investigar. Essa distinção é desenvolvida no Laboratório A2CR.
Falhas de extração automática também precisam de revisão. Um valor lido de um PDF não é um fato validado apenas porque foi identificado por OCR ou IA. Mostre a referência de origem e permita conferência antes de produzir decisões comerciais.
9. Indicadores e testes de implantação
Meça quantidade de exceções por causa, tempo de tratamento, documentos sem vínculo e reincidência por origem. Não avalie o processo apenas pela velocidade de liberação. Uma fila rápida que ignora divergências não representa uma operação melhor.
Teste pedidos com múltiplas entregas, cobranças parciais, devoluções, unidades diferentes e correções posteriores. Inclua indisponibilidade de sistemas externos e duas pessoas trabalhando na mesma exceção. O estado final deve ser explicável, com documentos e decisões associados.
Checklist de implantação
- Identificar fontes de pedido, recebimento e cobrança.
- Vincular documentos no nível de item necessário.
- Tratar entregas, cobranças e devoluções parciais.
- Documentar conversões de unidade e arredondamento.
- Definir tolerâncias e versões de política.
- Diferenciar divergência operacional e falha técnica.
- Criar fila de exceções com responsáveis e ações.
- Separar conferência, aprovação e pagamento.
- Impedir duplicidade na importação de documentos.
- Testar correções após aprovação e antes da execução.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre a conferência, o responsável e as observações da implantação.
Perguntas frequentes
Toda cobrança precisa de pedido de compra?
A empresa pode ter exceções legítimas, como certas despesas recorrentes. Elas devem ter fluxo e evidências próprios. Criar pedidos fictícios apenas para satisfazer uma tela reduz a confiabilidade do controle.
A conferência pode ser totalmente automática?
Casos com dados completos e regras estáveis podem avançar automaticamente até o limite autorizado. Divergências, informações ausentes e mudanças relevantes precisam de tratamento definido. Automação não elimina a necessidade de uma fila de exceções.
Preciso substituir o ERP atual?
Nem sempre. Uma camada de integração pode organizar vínculos e decisões utilizando dados dos sistemas existentes. A viabilidade depende de acesso, qualidade das informações e limites das APIs disponíveis.
Para avaliar esse fluxo, prepare um briefing com um pedido real anonimizado, um recebimento e uma cobrança que hoje exigem conferência manual. A A2CR pode mapear o processo antes de propor a implementação.
Autoria: Agência A2CR. Preparação editorial: 12 de novembro de 2026. Exemplos hipotéticos; desenho operacional e técnico, sem orientação fiscal ou autorização de pagamentos.
