Em 31 de julho de 2026 saiu o primeiro CNPJ alfanumérico emitido pela Receita Federal, sob a Instrução Normativa RFB nº 2.229/2024. Doze caracteres alfanuméricos seguidos de dois dígitos verificadores numéricos, no lugar dos catorze dígitos que todo pipeline de glosa trata hoje como inteiro, ou como string de dígitos que se comporta como inteiro em todo lugar que importa: ordenação, comparação, geração de dígito verificador, chave de join.
A estrutura exata está no material técnico da Receita Federal, e a Abramed confirma o alcance dentro do TISS: a mudança atinge o Componente de Comunicação do Padrão, não o Componente de Conteúdo e Estrutura. Isso soa como boa notícia, porque os XMLs de guia continuam com o mesmo layout de campos. Não é bem assim.
Comunicação é exatamente a camada que carrega remetente e destinatário de toda transação TISS, e é ali que o CNPJ de prestador e operadora circula em todo envio, retorno, lote e recurso. Trocar o tipo desse campo não é um detalhe de camada de transporte. É mudar o tipo de uma chave que atravessa o pipeline inteiro.
CNPJ alfanumérico transforma a chave em string
A maior parte dos sistemas de glosa que conheço guarda CNPJ como NUMERIC(14) ou como CHAR(14) validado por regex ^\d{14}$. Os dois quebram com o novo formato, porque a Receita Federal define a estrutura como AA.AAA.AAA/AAAA-DV: doze posições que podem ser numerais de 0 a 9 e letras maiúsculas de A a Z, mais dois dígitos verificadores. Um CNPJ novo como 12ABC34501DF35 é uma string legítima e não passa em nenhuma das duas validações antigas.
// validação antiga, rejeita CNPJ alfanumérico
const valido = /^\d{14}$/.test(cnpj);
// validação que aceita os dois formatos
const valido = /^[0-9A-Z]{12}\d{2}$/.test(cnpj);Qualquer coluna tipada como numérico rejeita a inserção. Qualquer regex ancorada em \d{14} rejeita a validação. Nenhum dos dois erra de forma silenciosa, o que é uma vantagem real: a falha aparece em log de ingestão, não em relatório de glosa com CNPJ nulo três etapas depois.
Vale registrar a admissão honesta aqui. Se sua base de dados já trata CNPJ como VARCHAR desde o início, prática mais comum do que se assume em sistemas mais novos, essa parte do problema já está resolvida. O que sobra é o dígito verificador, e ele não sobra pouco.
O dígito verificador não é mais aritmética de escola
O algoritmo de dígito verificador do CNPJ numérico é módulo 11 sobre dígitos puros, e qualquer desenvolvedor de sistema fiscal brasileiro já implementou isso de memória. O novo algoritmo mantém módulo 11, mas insere um passo antes: cada caractere alfanumérico é convertido para valor numérico via código ASCII menos 48. A letra "A" (ASCII 65) vira 17 para efeito de cálculo. Só depois dessa conversão entram os pesos decrescentes de 9 a 2, a soma dos produtos, e o cálculo do resto módulo 11, repetido duas vezes para os dois dígitos verificadores.
Isso significa que toda rotina de validação de CNPJ escrita para o formato antigo, e existem dezenas delas copiadas e coladas entre projetos há quinze anos, precisa ser reescrita, não adaptada. Não é trocar um parâmetro de tamanho de string. É trocar a função de conversão de caractere para número antes mesmo de o módulo 11 rodar.
Dois formatos convivem para sempre, isso não é migração com fim
Aqui está o ponto que a maioria dos comunicados de fornecedor de sistema deixa passar batido. Não existe reemissão de CNPJ existente. Todo CNPJ numérico já emitido continua exatamente como está, permanentemente. A atribuição de formato para CNPJ novo é aleatória, e a Receita Federal já indicou que registros novos podem sair numéricos ou alfanuméricos, sem ordem previsível.
Na prática, isso quer dizer que seu pipeline de glosa não vai fazer uma migração de formato A para formato B com data de corte. Ele vai precisar aceitar os dois formatos, na mesma tabela, na mesma coluna, indefinidamente. Toda lógica que assume "CNPJ é sempre numérico" ou "CNPJ alfanumérico só aparece a partir de tal competência" está errada por construção. E toda comparação lexicográfica entre um CNPJ numérico antigo e um alfanumérico novo, usada em índice ordenado ou em relatório agrupado por faixa, muda de comportamento dependendo do collation do banco. Um "A" pode ordenar antes ou depois de "9" dependendo da configuração, e isso não é um bug do banco, é ambiguidade que o próprio formato introduziu.
A suíte de testes provavelmente está mentindo sobre isso
Vale um parágrafo à parte para quem mantém a suíte de testes do parser de glosa. Fixture de CNPJ em teste unitário quase sempre é gerado por biblioteca de dados fake que produz só dígitos, porque é isso que essas bibliotecas fazem há anos e ninguém pediu para mudar. Isso quer dizer que a suíte inteira pode estar verde e ainda assim não cobrir o caso que vai aparecer em produção na primeira guia com CNPJ alfanumérico de prestador novo.
Não é caso raro de borda para ignorar. É caso novo e frequente, porque todo cadastro de prestador aberto a partir de agosto de 2026 tem chance real de vir com CNPJ alfanumérico, já que a atribuição é aleatória entre os dois formatos, e prestador novo é exatamente o tipo de cadastro que entra no sistema toda semana. Vale adicionar pelo menos um fixture alfanumérico manualmente à suíte antes de assumir que o pipeline está coberto.
Comunicação muda, Conteúdo e Estrutura não, e o parser precisa saber a diferença
Voltando à distinção que a Abramed registrou: o Componente de Conteúdo e Estrutura do TISS, que define os XMLs de guia de consulta, SP/SADT, internação, não muda. O Componente de Comunicação, que define como as mensagens trafegam entre prestador e operadora (lote de guias, protocolo de recebimento, mensagem de envio de documentos), é que incorpora o ajuste ao novo identificador alfanumérico da Receita Federal.
Vale pensar em quem mais consome esse CNPJ além do parser de ingestão. Sistema de reconciliação financeira que casa pagamento com guia por CNPJ do prestador. Relatório de recorrência de glosa agrupado por CNPJ da operadora. Motor de regras que decide alíquota ou rota de aprovação com base em faixa de CNPJ. Cada um desses consumidores downstream herda a mesma decisão de tipo que foi tomada lá na ingestão, e nenhum deles vai reclamar em tempo de build. Vão reclamar em produção, com um número financeiro real atravessado.
Isso importa porque a maioria dos ETLs de glosa que já vi trata os dois componentes com o mesmo parser, ou pior, extrai CNPJ do envelope de Comunicação uma vez e reaproveita o valor em todo processamento downstream de Conteúdo e Estrutura sem revalidar. Se a extração inicial já rejeita ou trunca um CNPJ alfanumérico, cada etapa seguinte herda um dado corrompido sem nunca reprocessar a fonte.
Já escrevemos sobre um problema estrutural parecido no de-para da TUSS 38, que é outra frente da mesma leva de atualização do Padrão TISS: ali o campo que quebra é a terminologia de glosa, aqui é a chave que identifica quem enviou e quem recebeu. Normas diferentes do mesmo pacote, falhas de naturezas diferentes, mesmo prazo.
No AI.DOC, tratamos CNPJ como campo de identidade versionado por formato, não como coluna de banco fixa: a extração valida o formato no momento da ingestão, aplica o algoritmo correto conforme o padrão detectado, e mantém o CNPJ original e o normalizado lado a lado para auditoria. É o tipo de decisão de schema que só parece óbvia depois que alguém já apanhou com um caso de borda.
A assinatura ICP-Brasil chega no mesmo pacote, com relógio próprio
O CNPJ alfanumérico não viaja sozinho nessa atualização. A Mensagem de Envio de Documentos do Padrão TISS passa a exigir assinatura digital institucional com certificado ICP-Brasil do tipo e-CNPJ, ou e-CPF quando aplicável, com envio em papel expressamente vedado como substituto (Abramed, 27/02/2026). Trocar a chave de identidade e endurecer a exigência de autenticação no mesmo componente, na mesma janela de tempo, não é coincidência de calendário: é a ANS fechando duas lacunas de integridade de uma vez.
O prazo de implantação dessa leva de mudanças segue a mesma régua que já vale para o restante do Padrão TISS: a RN nº 501/2022, no parágrafo único do artigo 26, fixa entre 3 e 12 meses contados do início de vigência da versão. Não achei, até o fechamento deste texto, uma data de corte específica e publicada para o fim de implantação exclusivo do ajuste de CNPJ alfanumérico na Comunicação; o que existe é a regra geral do artigo 26 aplicada à versão em vigor. Vale conferir a data exata no arquivo de histórico de versão antes de travar qualquer cronograma de release interno, porque é exatamente esse tipo de prazo específico que eu não citaria de memória.
Talvez o ponto mais fácil de subestimar seja este: nenhuma dessas mudanças é opcional para quem envia ou recebe TISS, e não existe modo de compatibilidade retroativa embutido no padrão. Ou o parser aceita os dois formatos de CNPJ e valida a assinatura digital nova, ou a mensagem é rejeitada na porta de entrada da operadora. O AI.DOC foi desenhado para esse tipo de dependência de schema: identidade de prestador e operadora versionada por formato, dígito verificador calculado conforme o padrão detectado em cada registro, e trilha auditável ligando o CNPJ original ao normalizado.
O trabalho de revisão aqui não é vistoso, mas é mensurável. Solicitar avaliação do AI.DOC roda seu schema e seu conjunto de regras de glosa atuais contra os dois formatos, numérico e CNPJ alfanumérico, e devolve, com volume financeiro real, cada ponto do pipeline onde a ruptura apareceria primeiro.
"Sozinhos, combatemos uma fraude. Unidos, eliminamos o problema."