Automação da conciliação três-vias: tabelas e fluxo para retenções em AP

Qual problema a conciliação três-vias realmente resolve

A automação da conciliação três-vias é simples: você paga uma fatura apenas quando ela bate com o que você pediu e com o que realmente recebeu. Os três documentos são o pedido de compra (PO), o registro de recebimento (receipt) e a fatura do fornecedor.

Sem essa verificação, contas a pagar podem acabar pagando com base em um único documento incorreto ou incompleto. Um fornecedor pode faturar mais unidades do que foram entregues, aplicar um preço diferente do acordado ou enviar uma fatura duplicada que parece nova em um thread de e-mail.

Essas falhas raramente parecem dramáticas no primeiro dia. Aparecem como pequenos vazamentos: um item cobrado duas vezes, uma remessa com algumas unidades a menos, um aumento de preço sem aprovação ou frete adicionado quando não deveria. Com o tempo, esses pequenos erros viram dinheiro real.

O objetivo não é “aprovar faturas”. O objetivo é bloquear o pagamento até que os campos-chave que você escolher (normalmente quantidade, preço unitário e totais) coincidam entre PO, recebimento e fatura. Quando eles não coincidem, a fatura não deve desaparecer no e-mail. Deve cair em uma fila de exceções com um código de motivo claro e os campos exatos que diferem.

A conciliação três-vias também traça uma linha clara entre equipes. Compras (Procurement) é responsável pelo que foi pedido (termos e preço). Recebimento confirma o que chegou (quantidades e datas). Finanças controla o que é pago (revisão e liberação da fatura).

Defina expectativas cedo: isto é um problema de processo mais dados, não apenas um botão de aprovação. Se as linhas do PO são vagas, os recebimentos não são registrados ou as faturas não conseguem ser vinculadas a uma linha de PO, a automação não vai salvar você.

Documentos e papéis: PO, recebimento, fatura e quem é responsável por cada um

A conciliação três-vias funciona apenas quando cada documento tem um dono claro. Se “quem atualiza o quê” for vago, o sistema ou bloqueia pagamentos válidos ou deixa passar pagamentos errados.

Um modelo prático de responsabilidades é:

• Requisitante cria a solicitação de compra e confirma a necessidade.
• Procurement cria e mantém o PO (fornecedor, preço, termos).
• Armazém/recebedor (ou o responsável pelo serviço) contabiliza o recebimento ou aceitação.
• AP/Finanças registra a fatura e controla o pagamento.

Cada documento também precisa de um conjunto mínimo de campos para que a conciliação não seja um palpite.

PO (purchase order) precisa de supplier ID, número do PO, linhas de item (SKU ou serviço), quantidade pedida, preço unitário, moeda, regras de imposto e termos de pagamento.

Receipt precisa de referência ao PO, data do recebimento, quantidades recebidas por linha do PO e quem recebeu. Para serviços, trate como aceitação e registre o aprovador.

Invoice precisa de número da fatura do fornecedor, data da fatura, referência ao PO (ou uma forma segura de encontrar o PO), detalhes das linhas (qty, preço unitário), impostos/frete e o total.

Também decida quando a conciliação é executada. Não deve ser um evento único. Dispare sempre que a realidade mudar:

1. Quando uma fatura é capturada (para decidir pagar ou reter imediatamente).
2. Quando um recebimento é postado (para que uma fatura em hold possa se tornar pagável).
3. Quando um PO é alterado (para que faturas em aberto sejam rechecadas).

Recebimentos parciais e múltiplas faturas são normais. Uma linha de PO pode chegar em três entregas e ser faturada em duas faturas. Sua lógica deve comparar recebido acumulado vs faturado acumulado por linha de PO, não apenas um documento por vez.

Regras a decidir antes de construir qualquer coisa

Antes de tocar nas tabelas ou passos do fluxo, concorde sobre as regras que vão dirigir todo o sistema. Regras vagas criam falhas previsíveis: ou o sistema bloqueia demais (e as pessoas o burlam), ou bloqueia de menos (e faturas ruins ainda são pagas).

Escolha o nível de correspondência. Conciliação apenas no cabeçalho verifica totais no nível do documento. Parece mais fácil, mas quebra rápido com entregas parciais, pedidos em atraso, linhas de frete ou taxas de imposto misturadas. Conciliação por linha demora mais para configurar, mas é o padrão mais seguro porque você compara a mesma coisa entre PO, recebimento e fatura: a linha específica, sua quantidade e seu preço unitário.

Defina bloqueios rígidos vs avisos. Um bloqueio rígido significa que o pagamento não pode prosseguir até o problema ser resolvido. Um aviso significa que a fatura pode seguir em frente, mas alguém deve reconhecer o risco.

Pontos de partida típicos:

• Bloqueio rígido: quantidade faturada excede quantidade recebida (para bens).
• Bloqueio rígido: preço unitário excede o preço do PO além da tolerância.
• Aviso: pequenas diferenças de arredondamento.
• Aviso: diferenças de imposto ou frete que são esperadas e codificadas separadamente.

Mantenha regras de tolerância explícitas. Defina o método (percentual, valor absoluto ou o maior dos dois) e quem as controla. Exemplo: permitir +/- 1% ou +/- US$5 por linha, com finanças podendo alterar tolerâncias somente com uma nota de auditoria.

Use um conjunto pequeno e compartilhado de status. Evite status personalizados por equipe. Um conjunto limpo geralmente é suficiente: Matched, Hold, Exception, Approved. “Hold” significa pagamento bloqueado. “Exception” significa que um humano precisa revisar. “Approved” significa que uma pessoa nomeada aceitou a discrepância e registrou o motivo.

Modelo de dados: as tabelas de que você precisa (e por quê)

A automação da conciliação três-vias funciona apenas se seu modelo de dados conseguir alinhar uma linha de PO, o que foi recebido e o que foi faturado. Cada linha de fatura deve poder ser vinculada a uma linha específica do PO (ou estar claramente marcada como non-PO), e cada linha de recebimento deve reduzir a quantidade restante naquela linha do PO.

Comece com tabelas principais de compras:

• Vendors: uma linha por fornecedor (nome, termos, informações fiscais).
• ItemsServices: opcional, mas ajuda a consistência (SKU, descrição, unidade de medida).
• PurchaseOrders: cabeçalho do PO (vendor_id, currency, requested_by, status).
• PO_Lines: a âncora da conciliação (po_id, item_id/description, ordered_qty, unit_price).

Recebimento precisa de seus próprios registros, mesmo que um “receipt” seja só uma confirmação. Separe recebimentos de faturas para poder provar o que chegou e quando:

• Receipts: cabeçalho do recebimento (vendor_id, received_date, location, status).
• Receipt_Lines: cada linha referencia a linha do PO (receipt_id, po_line_id, received_qty, notes).

Faturamento espelha recebimento. Armazene o que o fornecedor cobrou no nível da linha e conecte ao po_line que deve cobrir isso:

• Invoices: cabeçalho da fatura (vendor_id, invoice_number, invoice_date, due_date, status).
• Invoice_Lines: (invoice_id, po_line_id quando aplicável, invoiced_qty, unit_price, tax, line_total).

Por fim, crie um registro voltado para pagamento que seu fluxo possa bloquear. Algumas equipes chamam isso de bill, payment request ou pay run item:

• PaymentRequests (ou Bills): vincula a invoice_id e inclui payment_hold (true/false) além de hold_reason.

Para auditorias e tratamento limpo de exceções, adicione campos de ciclo de vida consistentes nos cabeçalhos (POs, receipts, invoices, payments): status, created_at/created_by, approved_at/approved_by, posted_at e (opcional) source_document_id para importações.

Campos e relacionamentos chave que tornam a conciliação confiável

A conciliação funciona melhor quando todo documento remete à mesma linha de item. Isso significa IDs estáveis, links limpos e totais que podem ser recalculados a partir das linhas.

Garanta que cada tabela tenha tanto um ID interno estável quanto o número externo que as pessoas procuram:

• Cabeçalho PO: po_id, po_number, vendor_id, currency, status, po_date
• Linhas PO: po_line_id, po_id, item_id ou descrição, ordered_qty, unit_price, tax_rate, line_total
• Recebimentos: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• Faturas: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors e items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

Os links mais importantes são por linha:

• invoice_line.po_line_id deve apontar para a linha do PO.
• receipt_line.po_line_id deve apontar para a mesma linha do PO.

É isso que permite comparar quantidade e preço sem adivinhar.

Para lidar com parciais, calcule totais correntes por linha do PO: received_qty (soma das linhas de recebimento) e invoiced_qty (soma das linhas de fatura). Então compute remaining_qty = ordered_qty - received_qty e open_to_invoice_qty = received_qty - invoiced_qty. Esses valores deixam claro se uma fatura está adiantada, atrasada ou cobrando demais.

Não sobrescreva histórico quando um PO muda. Armazene um número de revisão do PO e ou mantenha linhas antigas do PO (com uma flag active) ou escreva um log de mudanças (quem mudou o quê, quando, valor antigo, novo valor).

Adicione guardrails básicos para prevenir duplicatas e junções erradas:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number and po_number
• Not null em currency, quantities e unit_price
• Check constraints como qty >= 0 e unit_price >= 0
• Foreign keys de invoice_line e receipt_line para po_line

Fluxo passo a passo: da recepção da fatura até a retenção de pagamento

A automação da conciliação três-vias normalmente tem três pontos de entrada: chega uma fatura (e-mail, upload, EDI), um recebimento é postado ou um PO é alterado (preço, quantidade, status). O fluxo deve reagir a qualquer uma dessas entradas para que uma fatura possa sair do hold assim que a peça faltante aparecer.

1) Valide os básicos da fatura primeiro. Confirme que o fornecedor está ativo, o PO existe, a moeda coincide com o PO e os totais são internamente consistentes (os totais das linhas somam, imposto é razoável, sem quantidades negativas a menos que suporte créditos). Se isso falhar, envie a fatura direto para Hold com um motivo claro.

2) Faça o pareamento por linha, não apenas no cabeçalho. Para cada linha de fatura, encontre a linha de PO relacionada e os totais de recebimento até o momento. Compare:

• Quantidade faturada vs quantidade recebida (ou recebido menos já faturado)
• Preço unitário faturado vs preço unitário no PO
• Regras de tolerância
• Se a linha do PO ainda está aberta para faturamento

3) Defina status e aplique bloqueio. Um padrão comum:

• Matched: todas as linhas passam nas verificações, sem exceções abertas.
• Hold: pelo menos uma linha falha, ou dados obrigatórios estão faltando.

Quando Hold é definido, crie um registro de retenção de pagamento que a execução de pagamento deve respeitar. Mantenha retenções separadas da fatura para que retenções possam ser adicionadas, liberadas ou substituídas sem reescrever o histórico da fatura.

4) Registre códigos de motivo confiáveis por finanças. Evite retenções apenas em texto livre. Use códigos como PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH ou CURRENCY_MISMATCH, além de uma nota curta.

Design da fila de exceções para finanças (o que armazenar e o que mostrar)

Uma fila de exceções é onde a conciliação se torna utilizável, não apenas estrita. Finanças deve ver apenas faturas que precisam de decisão, com contexto suficiente para decidir rapidamente e deixar um trilho de auditoria limpo.

Uma abordagem comum é uma tabela dedicada como ExceptionCases. Cada linha representa uma fatura bloqueada (ou linha de fatura) e aponta de volta para os registros de invoice, PO e receipt. Mantenha o motor de conciliação como leitura aqui. A fila é para decisões e documentação.

O que armazenar em ExceptionCases

Armazene o que está errado, qual o tamanho do problema, quem é dono e o que acontece em seguida:

• Type (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Severity (info, warning, block) além de um motivo amigável ao usuário
• Owner (pessoa ou equipe) e status (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• Snapshot da variação como números ordenáveis (invoice amount, matched amount, price delta, quantity delta)
• Campos de SLA (due date, escalation flag, reassigned_at, reassignment_reason)

Também armazene colaboração e dados de auditoria: comentários (autor, timestamp) e metadados de anexos (nome do arquivo, tipo, uploaded_by, uploaded_at). Mesmo que os arquivos morem em outro lugar, os metadados pertencem ao caso para que o histórico permaneça intacto.

O que finanças deve ver (e fazer)

A visão da fila deve ser uma lista enxuta de trabalho: fornecedor, número da fatura, tipo de exceção, severidade, valor, data de vencimento, responsável e uma mensagem clara “por que bloqueado”.

Abrir um caso deve mostrar um resumo lado a lado: linhas do PO, quantidades recebidas, linhas da fatura e os campos exatos que falharam.

Mantenha as ações limitadas e seguras:

• Solicitar recebimento (encaminha para recebimento, define status para waiting)
• Solicitar nota de crédito (encaminha ao fornecedor, registra ajuste esperado)
• Aprovar override (exige motivo, captura aprovador e timestamp)
• Reatribuir (atualiza o dono, mantém histórico de reatribuições)
• Fechar como resolvido (apenas depois de mudanças que façam a conciliação passar)

Exemplo: uma fatura está bloqueada porque 8 unidades foram recebidas mas 10 foram cobradas. Finanças pode pedir uma fatura corrigida, ou aprovar um override para as 8 unidades recebidas e manter as 2 restantes em hold.

Exemplo realista: recebimento parcial e fatura com divergência

Um comprador cria um PO para 100 unidades do item A a US$10,00 cada. O total do PO é US$1.000. Dois dias depois, o armazém registra um recebimento de 80 unidades.

Então chega uma fatura por 100 unidades a US$10,00 cada. A conciliação deve comparar as linhas da fatura com o que foi recebido, não apenas com o que foi pedido.

Nessa linha:

• Pedido: 100 unidades
• Recebido: 80 unidades
• Faturado: 100 unidades
• Quantidade conciliada: min(Received, Invoiced) = 80 unidades
• Quantidade não conciliada: Invoiced - Matched = 20 unidades

A fatura fica “On hold” porque 20 unidades não têm recebimento. Finanças vê um caso com um motivo claro (Quantity variance: +20) e os números chave lado a lado.

Notificações devem ir para quem pode corrigir mais rápido: normalmente o recebedor (para confirmar se falta um recebimento) e o comprador (para acompanhar se a remessa veio curta).

Quando as 20 unidades restantes chegam, o armazém posta um segundo recebimento de 20 unidades. O sistema reexecuta a conciliação: received fica 100, unmatched vira 0, a fatura passa para Matched e a retenção é liberada.

Agora adicione uma variação de preço. Se o fornecedor fatura 100 unidades a US$10,50 em vez de US$10,00, a quantidade casa mas o preço não. Resultado esperado: manter a fatura em hold e direcioná-la com um motivo como “Price variance: +$0.50/unit (+$50 total).”

Erros comuns que quebram fluxos de conciliação três-vias

A maioria das falhas de conciliação não é sobre matemática. Vem de links de dados fracos e controles frouxos sobre documentos postados.

Conferir apenas pelo total da fatura. Um cabeçalho pode parecer OK enquanto uma linha está com preço errado ou faltando. Faça conciliação por linha e seja explícito sobre o que pode diferir (frete, por exemplo) e o que não pode (quantidade recebida e preço unitário).

Pressupor um recebimento e uma fatura por PO. Compras reais incluem remessas fracionadas e faturamento parcial. Suporte várias receipts e várias invoices contra as mesmas linhas de PO, e acompanhe a quantidade aberta por linha.

Permitir edições em recebimentos ou faturas postadas sem trilha. Se alguém pode mudar quantidades silenciosamente depois, a conciliação deixa de ser prova. Bloqueie registros postados e corrija via documentos de ajuste que preservem histórico.

Falta de prevenção de duplicatas. O mesmo número de fatura do fornecedor pode ser inserido duas vezes, ou um PDF pode ser carregado novamente por outra pessoa. Adicione unicidade cedo (vendor + número da fatura, e opcionalmente data/valor) e mostre mensagem clara quando uma duplicata for detectada.

Motivos de exceção vagos. Finanças não deve adivinhar. Use códigos de motivo que direcionem claramente: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch.

Checklist rápido antes de ativar bloqueio de pagamento

O bloqueio de pagamento é quando a conciliação deixa de ser relatório e vira controle. Se o básico não estiver sólido, você criará ruído para finanças e pagamentos atrasados para fornecedores.

Teste um conjunto pequeno de faturas que se parecem diferentes: uma conciliação limpa, um recebimento parcial, uma mudança de preço e uma diferença de imposto. Se alguma não puder ser conciliada limpidamente, corrija os dados e as regras primeiro.

Checklist:

• Completude de referência: cada fatura tem fornecedor e uma referência de PO, e cada linha de fatura pode mapear para uma linha específica do PO (não apenas “total do PO”). Decida o que acontece quando um fornecedor envia apenas o número do cabeçalho do PO.
• Matemática consistente: quantidades, preços unitários e totais são recalculados da mesma forma toda vez. Seja explícito sobre imposto, frete, descontos e arredondamento (por exemplo, arredondar por linha vs apenas no total da fatura).
• Status bloqueiam cedo o suficiente: defina “on hold” antes que qualquer solicitação de pagamento ou registro de pagamento seja criado.
• Exceções estruturadas: cada retenção armazena um código de motivo e um responsável (AP, comprador, recebedor). Acrescente datas de vencimento para que retenções não fiquem indefinidamente.
• Trilha de auditoria real: substituições registram quem aprovou, quando e o que aprovaram (incluindo valores originais). Se permitir edições, registre valores antes e depois.

Próximos passos: pilote o processo e construa visualmente

Trate a automação da conciliação três-vias como qualquer controle: prove que funciona em uma fatia pequena do gasto e então faça o rollout.

Comece com um piloto fácil de monitorar. Escolha uma unidade de negócios, um pequeno grupo de fornecedores que enviam faturas limpas ou uma única categoria de itens. Mantenha as regras estritas no início (conferência exata de quantidade e preço) para que problemas de qualidade de dados apareçam rapidamente.

Meça sucesso com uma visão simples para finanças: retenções por semana, principais códigos de motivo, tempo de hold até liberação, quantas retenções eram discrepâncias reais e quais fornecedores geram exceções recorrentes.

Se quiser prototipar rapidamente, uma plataforma no-code pode ajudar porque você pode modelar tabelas, regras de conciliação e roteamento sem escrever código. Por exemplo, no AppMaster (appmaster.io) você pode construir as tabelas de PO, receipt, invoice e exception, e então conectar a lógica de retenção em um processo visual para que as mesmas regras rodem em todo gatilho.

Teste com faturas reais do grupo piloto, incluindo recebimentos parciais e erros comuns dos fornecedores. Espere ajustar chaves de pareamento e adicionar pequenas tolerâncias só depois de ver padrões. Quando as retenções parecerem razoáveis e os tempos de resolução melhorarem, expanda o escopo e acrescente regras mais ricas (imposto e frete, conversões de unidade de medida, remessas fracionadas) sem perder o controle central: nenhum pagamento liberado até a conciliação ser limpa.