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

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 conselhos de ERP não se aplicam a fluxos de trabalho com planilhas

O módulo MM da SAP, o Oracle E-Business Suite e o Microsoft Dynamics 365 — todos incluem módulos de conciliação de três vias com tolerâncias configuráveis. A SAP, por exemplo, gerencia 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 existam 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 descobriu 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 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 conciliação possa começar.

Se você está nesse grupo — seja porque sua empresa gerencia 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 para manter, ou porque sua base de fornecedores inclui muitos pequenos fornecedores para os quais o PDF é o único formato enviado — o módulo de conciliação do seu 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 maneira de obter 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 rastrear compras é provavelmente uma planilha. A questão é como transformar essa planilha em um pipeline.

A Arquitetura de Pipeline de Três Camadas

O pipeline tem três camadas — uma para cada documento na conciliação de três vias — 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 pode 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 a pagamento. A camada do pedido estabelece a base — o que foi pedido, a que preço, de quem. A camada de recebimento confirma o que chegou fisicamente. A camada da fatura captura o que o fornecedor cobrou. O painel de conciliação é onde todas 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 Pedido", "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 pedido estruturado da saída PDF do SAP e um pedido manuscrito de um fornecedor local não se parecem em nada. Mas ambos contêm número do pedido, 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 diferentes de documentos de fornecedores.

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

Todo three-way match começa com o pedido de compra (PO). O PO 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 — o PO foi criado no sistema. Mas em um fluxo de compras baseado em planilhas, os POs chegam em vários formatos: PDFs gerados pelo sistema do comprador, POs enviados por e-mail pelos fornecedores confirmando um pedido, ou documentos digitalizados de fornecedores menores que ainda usam papel. Extrair os dados do PO para um formato estruturado é o primeiro passo — e, para equipes que usam planilhas, é uma etapa que determina se o restante do processo será viável.

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

Para pedidos de compra gerados internamente em um formato consistente — o modelo de PO da sua própria empresa — a extração é direta. A IA lê os mesmos campos do mesmo layout geral todas as vezes. Para POs 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 PO com dados estruturados — uma linha por PO, ou uma linha por item de linha, dependendo se você deseja granularidade no nível do cabeçalho ou do item para conciliação. O guia de extração de PO único com o complemento do Google Sheets detalha a configuração das colunas e o primeiro fluxo de extração. Para equipes de alto volume que processam dezenas de POs de uma só vez, o painel de processamento em lote de POs aplica o mesmo mecanismo de extração em vários POs em uma única sessão.

A demonstração acima usa o preset de pedido de compra — um conjunto pré-configurado de colunas de extracção concebido para documentos PO. Carregue um pedido de compra e veja os campos a preencherem-se sem necessidade de digitar. Se os seus PO contiverem campos que o preset não cobre (uma linha de sobretaxa de mercadoria, uma secção de termos de frete, códigos internos de centro de custo), adicione-os como colunas personalizadas — o motor de extracção trata-as da mesma forma. O preset dá-lhe o ponto de partida. As suas colunas personalizadas estendem-no para corresponder aos requisitos do seu painel de correspondência.

Camada 2 — Dados do Relatório de Recebimento: O Documento Intermédio Complicado

A guia de recebimento é o documento com maior probabilidade de faltar num sistema estruturado — e é o documento que torna a correspondência tripla um processo de três vias. Sem confirmação de recebimento, está a fazer correspondência dupla (PO vs. fatura) e a pagar por mercadorias que não pode confirmar que foram entregues. A ACFE identifica especificamente a guia de recebimento como o controlo que previne a fraude de faturação — pagar por mercadorias nunca enviadas. Ignorá-la não é um atalho. É uma lacuna no quadro de controlo.

Os dados de recebimento são mais difíceis de estruturar do que os dados de PO devido à forma como são criados — na doca, muitas vezes em papel, por funcionários cuja prioridade é descarregar camiões, não introduzir dados. A guia de remessa é tipicamente um formulário de carbono de múltiplas vias ou um documento de impressão térmica da transportadora. O funcionário de recebimento assina-a, regista a quantidade recebida (por vezes em unidades diferentes das do PO) e arquiva a cópia física. Se esses dados chegam a um sistema digital depende de alguém os digitar posteriormente — e esse passo é o primeiro a ser ignorado durante um dia de recebimento movimentado.

Para o pipeline, os dados de recebimento têm duas vias de entrada viáveis. A primeira é a introdução manual direta: o funcionário de recebimento — ou uma pessoa designada para introdução de dados — digita os campos-chave numa Folha Google como parte do fluxo de trabalho de recebimento. As colunas espelham as colunas do PO: Número do PO (para ligação de volta), Item Recebido, Quantidade Recebida, Data de Recebimento, Transportadora, Condição. Esta via funciona quando o volume de recebimento é moderado (menos de 30 envios por dia) e a doca tem acesso a um dispositivo com a Folha aberta. A vantagem é o controlo — os dados de recebimento são estruturados desde o momento da introdução, sem necessidade de conversão a jusante.

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 de recebimento remotos 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 através do 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 da 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 pode 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 — 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 coluna de fatura para correspondência tripla 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.

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 corresponda à quantidade vezes o 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 conciliação de "encontrar os erros" para "revisar as linhas sinalizadas" — um fluxo 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, veja nosso guia de colunas calculadas na extração de documentos.

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

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

Com todas as três camadas preenchidas — registro de PO, registro de recebimento e registro de fatura — o painel de conciliação é onde elas convergem. Esta é uma única aba que puxa dados de todas as três abas de origem usando funções de procura 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 pode 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, construída 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 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 do AP 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 para um 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 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 muda o fluxo de documentos de "fornecedor envia fatura por e-mail → você baixa → você faz upload → você extrai" para "fornecedor faz upload diretamente → 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 coluna 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:

• 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 Planilhas — apenas o aplicativo web?

Sim. O mecanismo de extração é o mesmo, seja acessado pelo complemento na barra lateral do Planilhas 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 conciliação. 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 Planilhas. Escolha com base 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 notas fiscais e painel de conciliação?

Para alguém familiarizado com PROCV e formatação condicional no Google Planilhas, construir 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 métricas resumidas, 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 é o mais demorado devido à configuração e ao preenchimento de dados. O terceiro mês já é rotina.

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 seu PO está em USD e um fornecedor 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 ao registro de PO quanto ao registro de faturas, e uma coluna "Taxa de Conversão" que referencie uma taxa de câmbio mantida manualmente ou alimentada por fórmula. A comparação de preços de correspondência então usa o valor convertido em vez do valor bruto extraído. O trabalho do pipeline é extração. A conversão de moeda é uma operação na camada da planilha.

A Conclusão

O pipeline de correspondência tripla 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 sua base de fornecedores abrange formatos que seu módulo de correspondência não consegue lidar, ou porque seu 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 todos 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 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 os compara — com VLOOKUP, instruçõ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 vários fornecedores. O Collection Link elimina o loop de download de anexos de e-mail do processo de recebimento de documentos.

A lacuna estrutural que nossa análise do problema identificou — três departamentos, três sistemas, nenhum proprietário único do pipeline de dados — não desaparece. Mas quando todos 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. Faça upload de uma ordem de compra na demonstração abaixo. Veja se os campos importantes para seu fluxo de correspondência — número do PO, fornecedor, itens de linha, 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 no mesmo mecanismo.