Como criar um pipeline de correspondência tripla no Google Sheets:
Passo a passo do pedido de compra à aprovação da fatura

O que a Conciliação Tríplice Realmente Exige — Mais do que Limites de Tolerância

A conciliação tríplice é 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 tríplice é o mecanismo operacional que a maioria das empresas usa 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 tríplice foca na camada de correspondência: apertar limites de tolerância, adicionar fluxos de aprovação, configurar regras de correspondência 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 canhoto de entrega em papel. A fatura do fornecedor chega como um PDF. Antes que qualquer lógica de correspondência 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 estejam alinhados. A camada de correspondência — 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 trabalho com planilhas

O módulo MM do SAP, o Oracle E-Business Suite e o Microsoft Dynamics 365 — todos incluem módulos de correspondência de três vias com tolerâncias configuráveis. O SAP, por exemplo, lida com a correspondência 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 correspondentes. 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 existam como dados estruturados e comparáveis dentro do ERP antes que a lógica de correspondência seja executada. A pesquisa IFOL AP Automation Trends Survey de 2025 constatou que 66% das equipes de contas a pagar ainda inserem manualmente os dados das faturas em seus ERPs. Para equipes de compras que gerenciam relacionamentos com fornecedores em 50 a 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 correspondência possa começar.

Se você está nesse grupo — seja porque sua empresa conduz compras por meio de planilhas, porque a captura de faturas do seu ERP exige configuração de modelo por fornecedor que você não tem tempo de manter, ou porque sua base de fornecedores inclui muitos pequenos fornecedores para os quais o PDF é o único formato enviado — o módulo de correspondência do ERP está lidando com um problema a jusante do que você realmente tem. Você não precisa de um algoritmo de correspondência melhor. Você precisa de uma forma de reunir dados de pedido de compra, dados de recebimento e dados de fatura 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 de Pipeline em Três Camadas

O pipeline tem três camadas — uma para cada documento na correspondência de três vias — e uma quarta que fica acima delas: o painel de correspondência. 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 correspondência não consegue fazer seu trabalho. A arquitetura é tão forte quanto sua camada de extração mais fraca.

Cada camada preenche uma lacuna específica na cadeia de compras até o 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 correspondência é onde os três convergem — e onde a planilha substitui a investigação entre três departamentos que a análise do problema identificou como a fraqueza estrutural nos fluxos de correspondência tradicionais.

A ferramenta que viabiliza a conversão de não estruturado para estruturado nas camadas 1 e 3 é a Extração de Colunas Personalizadas: 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 da saída em 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 impraticável para equipes de compras que lidam com dezenas de formatos de documentos de fornecedores diferentes.

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

Toda conciliação de três vias começa com a ordem de compra. A OC define os termos: qual fornecedor, quais itens, qual quantidade, a que preço e para entrega quando. Em um ambiente integrado a ERP, esses dados já existem como itens de linha estruturados — a OC foi criada no sistema. Mas em um fluxo de trabalho de compras baseado em planilhas, as OCs chegam em vários formatos: PDFs gerados pelo sistema do próprio comprador, OCs enviadas por e-mail pelos fornecedores confirmando um pedido, ou documentos digitalizados de fornecedores menores que operam em papel. Colocar os dados da OC em um formato estruturado é o primeiro passo — e, para equipes baseadas em planilhas, é um passo que determina se o restante do pipeline é sequer possível.

As colunas de extração para 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 fornecedor, 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 aba de registro de OCs com dados estruturados — uma linha por OC, ou uma linha por item de linha, dependendo se você quer granularidade em nível de cabeçalho ou de linha para a conciliação. O guia de extração de OC única com o complemento do Google Sheets detalha a configuração das colunas e o primeiro fluxo de extração. Para equipes de alto volume processando dezenas de OCs de uma vez, o painel de processamento de OCs em lote aplica o mesmo mecanismo de extração em múltiplas OCs em uma única sessão.

A demonstração acima usa o modelo de pedido de compra — um conjunto pré-configurado de colunas de extração projetado para documentos de PC. Envie um pedido de compra e veja os campos serem preenchidos sem digitação. Se seus POs contiverem campos que o modelo não cobre (uma linha de sobretaxa de mercadoria, 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 modelo fornece o ponto de partida. Suas colunas personalizadas o estendem para atender aos requisitos do seu painel de correspondência.

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

O recebimento de mercadorias é o documento com maior probabilidade de estar ausente em um sistema estruturado — e é o documento que torna a correspondência de três vias um processo de três vias. Sem a confirmação de recebimento, você está fazendo a correspondência de duas vias (PC vs. fatura) e pagando por mercadorias que não pode confirmar que 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 na estrutura de controle.

Os dados de recebimento são mais difíceis de estruturar do que os dados de PC por causa de como são criados — no cais, muitas vezes em papel, por funcionários cuja prioridade é descarregar caminhões, não inserir dados. O romaneio é tipicamente um formulário de carbono de múltiplas vias ou um documento de impressão térmica da transportadora. O funcionário do recebimento assina, registra a quantidade recebida (às vezes em unidades diferentes das do PC) e arquiva a cópia física. Se esses dados entram em um sistema digital depende de alguém digitá-los depois — e essa etapa é a primeira a ser ignorada em um dia movimentado de recebimento.

Para o pipeline, os dados de recebimento têm dois caminhos de entrada viáveis. O primeiro é a inserção manual direta: o funcionário do recebimento — ou uma pessoa designada para entrada de dados — digita os campos-chave em uma Planilha Google como parte do fluxo de trabalho de recebimento. As colunas espelham as colunas do PC: Número do PC (para vincular de volta), Item Recebido, Quantidade Recebida, Data do Recebimento, Transportadora, Condição. Esse caminho 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 entrada, sem necessidade de conversão downstream.

O segundo caminho é a extração de documentos a partir do próprio 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 a entrada manual não é viável — docas de alto volume, locais remotos de recebimento ou operações em que 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 do 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 em 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 um detalhamento 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 que seja o caminho usado, o resultado é o mesmo: uma aba de registro de recebimento com o Número do PO como campo-chave que vincula cada recebimento ao seu pedido de compra de origem. Sem esse vínculo, o painel de correspondência não consegue fazer seu trabalho.

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 formatos de data, convenções de moeda e estruturas de linha de imposto diferentes. O OCR baseado em modelo — em que você cria um modelo de mapeamento de campos para o layout de cada fornecedor e o atualiza quando o layout muda — quebra sob essa 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 correspondência de três vias normalmente inclui:

Você também pode adicionar colunas inferidas — colunas que capturam dados não impressos explicitamente na nota fiscal, mas deriváveis de seu contexto. Por exemplo, uma coluna definida como Status de Correspondência (opções: Pronto para Corresponder/Precisa de Referência do Pedido/Itens Faltantes) permite que a IA classifique cada nota fiscal durante a extração com base se encontrou um número de pedido e se os itens foram extraíveis. Notas fiscais que chegam de fornecedores que não incluem números de pedido em seus documentos são sinalizadas imediatamente — elas entram no painel de correspondência com o status "Precisa de Referência do Pedido", e o funcionário de contas a pagar sabe que não deve tentar uma correspondência até que o número do pedido 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.

coluna calculada lida com cálculos que, de outra forma, exigiriam fórmulas de planilha após a extração. Defina uma coluna como Extension Check (Line Total - Quantity * Unit Price) e a IA realiza o cálculo durante a extração, sinalizando qualquer linha em que o total da linha faturada não seja igual à quantidade multiplicada pelo preço unitário. O resultado é 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 fatura do fornecedor. Isso muda o papel do painel de correspondência de "encontrar os erros" para "revisar as linhas sinalizadas" — um fluxo de trabalho em que a IA faz a detecção e o humano faz a disposição. Para um tratamento completo da sintaxe e dos recursos de coluna calculada, consulte nosso guia de colunas calculadas na extração de documentos.

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

O Painel de Correspondência: VLOOKUP, IF e Formatação Condicional

Com todas as três camadas preenchidas — registro de pedidos de compra, registro de recebimento e registro de faturas — o painel de correspondência é onde elas convergem. Esta é uma única aba que puxa 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 correspondência em si não é complexa. Uma planilha pode fazer isso. O que sempre foi complexo — e o que o pipeline resolve — é colocar os dados em um estado em que a planilha possa fazer isso. Para a contraparte focada em reconciliação deste pipeline — regras de tolerância, zonas de correspondência automática e a camada de julgamento humano para descrições ambíguas de itens — consulte nosso guia de correspondência de três vias no Google Sheets sem ERP.

A estrutura do painel de correspondência, criada no Google Sheets:

A formatação condicional transforma esta tabela em um painel: destaque a Coluna N em verde para "MATCHED", âmbar para "NO RECEIPT", vermelho para "VARIANCE". Aplique uma borda vermelha a qualquer linha onde a Coluna J (Variação de Quantidade) exceda um limite configurável — 5% para materiais a granel, 2% para componentes de engenharia de alto valor. Adicione um resumo na linha superior: =COUNTIF(N:N,"MATCHED") para contar faturas conciliadas, =COUNTIF(N:N,"VARIANCE") para exceções, =SUMIF(N:N,"VARIANCE",L:L) para o valor total em dólares das variações.

A decisão arquitetural chave é o Número do Pedido como chave universal. Cada VLOOKUP no painel de conciliação referencia a coluna de Número do Pedido. Se uma fatura de fornecedor não incluir um número de pedido — 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/A em todas as colunas VLOOKUP, imediatamente visíveis no painel. A correção é simples: adicione o número do pedido à linha do registro de faturas e as fórmulas recalculam. Mas a visibilidade é o ponto central. Sem o painel, uma fatura sem número de pedido 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 de manufatura, onde um pedido cobre múltiplos embarques — adicione uma coluna "Número da Entrega" tanto ao registro de recebimento quanto ao registro de faturas. O VLOOKUP se torna uma consulta de duas chaves: conciliar por Número do Pedido E Número da Entrega. Cada entrega parcial ganha sua própria linha de conciliação, e o cálculo de recebimento acumulado (=SUMIFS(F:F, A:A, A2, [Entrega], "<="&[@Entrega])) rastreia quanto da quantidade total do pedido foi entregue em todos os embarques parciais. A mesma lógica lida com pedidos abertos com liberações mensais contínuas — o painel rastreia quantidades acumuladas em relação à autorização total do pedido.

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 funcionário de contas a pagar baixa o anexo, salva em uma unidade compartilhada ou pasta local e, em seguida, faz o upload 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 ao fornecedor. O fornecedor abre o link, insere um código de verificação curto exibido na página e faz o upload da fatura diretamente — sem criar conta, sem login, sem instalação de software. O arquivo chega automaticamente à 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 fluxo de conciliação de três vias, um Link de Coleta muda o fluxo de documentos de "fornecedor envia fatura por e-mail → você baixa → você faz upload → você extrai" para "fornecedor faz upload diretamente → o arquivo aparece na sua fila → você extrai". Ele elimina completamente a etapa de baixar e reenviar. Para fornecedores que enviam vários documentos — um romaneio e uma fatura 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 a configuração detalhada e o 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:

• Entrada 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 linha 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 de nomes de colunas lê qualquer layout de documento sem modelos pré-configurados. Um novo fornecedor é integrado enviando a ele um Link de Coleta — sem necessidade de criar modelos.
• O ciclo de investigação entre três departamentos. Quando os 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 de formatação condicional, não ligando para compras e para o recebimento.
• Pontos cegos de documentos ausentes. A estrutura 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 faturas por mês, um painel de conciliação baseado em planilha 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, 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. Ele não as resolve. Uma diferença de R$ 47,50 entre o preço unitário faturado e o do PO pode ser uma sobretaxa legítima que o departamento de compras negociou, mas nunca comunicou ao AP, ou pode ser um erro. A IA não pode saber qual é — e não deve ser solicitada a decidir. O sinalizador aciona a revisão humana. A revisão exige contexto de negócios que a IA não possui.
• O processo de recebimento em si. Se os recebimentos de mercadorias não estão sendo criados — se o cais 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. Ele não os cria do nada.
• Conformidade do fornecedor com a exigência de número de PO na fatura. O pipeline torna visível a ausência de um número de PO. Ele 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 esse 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 conciliação. Um único auxiliar de contas a pagar revisando e tratando divergências consegue lidar confortavelmente com cerca de 300 a 500 notas fiscais por mês com um painel bem estruturado, assumindo uma taxa de exceção de 22% (66 a 110 exceções para investigar). Acima de 1.000 notas fiscais por mês, o volume de exceções exige ou vários auxiliares de contas a pagar ou a migração para um ERP com regras automatizadas de conciliação. O valor do pipeline em volumes maiores muda de "ferramenta principal de conciliação" 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 conciliação.

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, não uma extração única. Para um pedido de compra aberto com ajustes mensais de preço indexados a uma taxa de mercado, a linha do registro de pedidos de compra para aquele fornecedor precisa ser atualizada a cada mês com o preço vigente atual. O PROCV no painel de conciliação 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: extrair o preço do pedido de compra que estava em vigor na data da nota fiscal, 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 conciliação tripla deve verificar.

A extração funciona em romaneios e documentos de recebimento manuscritos?

Sim — a IA lê texto manuscrito, incluindo os números e anotações típicos 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 fraco, romaneios amassados e re-alisados) gerarão mais erros de extração. Para dados de recebimento especificamente, recomendamos: (a) se viável, que o conferente insira os campos-chave (Número do Pedido, Item, Quantidade, Data) diretamente na Planilha Google no cais — a entrada manual no ponto de recebimento é mais rápida e precisa do que a extração de um documento degradado posteriormente; (b) se a extração do romaneio for o único caminho viável, faça uma verificação pontual de uma amostra de linhas contra o documento original, especialmente para remessas de alto valor; (c) use a foto do romaneio como anexo armazenado junto com a 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 com o aplicativo web?

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

Qual é o tempo de configuração para o pipeline completo — registro de PO, registro de recebimento, registro de fatura e dashboard de correspondência?

Para alguém familiarizado com VLOOKUP 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 VLOOKUP e IF no dashboard de correspondência, 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 essa planilha. Após a configuração inicial, o fluxo mensal é: (1) extrair novos POs para o registro de PO, (2) inserir ou extrair dados de recebimento, (3) extrair faturas de fornecedores, (4) abrir o dashboard de correspondência e revisar as linhas sinalizadas. O primeiro mês é o mais demorado por causa da configuração e da população de dados. O terceiro mês é rotina. Para a descrição completa dos recursos — tipos de campo suportados, formatos e detalhes do plano — consulte a página de extração para o Google Sheets.

Como lidar com diferenças de moeda entre POs e faturas 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 o seu PO estiver em USD e um fornecedor emitir fatura em EUR, o painel de correspondência 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 POs quanto no registro de faturas, 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 na correspondência então usa 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.

A 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 meio de 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 suporta, 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 entre três departamentos".

O pipeline responde a essa pergunta com três camadas de extração e um painel. A camada de PO 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 tudo — com VLOOKUP, declarações IF 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 em vez da 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 no processo de captura de documentos.

A lacuna estrutural que nossa análise de problemas identificou — três departamentos, três sistemas, nenhum dono ú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 com a camada de extração de PO. Envie uma ordem de compra na demonstração abaixo. Veja se os campos que importam para o seu fluxo de correspondência — número do PO, fornecedor, itens de linha, quantidades, preços — voltam estruturados em segundos em vez de digitados em minutos. Se essa primeira camada funcionar, o restante do pipeline é construído no mesmo mecanismo.