Por que o Processamento de Faturas CFDI Mexicanas
É Mais Difícil do que a Maioria das Equipes Espera

Mais do que uma Simples Fatura Longa: O Problema de Superfície

Um CFDI (Comprobante Fiscal Digital por Internet) em conformidade com o Artigo 29-A do CFF não é meramente uma fatura longa. É um documento XML exigido pelo governo, cuja estrutura é definida pelo padrão técnico do Anexo 20 — uma especificação que, em sua versão atual CFDI 4.0, define mais de 100 possíveis elementos XML e múltiplas cadeias de validação condicional. Mas apontar a quantidade de campos como o problema ignora o que realmente retarda o processamento. A dificuldade não está no grande número de campos. A dificuldade está no fato de que os campos se relacionam entre si de maneiras que criam obrigações de rastreamento entre documentos, sistemas e momentos distintos.

Os sintomas são fáceis de identificar. Uma fatura é rejeitada pelo PAC (Proveedor Autorizado de Certificación) do seu fornecedor porque o RFC (Registro Federal de Contribuyentes — CPF/CNPJ mexicano) do destinatário não corresponde exatamente ao cadastro de contribuintes do SAT — uma diferença tão pequena quanto um acento faltando. Um pagamento que foi compensado no banco na semana passada não aparece em nenhuma fatura em aberto no seu razão, porque o pagamento foi emitido como um CFDI separado do tipo Pago referenciando o UUID (Identificador Único Universal) da fatura original, em vez de aparecer como um item de linha no documento original. Uma fatura processada pela sua equipe há três semanas acabou sendo cancelada pelo fornecedor — mas ninguém na sua empresa aceitou ou rejeitou a solicitação de cancelamento dentro da janela de 72 horas, então ela foi aprovada automaticamente. Seu lançamento no contas a pagar agora referencia um documento anulado.

Estes não são casos isolados. São as condições normais de operação ao processar faturas de fornecedores mexicanos em qualquer escala acima de algumas por mês. E elas não decorrem de más práticas dos fornecedores ou ferramentas de contas a pagar inadequadas, mas sim da arquitetura do próprio sistema CFDI — um sistema cujos objetivos de projeto foram visibilidade regulatória e fiscalização tributária, e não eficiência operacional para o lado receptor da transação.

Camada 1: A Arquitetura Regulatória que Torna Cada CFDI uma Minideclaração Fiscal

Na maioria dos países, uma fatura é um documento comercial: registra o que foi vendido, para quem e por quanto. A declaração fiscal vem depois — quando o vendedor entrega a declaração de IVA, quando o comprador contabiliza a despesa. No México, a fatura é a declaração fiscal. A distinção não é acadêmica. Ela altera quais informações devem estar presentes no momento da criação e quem deve verificá-las antes que o documento tenha validade legal.

O México opera o que pesquisadores de sistemas tributários chamam de modelo de aprovação em tempo real. De acordo com o Artigo 29, Seção IV do CFF, todo CFDI deve ser transmitido ao SAT (Serviço de Administração Tributária, a autoridade fiscal federal do México) antes de ser emitido ao destinatário. A transmissão passa por um PAC — um intermediário certificado pelo SAT — que valida a estrutura XML conforme as regras do Anexo 20, verifica se os RFCs do emissor e do receptor existem no cadastro ativo de contribuintes do SAT, confirma se o CSD (Certificado de Selo Digital) do emissor é válido e não foi revogado, checa se os cálculos fiscais são internamente consistentes e, só então, aplica o timbre fiscal digital (carimbo fiscal digital) e retorna o CFDI validado com seu UUID atribuído.

O que isso significa para sua equipe de contas a pagar é que cada CFDI recebido já passou por um ponto de verificação governamental. Os dados nele não são uma afirmação do fornecedor — são uma afirmação que o SAT já viu. Isso torna os dados mais confiáveis do que uma fatura típica. Também significa que erros nos dados — um RFC incorreto, um código de regime fiscal errado — não podem ser corrigidos pelo seu fornecedor com um PDF atualizado rápido. O CFDI incorreto deve ser cancelado por meio de um processo formal de cancelamento, e um novo deve ser emitido do zero.

Os dados obrigatórios não são apenas "nome, data, valor". O Artigo 29-A do CFF determina que todo CFDI do tipo Ingreso (fatura de receita) contenha: o RFC do emissor, razão social e código do regime fiscal (régimen fiscal); o RFC do receptor, razão social, código postal do domicílio fiscal e o código Uso CFDI declarando como o destinatário usará a fatura para fins fiscais; o local e data de emissão; um número de folio único; o selo digital do emissor; itens detalhados com quantidades, unidades de medida, códigos de classificação de produtos/serviços do SAT (ClaveProdServ), preços unitários e totais; um detalhamento completo de impostos por tipo (IVA — Imposto sobre Valor Agregado — transferências e retenções); forma de pagamento (Forma de Pago) e método de pagamento (Método de Pago, codificado como PUE para pagamento único ou PPD para pagamentos parcelados/diferidos); e o UUID e o timestamp de certificação.

Cada um desses campos é importante não apenas para seus registros, mas para os mecanismos de verificação cruzada do SAT. O RFC e o nome do receptor são verificados no cadastro de contribuintes do SAT. O código do regime fiscal — um identificador numérico como 601 para corporações, 612 para pessoas físicas com atividades empresariais, 605 para empregados assalariados — determina qual tratamento tributário se aplica a ambos os lados da transação. Uma incompatibilidade entre o regime declarado do emissor e o tipo de receita reportada pode acionar uma bandeira automática de auditoria. É por isso que seus fornecedores mexicanos são tão rigorosos em obter seu RFC e regime fiscal corretos antes de emitir uma fatura: eles não estão sendo burocráticos. Estão cumprindo um sistema que rejeita faturas contendo dados que não correspondem aos registros do SAT.

A reforma tributária de 2026 adicionou uma nova dimensão a esta camada. Uma nova disposição (Fracción IX) foi adicionada ao Artigo 29-A do CFF, em vigor a partir de 1º de janeiro de 2026, exigindo que os CFDIs reflitam transações reais e verdadeiras. Se um CFDI não representar um ato jurídico ou operação real, será considerado falso — com consequências que agora incluem responsabilidade criminal para emissores, receptores e intermediários. Isso eleva o risco de cada CFDI que sua empresa recebe: um fornecedor que emite uma nota fiscal por serviços não prestados não está apenas cometendo um erro de declaração. Ele está criando um documento que o SAT pode presumir falso, e o nome e RFC da sua empresa podem ser publicados como receptora de um CFDI falso, com 30 dias para corrigir suas declarações fiscais.

Complexidade da Camada 1, em resumo: o documento que você está processando não foi criado para você. Foi criado para a infraestrutura de monitoramento em tempo real do SAT. Seu fluxo de contas a pagar herda cada campo e cada validação exigida pelo SAT — independentemente de esses campos serem relevantes para sua contabilidade.

Camada 2: A Arquitetura do Documento — Por Que Uma Transação Gera Dois (ou Mais) XMLs

Se a camada regulatória adiciona campos obrigatórios, a camada de arquitetura do documento divide a própria transação em vários arquivos. É aqui que o processamento de CFDI mais se distancia do que uma equipe de contas a pagar treinada em formatos de nota fiscal dos EUA ou Europa espera.

A divisão começa com um campo chamado Método de Pago. Quando o valor é PUE (Pago en Una Sola Exhibición — pagamento em parcela única), o próprio CFDI de Ingreso registra a transação completa: bens ou serviços, valores, impostos e o fato de que o pagamento é liquidado integralmente no momento da emissão. Um documento, uma transação. Este é o CFDI mais próximo de uma nota fiscal comum.

Quando o valor é PPD (Pago en Parcialidades o Diferido — pagamento parcelado ou diferido), o CFDI de Ingreso registra apenas a obrigação. O pagamento real — quando ocorre, quanto, por qual método — é registrado em um CFDI separado do tipo Pago (pagamento), que contém o Complemento de Recepción de Pagos (Complemento de Recebimento de Pagamentos, às vezes chamado de Complemento de Pago). Este complemento referencia o UUID do CFDI de Ingreso original e registra: a data do pagamento, o valor pago, o método de pagamento (transferência, cheque, dinheiro, carteira eletrônica), a moeda e a taxa de câmbio, se aplicável, e o saldo restante após este pagamento.

Uma transação comercial agora gera dois XMLs que devem ser rastreados juntos. Se o pagamento for feito em três parcelas, gera quatro XMLs: um Ingreso e três CFDIs de Pago, cada um com seu próprio UUID, cada um referenciando o original por meio da estrutura do complemento. Conciliar isso significa combinar o UUID em cada complemento de Pago com o UUID do Ingreso original, somar os pagamentos parciais e confirmar que o saldo chega a zero. Se um CFDI de Pago faltar na sua caixa de entrada, o Ingreso aparecerá como não pago no seu razão indefinidamente — mesmo que o banco mostre o débito.

Essa estrutura de dois documentos gera problemas downstream que se agravam com o volume. No fechamento de fim de mês, uma equipe de AP processando 50 faturas de fornecedores mexicanos com termos PPD potencialmente tem 100 ou mais XMLs para reconciliar — cada um exigindo uma referência cruzada de UUID entre o Ingreso e seu(s) complemento(s) de Pago. Uma reconciliação manual significa abrir cada XML de Pago, encontrar o nó UUID referenciado, pesquisar no banco de dados de Ingresos processados por uma correspondência, verificar se os valores coincidem e marcar ambos como reconciliados. A três minutos por reconciliação, 50 pares PPD consomem duas horas e meia do tempo da equipe de AP — todo mês, para fornecedores de um único país.

Há outra dimensão de divisão de documentos: a relação entre o XML e a representação em PDF. De acordo com a lei mexicana, o arquivo XML — assinado digitalmente e carimbado pelo PAC — é o documento legalmente autoritativo. O PDF é uma representação visual regulamentada pelo SAT (deve incluir um código de barras bidimensional codificando um link para o portal de verificação do SAT), mas não tem peso legal independente. Se os dados no PDF diferirem dos dados no XML correspondente — o que pode acontecer quando os sistemas ERP do fornecedor renderizam o PDF a partir de um modelo que trunca ou reformata campos — o XML é o que o SAT considera correto. Uma equipe de AP que insere dados do PDF sem verificar o XML está, do ponto de vista de conformidade, processando uma impressão decorativa.

Para mais informações sobre o fluxo de extração de dados CFDI de XML e PDF para Excel, consulte nosso guia de extração de CFDI. Para lidar com faturas CFDI em lote — especialmente a referência cruzada de UUID entre complementos de Pago — consulte nosso guia de processamento de CFDI em lote.

Camada 3: A Armadilha do Cancelamento — Por Que Corrigir um Erro Leva 72 Horas e Duas Assinaturas

Na maioria dos ambientes de processamento de faturas, corrigir um erro significa que o fornecedor envia uma nota de crédito ou um PDF revisado, e o comprador registra o ajuste. No sistema CFDI, uma fatura emitida e timbrada não pode ser editada. Ela só pode ser cancelada — e o cancelamento é, por si só, um processo regulamentado que envolve ambas as partes, um sistema governamental e um prazo.

De acordo com as regras atuais, cancelar um CFDI exige que o emissor envie uma solicitação de cancelamento através do Buzón Tributário do SAT, especificando um dos quatro códigos de motivo padronizados: 01 — comprovante emitido com erros na relação (ou seja, o CFDI cancelado será substituído por um documento relacionado); 02 — comprovante emitido com erros não relacionados; 03 — a transação não foi realizada; 04 — operação nominativa relacionada em fatura global. O código 01 é o mais comum para correções comerciais e exige que o emissor especifique o UUID do CFDI substituto.

Uma vez enviada a solicitação de cancelamento, o receptor tem 72 horas (três dias úteis) para aceitá-la ou rejeitá-la. Se o receptor não tomar nenhuma ação, o cancelamento é aprovado automaticamente por tempo limite. Se o receptor rejeitar, o CFDI permanece legalmente ativo, e o emissor deve renegociar com o receptor ou recorrer aos canais de resolução de disputas do SAT.

Existem exceções limitadas onde a aprovação do receptor não é necessária: CFDIs de folha de pagamento (Nómina), faturas abaixo de MXN 1.000, transações com o público em geral (usando o RFC genérico XAXX010101000) e cancelamentos realizados dentro de 72 horas após a emissão original. Para todo o resto — qualquer CFDI de Ingreso comercial acima de MXN 1.000 — a janela de aceitação de 72 horas do receptor se aplica.

Para a equipe de contas a pagar (AP) receptora, isso cria dois riscos operacionais. O primeiro é o risco de documento anulado: um CFDI que você processou e contabilizou há três semanas pode ter sido cancelado pelo fornecedor e, como ninguém na sua organização acessou o Buzón Tributário do SAT para aceitar ou rejeitar a solicitação, ele foi aprovado silenciosamente. Seus livros agora contêm um lançamento respaldado por um documento fiscal anulado — uma constatação que o SAT tratará como uma despesa amparada por um CFDI inválido, desautorizando a dedução e potencialmente gerando impostos atrasados e multas.

O segundo é a lacuna de rastreamento de substituição: quando um fornecedor cancela um CFDI com o código de motivo 01, ele emite um CFDI substituto com um novo UUID. Sua equipe de AP agora precisa localizar o lançamento original, anulá-lo e reinserir o substituto — vinculando o novo UUID ao antigo. Se o substituto chegar em um tópico de e-mail diferente, com uma linha de assunto ligeiramente diferente, processado por um membro diferente da equipe, a conexão entre o original e o substituto é perdida, e ambas as versões podem acabar no seu sistema simultaneamente.

Camada 4: Dores de Cabeça com Múltiplos RFCs e Operações Transfronteiriças

As três camadas acima se aplicam a qualquer organização que receba faturas CFDI mexicanas. Para empresas multinacionais, há uma quarta complicação específica de como o sistema RFC interage com operações transfronteiriças.

Uma empresa com múltiplas entidades legais no México — uma subsidiária de manufatura, uma subsidiária de distribuição, uma entidade de serviços — terá um RFC separado para cada uma. Faturas CFDI enviadas para o RFC errado são legalmente endereçadas ao contribuinte errado. Um fornecedor emite a fatura para o RFC da subsidiária de manufatura, mas as mercadorias foram entregues e consumidas pela entidade de distribuição. A entidade de manufatura não pode deduzir legalmente a despesa porque a transação não ocorreu sob seu registro fiscal — e a entidade de distribuição não tem CFDI para respaldar seu custo das mercadorias. Corrigir isso exige um ciclo de cancelamento e reemissão, com todas as implicações de aceitação do receptor em 72 horas descritas acima.

Para empresas estrangeiras que recebem faturas CFDI de fornecedores mexicanos, mas não possuem RFC próprio, o RFC genérico para destinatário estrangeiro — XEXX010101000 — pode ser usado. Este RFC tem limitações importantes. Ele não permite que o destinatário solicite créditos de IVA ou deduza a despesa para fins fiscais mexicanos (o que, para uma empresa estrangeira sem obrigação de declaração fiscal no México, geralmente é irrelevante). Mais significativo operacionalmente: como XEXX010101000 é um identificador genérico usado por milhares de entidades não relacionadas, ele não fornece rastreabilidade de volta a uma entidade corporativa específica. Se sua empresa tem três escritórios regionais, cada um recebendo faturas CFDI de diferentes fornecedores mexicanos, todos usando XEXX010101000, não há uma maneira no nível do RFC de rotear as faturas para a entidade correta durante o processamento. A lógica de roteamento deve ser incorporada ao seu fluxo de trabalho de contas a pagar — dependendo do nome do fornecedor, do campo de descrição ou do destinatário do e-mail — nenhum dos quais tem a confiabilidade estrutural de um ID fiscal.

Há também o problema de incompatibilidade de regime fiscal no lado do receptor. Quando um fornecedor mexicano emite um CFDI, ele deve registrar o código de regime fiscal do receptor. Se sua empresa obteve um RFC para uma entidade mexicana, essa entidade está registrada sob um regime específico — digamos, 601 (Regime Geral para Pessoas Jurídicas). Se o fornecedor inserir erroneamente 612 (Pessoas Físicas com Atividades Empresariais) porque alguém forneceu o código errado durante a integração, o CFDI pode ainda passar pela validação do PAC (já que 612 é um código de regime válido), mas conterá um erro estrutural de dados que o SAT pode sinalizar durante uma auditoria futura. O CFDI é válido, mas incorreto — o tipo de erro mais difícil de detectar antes que se torne um problema.

Para uma análise do desafio mais amplo de processar documentos em mercados de língua espanhola, veja nossa visão geral da extração de documentos em mercados hispânicos.

Por que abordagens baseadas em template falham no CFDI

Uma resposta comum à complexidade do processamento de faturas é o OCR baseado em template: definir um modelo para o layout de cada fornecedor, mapear campos para posições e extrair dados por coordenadas. Essa abordagem pressupõe que o formato do documento é consistente o suficiente para que um modelo treinado em uma amostra funcione nas próximas cem. O CFDI quebra essa suposição em duas frentes.

Primeiro, a representação em PDF varia conforme o fornecedor. Embora todo CFDI contenha os mesmos campos obrigatórios definidos pelo Anexo 20, o ERP ou sistema de faturamento de cada fornecedor renderiza o PDF de forma diferente. Um fornecedor coloca o UUID no canto superior direito como uma string de 36 caracteres. Outro o insere apenas no código QR na parte inferior. Um terceiro o imprime em fonte condensada no rodapé. Um modelo criado para o layout do Fornecedor A falha completamente na fatura do Fornecedor B.

Segundo, o PDF e o XML podem conter dados diferentes. O ERP de um fornecedor pode renderizar o PDF a partir de um subconjunto dos campos do XML — mostrando o total do item, mas não o detalhamento do IVA, exibindo o nome fantasia do fornecedor em vez da razão social registrada. Se sua ferramenta de extração lê o PDF, ela captura os dados impressos simplificados. Se sua obrigação de conformidade exige o detalhamento fiscal completo do XML, o PDF é insuficiente. Uma equipe de AP conciliando com o PDF está conciliando com menos dados do que o SAT considera o registro oficial.

A abordagem que lida com essa variabilidade estrutural é aquela que lê o conteúdo do documento — o significado semântico de campos como UUID, RFC, IVA 16%, Regime Fiscal — independentemente de onde aparecem na página e independentemente de a fonte ser um PDF ou XML. A extração semântica identifica um RFC não porque está nas coordenadas (200, 450), mas porque corresponde ao padrão de um identificador alfanumérico de 12 ou 13 caracteres rotulado como "RFC" no texto ao redor. Essa é a diferença entre mapear posições visuais e entender o conteúdo do documento — e é a diferença que torna o processamento de CFDI viável em escala, em vez de um fardo de manutenção de modelos por fornecedor.

O Que Isso Significa para o Fluxo de Contas a Pagar no México

Unindo as quatro camadas, um fluxo de processamento de CFDI que considere todas elas exige capacidades que a maioria dos sistemas de AP padrão — construídos sob a premissa de que uma fatura é um documento único, autocontido e sem estado — não oferece nativamente.

Ingestão em múltiplos formatos. O fluxo deve aceitar tanto XML quanto PDF como entrada, pois os fornecedores entregam ambos e os dados oficiais estão no XML. Extrair apenas do XML descarta a etapa de verificação visual (o documento impresso corresponde aos dados estruturados?). Extrair apenas do PDF descarta o registro legal. Ambos os formatos devem alimentar o mesmo pipeline de extração, gerando uma linha de saída unificada por CFDI.

Reconciliação com ciência de UUID. O UUID — o identificador de 36 caracteres embutido em cada CFDI — é a chave permanente que vincula faturas de Ingreso aos seus complementos de Pago, rastreia cancelamentos e conecta cada documento ao portal de verificação do SAT. Um fluxo de CFDI que não capture, armazene e faça referência cruzada de UUIDs entre lotes não consegue realizar reconciliação de pagamentos PPD sem consultas manuais. Para fluxos de reconciliação em lote, consulte nosso guia de processamento de CFDI em lote.

Validação de regime e RFC na entrada. Antes de um CFDI entrar no seu sistema contábil, o RFC do receptor e o código do regime fiscal devem ser validados contra os dados registrados da sua empresa. Uma incompatibilidade detectada na entrada evita uma cascata: a despesa é contabilizada na entidade errada, a equipe fiscal descobre o erro durante a preparação da auditoria, e a correção envolve um ciclo de cancelamento e reemissão com um fornecedor que pode não estar mais disponível.

Consciência do status de cancelamento. Um CFDI processado não é um CFDI liquidado permanentemente. Fluxos que incluem verificações periódicas de status do UUID no portal do SAT — ou que exigem que os fornecedores notifiquem sua equipe sobre solicitações de cancelamento por um canal definido — reduzem o risco de manter documentos anulados no seu razão.

Nada disso exige uma integração PAC de nível empresarial ou uma plataforma dedicada de conformidade fiscal mexicana. O que é necessário é uma etapa de processamento que entenda o que é um CFDI — um registro multifacetado, com estado e validado pelo governo — e extraia seus dados de acordo, em vez de tratá-lo como um PDF longo com números extras.

Perguntas Frequentes

Por que fornecedores mexicanos não podem simplesmente emitir uma nota fiscal em PDF normal?

Porque a lei mexicana não reconhece um PDF como documento fiscal válido. Desde 2014, todos os contribuintes no México — empresas, profissionais autônomos e pessoas físicas com atividades comerciais — são obrigados a emitir notas fiscais CFDI em XML validadas por um PAC e registradas no SAT em tempo real. Um fornecedor que emite apenas um PDF não está produzindo um documento fiscal legalmente válido de acordo com a lei tributária mexicana, e você não pode usar tal documento para embasar uma dedução fiscal no México.

Qual é a diferença prática entre PUE e PPD?

PUE (pagamento único) significa que a nota fiscal é quitada integralmente no momento da emissão — um CFDI cobre toda a transação. PPD (pagamento diferido/parcelado) significa que a nota fiscal registra a obrigação, e cada pagamento subsequente gera um CFDI separado do tipo Pago com seu próprio UUID e um Complemento de Pago referenciando o original. PPD exige o rastreamento de pelo menos dois XMLs por transação; PUE exige apenas um. O código do método de pagamento (PUE ou PPD) aparece no campo Método de Pago do CFDI de Ingreso.

Preciso guardar o XML ou o PDF é suficiente para nossos registros?

Você precisa do XML. De acordo com o Artigo 30 do CFF, tanto o emissor quanto o receptor devem reter os arquivos XML do CFDI por pelo menos cinco anos. O PDF é uma representação visual regulamentada — deve incluir um QR code que leva ao portal de verificação do SAT — mas não possui valor legal independente. Em uma auditoria, o SAT solicitará o XML, não o PDF.

O que acontece se eu ignorar uma solicitação de cancelamento de um fornecedor?

Se você não responder em até 72 horas (três dias úteis), o cancelamento é aprovado automaticamente por tempo limite. O CFDI torna-se nulo, e qualquer dedução fiscal ou lançamento de despesa em seu sistema amparado por esse CFDI não terá mais respaldo de um documento fiscal válido. Se sua empresa declara impostos no México, isso gera uma exposição de conformidade. Se sua empresa não declara no México, o risco operacional é pagar por uma nota fiscal cancelada sem perceber.

Posso usar o RFC genérico XEXX010101000 para todas as notas fiscais de fornecedores mexicanos?

Sim, se sua empresa não possui registro fiscal no México nem um RFC mexicano próprio. No entanto, XEXX010101000 é um identificador genérico compartilhado por todos os destinatários estrangeiros — ele não oferece rastreabilidade em nível de entidade. Se sua empresa possui vários escritórios, departamentos ou entidades que recebem faturas CFDI, você precisará de um mecanismo de roteamento interno (baseado no nome do fornecedor, descrição ou e-mail) para direcionar cada fatura para a fila de processamento correta.

A complexidade do CFDI é pior que a de outros sistemas de faturamento eletrônico?

O sistema do México está entre os mais rigorosamente controlados do mundo, ao lado do NF-e brasileiro. Ambos usam autorização governamental em tempo real, ambos exigem XML estruturado com assinaturas digitais, e ambos criam obrigações de conciliação entre faturas originais e documentos de pagamento ou transporte subsequentes. A complexidade específica do sistema mexicano reside na estrutura de duplo documento PPD/Pago e no mecanismo de cancelamento com aceitação do destinatário — funcionalidades que não têm equivalente direto na maioria das exigências europeias de faturamento eletrônico.