Por que seu ERP rejeita seu
Excel extraído: 5 causas comuns e soluções

Este é um dos momentos mais frustrantes na automação de contas a pagar: a extração funcionou, mas a importação falhou. O problema quase nunca é que os dados foram extraídos incorretamente. O problema é uma incompatibilidade de formato entre o que sua ferramenta de extração gera e o que seu ERP espera. Cada ERP — SAP, Oracle NetSuite, Microsoft Dynamics 365, Oracle Cloud ERP — tem sua própria especificação para formato de data, formato de valor, tamanho do campo de código, identificação do fornecedor e campos obrigatórios. Sua saída de extração de dados não sabe qual você usa, a menos que você informe.

Este guia aborda os cinco motivos pelos quais seu ERP rejeita a saída da extração e como corrigir cada um antes de clicar em "importar".

1 Causa 1: O formato da data não corresponde ao que seu ERP espera

Os sintomas

Sua importação falha com erros como "Valor de data inválido no campo Data da Fatura" (SAP), "Campo de data não está no formato de data preferido" (NetSuite) ou "Os dados de origem não estão no formato exigido" (Dynamics 365). Ou pior — a importação é bem-sucedida, mas uma fatura de 7 de março é lançada como 3 de julho porque o ERP interpretou 03/07/2026 de forma diferente da sua.

Por que isso acontece

Cada ERP armazena datas internamente em seu próprio formato, e todos esperam que seu arquivo de importação corresponda a um layout de data específico:

A verdadeira armadilha é o tratamento automático de datas do Excel. Ao abrir um CSV contendo 07/03/2026, o Excel pode interpretá-lo como um número de série (um número como 46142) dependendo da sua localidade do sistema. Esse número de série parece correto quando você olha para a célula (o Excel o exibe como uma data), mas o valor real na célula é um número. Quando o ERP lê o CSV, ele vê 46142, não uma data — e rejeita a linha. Esse problema de data serial do Excel é uma das causas ocultas mais comuns de falha de importação.

A correção

A correção mais confiável é exportar as datas como texto. Na configuração de colunas da sua ferramenta de extração, especifique o formato exato de saída. Para SAP, nomeie sua coluna como Invoice Date (output as YYYYMMDD text). Para NetSuite, Invoice Date (output as MM/DD/YYYY text, zero-padded). No ImageToTable.ai, isso é feito pelo nome da coluna ou pela Regra de Formato — basta incluir a instrução de formato.

Antes de importar, certifique-se de que as colunas de data estejam formatadas como Texto na sua planilha, e não como Data. Não clique duas vezes para abrir arquivos CSV no Excel — use o Assistente de Importação de Texto ou o Power Query, onde você pode definir explicitamente o tipo de dados de cada coluna.

2 Causa 2: Símbolos de Moeda e Separadores de Milhar em Campos de Valor

Os sintomas

O erro exibe "Insira um número válido" ou "A coluna Valor contém caracteres inválidos." Ou a importação é bem-sucedida, mas os valores aparecem como zeros — porque o ERP removeu os caracteres não numéricos e ficou sem nada que pudesse interpretar.

Por que acontece

As ferramentas de extração preservam o que veem: $1.234,56 ou € 2.500,00. Mas os ERPs esperam valores numéricos brutos:

• NetSuite: Sem símbolos de moeda, sem vírgulas, sem separadores de milhar. Valores negativos devem usar sinal de menos ou parênteses.
• SAP: Ponto como separador decimal na maioria das configurações. Separadores de milhar não são permitidos.
• Dynamics 365 F&O: Valores decimais limpos são necessários. O pipeline DMF assume dados pré-formatados.

O problema da vírgula versus ponto é traiçoeiro. Um valor europeu de € 2.500,00 (ponto como separador de milhar, vírgula como decimal) torna-se 2.5 em um ERP configurado nos EUA que lê o ponto como decimal. A diferença entre 2.500,00 e 2.500,00 é um fator de mil — razão pela qual problemas com símbolo de moeda e ponto decimal na saída de OCR causam falhas de importação difíceis de diagnosticar.

A correção

Configure a saída da extração para remover símbolos e separadores. Especifique: "saída como número simples com duas casas decimais, sem símbolo de moeda, sem separador de milhar, ponto como decimal". Se seu ERP usa vírgula como decimal (comum em implementações SAP europeias), especifique isso explicitamente. O pós-processamento do ImageToTable.ai lida com ambas as convenções — você só precisa informar qual usar.

3 Causa 3: Campos de Código Perderam Zeros à Esquerda ou Usam o Formato Errado

Os sintomas

Seu ERP tem um código de fornecedor 0000000123, mas o arquivo extraído contém 123. Ou o número do pedido de compra aparece como PO-00123 enquanto o sistema espera 00123. A importação falha com "Registro não existe" ou — pior — o ERP cria um novo registro de fornecedor porque não conseguiu corresponder ao código.

Por que acontece

Dois problemas se combinam aqui. Primeiro, o Excel remove zeros à esquerda de qualquer coisa que considera um número — 0000000123 vira 123 no momento em que o CSV abre. Segundo, a extração preserva literalmente o que está no documento: se a fatura mostra PO-00123, a ferramenta gera PO-00123, mas o ERP espera apenas 00123 ou um formato de prefixo diferente.

A correção

Use o formato Texto para colunas de código. Antes de salvar seu CSV ou abri-lo no Excel, garanta que todos os campos de código — códigos de fornecedor, números de PO, números de fatura — estejam explicitamente formatados como Texto. No Excel, isso significa destacar a coluna, escolher Formatar Células > Texto e reinserir os valores. Em sua ferramenta de extração, especifique que os campos de código devem ser gerados como texto com preenchimento de zeros à esquerda, assim como você faria ao extrair campos de fatura para uso direto no ERP.

Para sistemas como SAP que usam números de conta de fornecedor com 10 dígitos, especifique: "Código do Fornecedor: saída como string de 10 caracteres, preenchida com zeros à esquerda". Defina o preenchimento e a remoção de prefixo como regras de formato em sua ferramenta de extração para que isso aconteça automaticamente em cada lote. Se sua ferramenta não suportar regras de formato, use =TEXT(A1, "0000000000") no Excel antes de salvar o CSV.

4 Causa 4: Nome ou Código do Fornecedor Não Corresponde aos Dados Mestres do seu ERP

Os sintomas

O NetSuite retorna "Invalid entity reference key". O SAP exibe "Vendor 123 not defined in company code." O Sage 300 informa "Vendor cannot be blank." O fornecedor existe no seu ERP — o sistema apenas não consegue associar o que está no seu arquivo de importação ao registro mestre.

Por que acontece

A correspondência de fornecedores é um dos pontos de falha de importação mais comuns e frustrantes. As causas são sutis:

• Espaços em branco à direita: Sua extração gera "Acme Corp " (com um espaço no final), mas o registro do fornecedor é "Acme Corp". A correspondência de strings no ERP é exata e diferencia maiúsculas de minúsculas.
• Diferença de abreviação: A fatura diz "Acme Corp", mas o registro no ERP é "Acme Corporation".
• ID interno necessário: O NetSuite e alguns outros ERPs podem importar pelo nome do fornecedor, mas a correspondência é mais rápida e confiável usando o ID interno do fornecedor (uma chave numérica que nunca muda).
• Fornecedor ainda não existe: O registro do fornecedor não foi criado no ERP. Nenhuma formatação resolverá isso.
• Incompatibilidade entre entidades legais: No Dynamics 365 F&O, o fornecedor deve existir na entidade legal específica para a qual você está importando — não apenas em algum lugar do locatário.

A solução

A abordagem mais confiável é usar IDs internos em vez de nomes. Exporte uma lista de fornecedores do seu ERP, crie uma tabela de consulta e configure sua ferramenta de extração para gerar o ID interno diretamente. No ImageToTable.ai, inclua uma coluna inferida: "ID do Fornecedor: consultar o nome do fornecedor na lista anexada e gerar o ID interno".

Se IDs internos não forem uma opção, implemente a correspondência aproximada (fuzzy matching) com uma lista de referência. Isso elimina problemas de espaços à direita e abreviações antes que eles cheguem ao ERP.

Se o fornecedor ainda não existir, a importação sempre falhará — a solução é criar o registro do fornecedor primeiro.

5 Causa 5: Um Campo Obrigatório Está Faltando na Sua Saída de Extração

Os sintomas

"Insira um valor para Valor." "O campo Conta Contábil é obrigatório." "O código do imposto deve ser especificado." Esses erros significam que o ERP espera um campo que sua saída de extração simplesmente não contém.

Por que acontece

Nem todo campo obrigatório no modelo de dados do seu ERP está impresso no documento. Uma fatura pode não exibir o código da conta contábil. A data de vencimento pode estar ausente, mas é obrigatória no diário de fatura de fornecedor do Dynamics 365. Códigos de imposto necessários para lançamento no SAP podem não estar listados na fatura do fornecedor.

Ferramentas de extração extraem o que está visível. Se um campo obrigatório não está no documento, a saída ficará em branco — e o ERP rejeitará a linha. Isso é comum em faturas que omitem códigos de conta contábil ou datas de vencimento — um problema que configurações eficazes de automação de contas a pagar resolvem pré-configurando valores padrão.

A solução

É aqui que colunas inferidas e valores padrão se tornam essenciais. Uma coluna inferida diz à IA: "Se este campo não estiver no documento, use este padrão — ou infira a partir do contexto."

No ImageToTable.ai, você pode adicionar colunas como:

• Conta Contábil (padrão: 4010 se não estiver no documento)
• Código do Imposto (inferir do país do fornecedor)
• Data de Vencimento (se não impressa, calcular como Data da Fatura + 30 dias)
• Moeda (inferir do contexto do documento)

A IA lê o documento, extrai o que encontra, preenche as lacunas com suas regras ou padrões, e a saída chega com todos os campos obrigatórios preenchidos.

O segredo é saber quais campos seu ERP considera obrigatórios. Baixe o modelo de importação dele, mapeie as colunas obrigatórias para sua configuração de extração e defina padrões para qualquer coisa não impressa no documento.

O Caminho Mais Inteligente: Crie Modelos de Exportação Prontos para ERP

Corrigir cada causa individualmente funciona, mas é reativo. A abordagem mais inteligente é um modelo de exportação pronto para ERP — uma única configuração de extração que gera dados exatamente no formato que seu ERP espera.

Um modelo pronto para ERP inclui:

1. Cabeçalhos de coluna idênticos ao modelo de importação do seu ERP. Se o Dynamics 365 espera VENDORACCOUNT, esse é o cabeçalho da sua coluna.
2. Campos de código como texto com zeros à esquerda. Números de PO, códigos de fornecedor e números de fatura chegam com o comprimento exato usado pelo seu ERP.
3. Campos de valor como números simples. Sem símbolos, sem vírgulas, ponto como separador decimal.
4. Todos os campos obrigatórios presentes. Campos ausentes preenchidos com valores padrão ou inferidos.
5. Datas como strings de texto. Sem números seriais do Excel, sem interpretações dependentes de localidade.

Uma vez configurado, cada lote gera automaticamente dados prontos para importação. A etapa de limpeza manual — onde a maioria dos erros reside — desaparece completamente.

Quando Escalar: Reconhecendo Problemas de Formato Fora do Seu Controle

A maioria das falhas de importação de ERP a partir de dados extraídos se enquadra nas cinco causas acima, e a maioria é corrigível com a configuração certa. Mas às vezes o formato não é o problema real:

• Lógica de validação complexa. A combinação de conta contábil, código de imposto e entidade legal pode não passar nas regras de validação — um problema de configuração do ERP, não de dados.
• Fluxo de trabalho e aprovações. Se a importação for bem-sucedida, mas a fatura ficar presa em "Aprovação Pendente", o problema é o design do fluxo de trabalho.
• O erro continua mudando. Se você corrige um erro e um novo aparece, a causa raiz pode ser dados mestre incompletos.

Corrija o formato dos dados primeiro — é o mais fácil de descartar — e depois escale os problemas restantes para o administrador do seu ERP.

Perguntas Frequentes

Pare de Corrigir, Comece a Prevenir

O padrão é sempre o mesmo: extrair → importar → falhar → corrigir um campo → reimportar → próximo erro. Cada ciclo custa de 15 a 30 minutos, e quando você processa dezenas de notas fiscais por lote, as horas perdidas se acumulam rapidamente.

As cinco causas neste guia cobrem cerca de 90% das falhas de importação de ERP a partir de dados extraídos. Corrija-as uma vez na sua configuração de extração, e cada lote subsequente chegará pronto para importar. O gargalo muda da compatibilidade de formato para onde deveria estar: obter os dados do documento para o seu sistema.

Teste seu modelo no próximo lote. Se os erros pararem, está resolvido. Se não pararem, o problema restante provavelmente é uma regra de validação do ERP — não os dados.