Conciliação de Três Vias sem ERP:
Um Pipeline no Google Sheets do Pedido à Aprovação

O que a Conciliação de Três Vias Realmente Exige — Mais que Limites de Tolerância

A conciliação de três vias é o processo de comparar um pedido de compra, um recebimento de mercadorias e uma fatura do fornecedor antes de autorizar o pagamento — verificando se o que foi pedido corresponde ao que foi recebido e ao que foi faturado. De acordo com a Cláusula 8.4 da ISO 9001:2015, a verificação de que os produtos adquiridos atendem aos requisitos especificados é obrigatória para fabricantes certificados, e a conciliação de três vias é o mecanismo operacional que a maioria das empresas utiliza para cumpri-la. O Relatório para as Nações 2024 da ACFE — que estima que as organizações perdem 5% da receita anual para fraudes ocupacionais — a identifica como um controle-chave contra esquemas de faturamento. A lógica regulatória é sólida. O problema de dados subjacente é o que quebra na prática.

A maioria dos conselhos sobre como corrigir a conciliação de três vias foca na camada de conciliação: apertar limites de tolerância, adicionar fluxos de aprovação, configurar regras de conciliação automática no ERP. Nada disso resolve o problema de que os três documentos chegam de três sistemas diferentes em três formatos diferentes — e dois deles são não estruturados. O pedido de compra está no sistema de compras. O recebimento de mercadorias pode ou não ter sido inserido a partir de um romaneio em papel. A fatura do fornecedor chega como um PDF. Antes que qualquer lógica de conciliação possa comparar esses documentos, alguém precisa extrair os dados dos dois que não estão em um formato estruturado, inseri-los em um layout comparável e torcer para que as unidades e os itens de linha se alinhem. A camada de conciliação — PROCV, funções SE, formatação condicional — é a parte fácil. A camada de extração é onde o pipeline vive ou morre.

Por que o Conselho de ERP Não se Aplica a um Fluxo de Planilha

O módulo MM do SAP, Oracle E-Business Suite, Microsoft Dynamics 365 — todos incluem módulos de conciliação tripla com tolerâncias configuráveis. O SAP, por exemplo, lida com a conciliação por meio da conta de compensação GR/IR: o recebimento de mercadorias (transação MIGO) lança um débito, o recebimento de fatura (MIRO) lança um crédito, e o sistema compensa automaticamente os itens de linha conciliados. A lógica é madura e bem documentada.

A lógica também pressupõe algo que, em um número substancial de operações de compras, não é verdade: que todos os três documentos existem como dados estruturados e comparáveis dentro do ERP antes que a lógica de conciliação seja executada. A Pesquisa de Tendências de Automação de Contas a Pagar da IFOL de 2025 constatou que 66% das equipes de AP ainda inserem manualmente os dados das faturas em seus ERPs. Para equipes de compras que gerenciam relacionamentos com fornecedores entre 50 e 200 fornecedores — muitos deles pequenas oficinas mecânicas, distribuidores locais e fornecedores especializados que enviam PDFs por e-mail — cada fatura é um evento de entrada manual de dados antes que a conciliação possa começar.

Se você está nesse grupo — seja porque sua empresa gerencia compras por planilhas, porque o sistema de captura de notas fiscais do seu ERP exige configuração de modelo por fornecedor e você não tem tempo para manter, ou porque sua base de fornecedores inclui muitos pequenos que só enviam PDF — o módulo de conciliação do ERP está resolvendo um problema a jusante do que você realmente tem. Você não precisa de um algoritmo de conciliação melhor. Você precisa de uma forma de reunir dados de pedido de compra, recebimento e nota fiscal em uma única visão estruturada — e a ferramenta que você já usa para acompanhar compras provavelmente é uma planilha. A questão é como transformar essa planilha em um pipeline.

A Arquitetura do Pipeline em Três Camadas

O pipeline tem três camadas — uma para cada documento na conciliação tripla — e uma quarta que fica sobre elas: o painel de conciliação. As três primeiras camadas extraem dados estruturados de documentos não estruturados. A quarta os compara. Se qualquer uma das três primeiras camadas produzir dados inconsistentes ou incompletos, a camada de conciliação não consegue funcionar. A arquitetura é tão forte quanto sua camada de extração mais fraca.

Cada camada preenche uma lacuna específica na cadeia de compras a pagamento. A camada de PO estabelece a base — o que foi pedido, a que preço, de quem. A camada de recebimento confirma o que chegou fisicamente. A camada de fatura captura o que o fornecedor cobrou. O painel de conciliação é onde as três convergem — e onde a planilha substitui a investigação entre três departamentos que a análise do problema identificou como a fragilidade estrutural nos fluxos de conciliação tradicionais.

A ferramenta que viabiliza a conversão de não estruturado para estruturado nas camadas 1 e 3 é a Extração Personalizada de Colunas: em vez de desenhar caixas ao redor dos campos em cada documento ou criar um modelo por formato de fornecedor, você digita os nomes das colunas desejadas — "Número do PO", "Nome do Fornecedor", "Item", "Quantidade", "Preço Unitário", "Total do Item" — e a IA lê o documento para encontrar esses valores entendendo o que significam, não onde estão na página. Um PO estruturado do PDF do SAP e um PO manuscrito de um fornecedor local não se parecem em nada. Mas ambos contêm número do PO, nome do fornecedor, quantidades e preços. A extração por nome de coluna busca o significado desses campos em qualquer layout — eliminando a manutenção de modelos por fornecedor e por formato que torna o OCR baseado em modelos inviável para equipes de compras que lidam com dezenas de formatos diferentes de documentos de fornecedores.

Camada 1 — Extração de Pedido de Compra: A Base de Referência

Toda conciliação tripla começa com a ordem de compra. A OC define os termos: qual fornecedor, quais itens, qual quantidade, a que preço e prazo de entrega. Em um ambiente integrado ao ERP, esses dados já existem como itens de linha estruturados — a OC foi criada no sistema. Mas em um fluxo de compras baseado em planilhas, as OCs chegam em vários formatos: PDFs gerados pelo sistema do comprador, OCs enviadas por e-mail pelos fornecedores confirmando um pedido, ou documentos digitalizados de fornecedores menores que operam no papel. Obter os dados da OC em um formato estruturado é o primeiro passo — e, para equipes que usam planilhas, é uma etapa que determina se o restante do processo é sequer viável.

As colunas de extração de uma OC dependem do que seu processo de conciliação precisa referenciar. No mínimo:

Para ordens de compra geradas internamente em um formato consistente — o modelo de OC da sua própria empresa — a extração é direta. A IA lê os mesmos campos do mesmo layout geral todas as vezes. Para OCs de confirmação de fornecedor que chegam no formato do vendedor, a extração se adapta: os nomes das colunas permanecem os mesmos, e a IA localiza os valores independentemente do layout. Uma única execução de extração preenche a guia de registro de OC com dados estruturados — uma linha por OC, ou uma linha por item de linha, dependendo se você deseja granularidade no nível de cabeçalho ou de item para a conciliação. O guia de extração de OC única com o complemento do Google Sheets explica a configuração das colunas e o primeiro fluxo de extração. Para equipes de alto volume que processam dezenas de OCs de uma só vez, o painel de processamento em lote de OCs aplica o mesmo mecanismo de extração em várias OCs em uma única sessão.

A demonstração acima usa o preset de pedido de compra — um conjunto pré-configurado de colunas de extração para documentos de PO. Faça upload de um pedido de compra e veja os campos serem preenchidos sem digitar. Se seus POs tiverem campos não cobertos pelo preset (uma linha de sobretaxa de commodity, uma seção de termos de frete, códigos internos de centro de custo), adicione-os como colunas personalizadas — o mecanismo de extração os trata da mesma forma. O preset fornece o ponto de partida. Suas colunas personalizadas o estendem para atender aos requisitos do seu dashboard de correspondência.

Camada 2 — Recebimento de Dados do Relatório: O Documento Intermediário Delicado

O recebimento de mercadorias é o documento com maior probabilidade de estar ausente em um sistema estruturado — e é o documento que torna a conciliação tripla um processo de três vias. Sem a confirmação de recebimento, você está fazendo uma conciliação dupla (pedido de compra vs. fatura) e pagando por mercadorias que não pode confirmar se foram entregues. A ACFE identifica especificamente o recebimento de mercadorias como o controle que previne fraudes de faturamento — pagar por mercadorias nunca enviadas. Ignorá-lo não é um atalho. É uma lacuna no sistema de controles.

Os dados de recebimento são mais difíceis de estruturar do que os dados do pedido de compra devido à forma como são criados — no cais, muitas vezes em papel, por funcionários cuja prioridade é descarregar caminhões, não inserir dados. O romaneio geralmente é um formulário de carbono multicópia ou um documento de impressão térmica da transportadora. O conferente assina, registra a quantidade recebida (às vezes em unidades diferentes do pedido de compra) e arquiva a cópia física. Se esses dados chegam a um sistema digital depende se alguém os digita posteriormente — e essa etapa é a primeira a ser ignorada em um dia movimentado de recebimento.

Para o pipeline, os dados de recebimento têm duas vias de entrada viáveis. A primeira é a inserção manual direta: o conferente — ou um funcionário designado para entrada de dados — digita os campos principais em uma Planilha Google como parte do fluxo de recebimento. As colunas espelham as colunas do pedido de compra: Número do Pedido (para vinculação), Item Recebido, Quantidade Recebida, Data de Recebimento, Transportadora, Condição. Essa via funciona quando o volume de recebimento é moderado (menos de 30 remessas por dia) e o cais tem acesso a um dispositivo com a Planilha aberta. A vantagem é o controle — os dados de recebimento são estruturados desde o momento da inserção, sem necessidade de conversão posterior.

O segundo caminho é a extração de documentos diretamente do packing slip — tirar uma foto ou digitalizar o packing slip assinado e processá-lo pelo mesmo mecanismo de extração usado para POs e faturas. Esse caminho funciona quando o lançamento manual não é viável — docas de alto volume, locais remotos de recebimento ou operações onde o packing slip é o único registro de recebimento. As colunas de extração são as mesmas: Número do PO, Descrição do Item, Quantidade Recebida, Data de Recebimento, Transportadora. Uma foto de packing slip tirada pelo celular e processada pelo complemento da barra lateral preenche a aba de recebimento no mesmo formato estruturado dos dados inseridos manualmente. A principal limitação: a caligrafia nos packing slips reduz a precisão da extração em comparação com POs e faturas impressos. Recomenda-se verificação pontual para remessas críticas. Para uma análise detalhada de precisão por qualidade do documento, consulte nosso guia sobre precisão da extração de documentos manuscritos — os mesmos princípios se aplicam a packing slips e relatórios de recebimento.

Qualquer caminho que você use, o resultado é o mesmo: uma aba de registro de recebimento com o Número do PO como campo-chave que vincula cada recebimento à sua ordem de compra de origem. Sem esse vínculo, o painel de correspondência não consegue funcionar.

Camada 3 — Extração de Faturas de Fornecedores: O Problema de Formato que Você Não Controla

As faturas de fornecedores são onde o problema da diversidade de formatos atinge o pico. Uma única operação de compras pode receber faturas de um grande distribuidor de MRO em um PDF estruturado gerado por SAP, de um fornecedor regional de metais em um formato caseiro de Excel para PDF, de uma oficina mecânica local como um documento manuscrito fotografado e de um fornecedor internacional com diferentes formatos de data, convenções de moeda e estruturas de linhas de imposto. O OCR baseado em modelos — onde você cria um modelo de mapeamento de campos para o layout de cada fornecedor e o atualiza quando o layout muda — falha diante dessa diversidade ou consome tanto tempo de manutenção que o esforço de extração equivale à entrada manual que deveria substituir.

A Extração de Colunas Personalizadas resolve isso desacoplando a lógica de extração de qualquer layout específico. Os nomes das colunas são definidos uma vez. A IA lê cada fatura — independentemente do formato — e encontra os valores que correspondem a essas definições de coluna. Uma configuração de colunas de fatura para conciliação tripla normalmente inclui:

Você também pode adicionar colunas inferidas — colunas que capturam dados não impressos explicitamente na nota fiscal, mas que podem ser deduzidos do contexto. Por exemplo, uma coluna definida como Status de Correspondência (opções: Pronto para Corresponder/Precisa de Referência PO/Itens de Linha Ausentes) permite que a IA classifique cada nota fiscal durante a extração com base na presença de um número de PO e na possibilidade de extrair itens de linha. Notas fiscais de fornecedores que não incluem números de PO em seus documentos são sinalizadas imediatamente — elas entram no painel de correspondência com o status "Precisa de Referência PO", e o auxiliar de contas a pagar sabe que não deve tentar a correspondência até que o número de PO seja adicionado. Isso é categorização como extração: a decisão de classificação ocorre na mesma passagem que preenche os dados, não em uma etapa de revisão separada.

Colunas calculadas lidam com cálculos que, de outra forma, exigiriam fórmulas de planilha pós-extração. Defina uma coluna como Verificação de Extensão (Total da Linha - Quantidade * Preço Unitário) e a IA realiza o cálculo durante a extração, sinalizando qualquer linha onde o total faturado não seja igual à quantidade vezes o preço unitário. A saída é um número de variação — zero significa que a extensão está correta, um valor diferente de zero identifica um erro aritmético na nota fiscal do fornecedor. Isso muda o papel do painel de correspondência de "encontrar os erros" para "revisar as linhas sinalizadas" — um fluxo de trabalho onde a IA faz a detecção e o humano faz a disposição. Para um tratamento completo da sintaxe e capacidades de colunas calculadas, consulte nosso guia de colunas calculadas em extração de documentos.

A mesma camada de extração de notas fiscais que alimenta o pipeline de conciliação de três vias é o motor por trás do pipeline de notas fiscais do fornecedor ao contas a pagar — a estrutura das colunas difere, mas o mecanismo de extração é idêntico. Uma vez construído para conciliação, o mesmo pipeline alimenta relatórios de contas a pagar, cálculos de provisões e documentação de auditoria.

O Painel de Conciliação: PROCV, SE e Formatação Condicional

Com as três camadas preenchidas — registro de pedidos de compra, registro de recebimentos e registro de notas fiscais — o painel de conciliação é onde elas convergem. Esta é uma única aba que extrai dados das três abas de origem usando funções de busca e aplica lógica de comparação para sinalizar correspondências, variações e dados ausentes. A lógica de conciliação em si não é complexa. Uma planilha consegue fazer isso. O que sempre foi complexo — e que o pipeline resolve — é colocar os dados em um estado onde a planilha possa fazer isso.

A estrutura do painel de conciliação, criada no Google Sheets:

Formatação condicional transforma isso de uma tabela em um painel: destaque a Coluna N em verde para "CONCILIADO," âmbar para "SEM RECEBIMENTO," vermelho para "VARIAÇÃO." Aplique uma borda vermelha a qualquer linha onde a Coluna J (Variação de Qtd.) exceda um limite configurável — 5% para materiais a granel, 2% para componentes de engenharia de alto valor. Adicione um resumo na linha superior: =CONT.SE(N:N;"CONCILIADO") para contar notas conciliadas, =CONT.SE(N:N;"VARIAÇÃO") para exceções, =SOMASE(N:N;"VARIAÇÃO";L:L) para o valor total em dólares das variações.

A decisão arquitetural chave é usar o Número de PO como chave universal. Cada PROCV no painel de conciliação faz referência à coluna de Número de PO. Se uma fatura de fornecedor não incluir um número de PO — e nossa análise do problema de conciliação confirmou que esta é a causa raiz mais comum de falha — a linha é preenchida com erros #N/D em todas as colunas de PROCV, ficando imediatamente visível no painel. A correção é simples: adicione o número de PO à linha do registro de faturas e as fórmulas recalculam. Mas a visibilidade é o ponto principal. Sem o painel, uma fatura sem número de PO fica em uma fila até que alguém perceba. Com o painel, ela é sinalizada no momento em que a linha é preenchida.

Para entregas parciais — a complexidade mais comum em compras industriais, onde um único pedido de compra cobre vários embarques — adicione uma coluna "Número da Entrega" tanto ao registro de recebimento quanto ao registro de faturas. O PROCV se torna uma consulta de duas chaves: correspondência por Número do PO E Número da Entrega. Cada entrega parcial recebe sua própria linha correspondente, e o cálculo de recebimento acumulado (=SOMASES(F:F; A:A; A2; [Entrega]; "<="&[@Entrega])) rastreia quanto da quantidade total do PO foi entregue em todos os embarques parciais. A mesma lógica se aplica a POs abertos com liberações mensais contínuas — o painel rastreia quantidades acumuladas em relação à autorização total do PO.

Link de Coleta — Deixe os Fornecedores Enviarem Documentos Diretamente

Uma das ineficiências persistentes na conciliação de três vias é a transferência de documentos do fornecedor para sua equipe de Contas a Pagar. O fornecedor envia a fatura por e-mail. O auxiliar de AP baixa o anexo, salva em uma unidade compartilhada ou pasta local e, em seguida, o envia para a ferramenta de extração. Esse ciclo de baixar e reenviar não é o gargalo — mas é uma etapa extra que acumula atrito quando você processa mais de 100 faturas por mês de 50 fornecedores diferentes.

Um Link de Coleta elimina essa etapa intermediária. É uma URL compartilhável (no formato /c/xxxx) que você gera e envia para um fornecedor. O fornecedor abre o link, insere um código de verificação curto exibido na página e envia sua fatura diretamente — sem criar conta, sem login, sem instalação de software. O arquivo chega automaticamente na fila de processamento da sua conta, com o fornecedor identificado pelo link usado. Você pode criar um Link de Coleta separado para cada fornecedor (ou um por grupo de fornecedores), para que os arquivos recebidos sejam pré-classificados por origem antes mesmo da extração começar.

Aplicado ao pipeline de conciliação de três vias, um Link de Coleta altera o fluxo de documentos de "fornecedor envia nota fiscal por e-mail → você baixa → você anexa → você extrai" para "fornecedor envia diretamente → arquivo aparece na sua fila → você extrai." Ele elimina completamente a etapa de baixar e reenviar. Para fornecedores que enviam múltiplos documentos — um romaneio e uma nota fiscal para a mesma remessa — um único Link de Coleta captura ambos os arquivos, e o mecanismo de extração processa cada um de acordo com as definições de colunas na planilha. Para configuração detalhada e fluxo de trabalho, consulte nosso guia de coleta de documentos com extração.

O Que Isso Substitui — e o Que Não Substitui

Um pipeline é uma afirmação específica: ele diz "esta sequência de etapas produz esta saída." É importante ser preciso sobre o que o pipeline descrito aqui substitui, o que complementa e o que nunca foi projetado para fazer.

O que substitui:

• Inserção manual de dados de POs e faturas em planilhas. As camadas de extração convertem documentos não estruturados em linhas estruturadas. Digitar itens de PO e campos de fatura em uma planilha de controle é a etapa que desaparece.
• Manutenção de modelos OCR por fornecedor. A extração por nomes de colunas lê qualquer layout de documento sem modelos pré-configurados. Um novo fornecedor é integrado enviando um Link de Coleta — sem necessidade de criar modelos.
• O ciclo de investigação entre três departamentos. Quando dados de PO, recebimento e fatura estão todos em um painel estruturado, a pergunta "a fatura corresponde ao PO?" é respondida olhando para uma célula com formatação condicional, sem precisar ligar para compras ou para o almoxarifado.
• Pontos cegos de documentos ausentes. A estrutura de PROCV do painel expõe lacunas imediatamente: #N/D no PROCV do PO significa que a fatura não referencia um PO válido. Em branco na quantidade recebida significa que o recebimento de mercadorias nunca foi registrado. Esses não são achados de uma auditoria mensal — são visíveis em cada linha, em tempo real.

O que não substitui:

• Um ERP para organizações que precisam de um. Com 2.000 a 3.000 notas fiscais por mês, um painel de conciliação baseado em planilhas atinge seu limite prático. O volume de exceções sobrecarrega a revisão manual. Nessa escala, o valor do ERP — conciliação automatizada, trilhas de auditoria integradas, imposição de segregação de funções — torna-se necessário, não opcional. O pipeline alimenta o ERP com dados estruturados; não substitui o ERP como ambiente de controle.
• Julgamento humano sobre exceções. O painel sinaliza variações. Não as resolve. Uma diferença de R$ 47,50 entre o preço unitário faturado e o do pedido de compra pode ser uma sobretaxa legítima negociada pela equipe de compras, mas nunca comunicada ao contas a pagar, ou pode ser um erro. A IA não consegue saber qual é — e não deve ser solicitada a decidir. A sinalização aciona a revisão humana. A revisão exige contexto de negócios que a IA não possui.
• O próprio processo de recebimento. Se os recibos de mercadorias não estão sendo criados — se o depósito não está registrando o que chega — o pipeline expõe a lacuna na aba de recebimento, mas não pode fabricar os dados. A camada de recebimento exige disciplina de processo: alguém precisa confirmar e registrar o que foi entregue. O pipeline estrutura esses dados. Não os cria do nada.
• Conformidade dos fornecedores com a exigência de número de pedido de compra na nota fiscal. O pipeline torna visível a ausência de um número de pedido de compra. Não faz com que os fornecedores incluam um. Isso exige uma política de compras — e aplicação —, não uma solução técnica.

Perguntas Frequentes

Quantas notas fiscais este pipeline consegue processar por mês antes de quebrar?

O limite estrutural não está no mecanismo de extração — ele lida com uploads em lote de vários arquivos em uma única sessão — mas sim na capacidade de revisão manual do painel de correspondência. Um único auxiliar de contas a pagar revisando e tratando variações consegue processar confortavelmente cerca de 300 a 500 faturas por mês com um painel de correspondência bem estruturado, assumindo uma taxa de exceção de 22% (66 a 110 exceções para investigar). Acima de 1.000 faturas por mês, o volume de exceções exige vários auxiliares de contas a pagar ou a migração para um ERP com regras de correspondência automatizadas. O valor do pipeline em volumes mais altos muda de "ferramenta principal de correspondência" para "mecanismo de ingestão de dados que alimenta dados estruturados no ERP" — as camadas de extração continuam funcionando; o painel se torna uma etapa de validação pré-ERP, em vez do ambiente final de correspondência.

E se meus pedidos de compra usarem preços abertos que mudam mensalmente — o pipeline consegue lidar com preços variáveis?

Sim — mas exige que o registro de pedidos de compra seja mantido como um documento vivo, e não como uma extração única. Para um pedido de compra aberto com ajustes mensais de preço indexados a uma taxa de mercado de commodities, a linha do registro de pedidos de compra para aquele fornecedor precisa ser atualizada a cada mês com o preço vigente. O PROCV no painel de correspondência refletirá o preço atualizado. A alternativa — e a que preserva uma trilha de auditoria — é adicionar uma coluna "Data de Vigência" ao registro de pedidos de compra e usar um PROCV com correspondência por intervalo de datas: buscar o preço do pedido de compra que estava vigente na data da fatura, e não o preço atual. Isso é mais complexo de configurar, mas reflete com precisão qual era o preço acordado no momento do embarque — que é o que a correspondência tripla deve verificar.

A extração funciona em notas fiscais de remessa e documentos de recebimento manuscritos?

Sim — a IA lê texto manuscrito, incluindo números e anotações típicas de romaneios assinados no cais. No entanto, a precisão em documentos manuscritos é menor do que em documentos impressos, e documentos muito degradados (impressões térmicas desbotadas, cópias carbono com texto apagado, romaneios amassados e re-alisados) gerarão mais erros de extração. Especificamente para dados de recebimento, recomendamos: (a) se possível, que o conferente insira os campos-chave (Nº do Pedido, Item, Quantidade, Data) diretamente na Planilha Google no cais — a digitação manual no momento do recebimento é mais rápida e precisa do que a extração de um documento degradado posteriormente; (b) se a extração do romaneio for a única opção viável, verifique uma amostra de linhas comparando com o documento original, especialmente para remessas de alto valor; (c) use a foto do romaneio como anexo armazenado junto à linha de recebimento — mesmo que a extração perca um dígito, o documento original está a um clique de distância para verificação.

Posso usar este pipeline sem o complemento do Google Sheets — apenas o aplicativo web?

Sim. O mecanismo de extração é o mesmo, seja acessado pelo complemento na barra lateral do Sheets ou pelo aplicativo web em ImageToTable.ai. A vantagem do complemento é que a saída da extração é gravada diretamente na planilha ativa — sem ciclo de download e reenvio. Com o aplicativo web, você envia documentos no navegador, baixa o arquivo Excel extraído e cola ou importa as linhas no seu painel de correspondência. As definições de colunas são as mesmas. A qualidade da extração é idêntica. O complemento elimina uma etapa (o download e a importação); o aplicativo web funciona com qualquer ferramenta de planilha, não apenas o Google Sheets. Escolha com base se essa etapa única faz diferença no seu volume.

Qual é o tempo de configuração para o pipeline completo — registro de PO, registro de recebimento, registro de nota fiscal e painel de conciliação?

Para alguém familiarizado com PROCV e formatação condicional no Google Sheets, montar o pipeline completo de quatro abas leva cerca de duas horas: 30 minutos para projetar e criar as quatro abas com as estruturas de colunas descritas acima, 45 minutos para escrever e testar as fórmulas PROCV e SE no painel de conciliação, 30 minutos para configurar a formatação condicional e as métricas de resumo, e 15 minutos para definir os conjuntos de colunas de extração na barra lateral do complemento. As definições de colunas são salvas na planilha e persistem entre sessões — você as define uma vez e elas ficam disponíveis toda vez que abrir a barra lateral e selecionar aquela planilha. Após a configuração inicial, o fluxo de trabalho mensal é: (1) extrair novos POs para o registro de PO, (2) inserir ou extrair dados de recebimento, (3) extrair notas fiscais de fornecedores, (4) abrir o painel de conciliação e revisar as linhas sinalizadas. O primeiro mês leva mais tempo devido à configuração e ao preenchimento dos dados. O terceiro mês já é rotina.

Como lidar com diferenças de moeda entre POs e notas fiscais de fornecedores?

O mecanismo de extração captura o valor numérico e o símbolo da moeda conforme aparecem no documento. Ele não realiza conversão de moeda. Se seu PO estiver em USD e uma nota fiscal de fornecedor em EUR, o painel de conciliação mostrará uma variação porque os valores numéricos não coincidirão — mesmo que os valores convertidos estejam corretos. A solução é adicionar uma coluna "Moeda" tanto no registro de PO quanto no registro de nota fiscal, e uma coluna "Taxa de Conversão" que faça referência a uma taxa de câmbio mantida manualmente ou alimentada por fórmula. A comparação de preços no painel usará então o valor convertido em vez do valor bruto extraído. O trabalho do pipeline é a extração. A conversão de moeda é uma operação na camada da planilha.

Conclusão

O pipeline de correspondência de três vias descrito aqui não substitui um ERP em organizações que precisam de um. É um sistema para equipes que já gerenciam compras por planilhas — porque a captura de faturas do ERP exige manutenção de modelos que não conseguem sustentar, porque a base de fornecedores abrange formatos que o módulo de correspondência não consegue processar, ou porque o volume de transações está na lacuna entre "complexo demais para correspondência manual" e "grande o suficiente para justificar uma atualização de ERP". Para essas equipes, a pergunta não é "devemos automatizar a correspondência". É "conseguimos colocar os três documentos no mesmo formato estruturado rápido o suficiente para que a correspondência se torne um exercício de fórmula, em vez de uma investigação de três departamentos."

O pipeline responde a essa pergunta com três camadas de extração e um painel. A camada de pedido de compra fornece a linha de base de referência. A camada de recebimento confirma o que chegou. A camada de fatura captura o que foi cobrado. O painel de correspondência compara os dados — com PROCV, instruções SE e formatação condicional — e sinaliza cada linha que precisa de atenção humana. O mecanismo de extração, alimentado por IA que lê documentos pelo significado, e não pela posição, lida com a diversidade de formatos que torna as abordagens baseadas em modelos insustentáveis em uma operação de compras com múltiplos fornecedores. O Link de Coleta elimina o ciclo de download de anexos de e-mail do processo de captura de documentos.

A lacuna estrutural que nossa análise de problemas identificou — três departamentos, três sistemas, nenhum proprietário único do pipeline de dados — não desaparece. Mas quando os três tipos de documento chegam no mesmo formato estruturado na mesma planilha, com o mesmo Número de PO como chave universal, a etapa de correspondência não exige mais investigação entre departamentos. A lacuna organizacional permanece. Os dados não carregam mais o desvio acumulado de três canais de entrada diferentes. É isso que torna a correspondência um exercício de planilha em vez de um problema de pessoal.

Comece pela camada de extração de PO. Faça upload de um pedido de compra na demonstração abaixo. Veja se os campos importantes para seu fluxo de correspondência — número do PO, fornecedor, itens, quantidades, preços — são retornados estruturados em segundos, em vez de digitados em minutos. Se essa primeira camada funcionar, o restante do pipeline é construído sobre o mesmo motor.