O manual da NFCom está na versão 1.00a — a mesma desde o começo do projeto. E, mesmo assim, o leiaute do documento já mudou várias vezes.

A explicação está numa linha da norma: nota técnica publicada no site do portal da NFCom pode esclarecer questões referentes ao manual. É por esse caminho que o documento fiscal se altera — sem edição nova do manual, sem publicação no Diário Oficial anunciando “mudança na NFCom”.

Neste artigo

• O que a norma autoriza
• Sete notas técnicas, um manual só
• 990 itens: o teto que voltou ao que era
• O código de retorno cresceu para quatro dígitos
• O CNPJ já pode ter letras no schema — e não pode ser usado
• A leitura: passar no schema não é cumprir a regra
• Onde conferir

O que a norma autoriza

O ajuste que instituiu a NFCom resolve a questão em duas frases. A primeira determina que Ato COTEPE/ICMS publicará o Manual de Orientação do Contribuinte, com as especificações e critérios técnicos da integração entre os portais das administrações tributárias e os sistemas das empresas emissoras.

A segunda é o parágrafo único, e é a que interessa aqui:

“Nota técnica publicada em sítio eletrônico do portal da NFCom poderá esclarecer questões referentes ao MOC.”

Na prática, “esclarecer” abrange bastante coisa: campos novos, regras de validação novas, códigos de rejeição novos e mudanças de schema. Tudo isso chega por documento publicado numa página — não por norma publicada em diário.

Não é um desvio: é o desenho. Documento fiscal eletrônico muda no ritmo de sistema, não no ritmo de legislação. Mas tem uma consequência prática para quem opera: acompanhar só a legislação não basta para saber o que mudou na sua nota.

Sete notas técnicas, um manual só

Conferindo o portal DF-e hoje, a conta é esta: o manual continua na versão 1.00a — tanto a Visão Geral quanto o Anexo I de leiaute e regras de validação — e existem sete notas técnicas próprias da NFCom publicadas, além de uma nota conjunta dos documentos fiscais eletrônicos sobre o CNPJ alfanumérico.

São elas: 2023.001, 2023.002, 2024.001, 2024.002, a 2025.001 da Reforma Tributária, a 2026.001 de vinculação de pagamento e a 2026.002, também da Reforma.

Quem baixou o manual uma vez e guardou tem, portanto, um documento correto e insuficiente. As três mudanças abaixo ilustram bem o problema — todas já implantadas, e nenhuma delas aparece no manual.

990 itens: o teto que voltou ao que era

O schema da NFCom foi readequado para aceitar até 990 itens por nota. A nota técnica explica o porquê, e a justificativa é técnica, não fiscal: o tamanho do arquivo a ser gerado e transmitido e a performance para validar as chaves de acesso anteriores relacionadas nos itens.

Repare no segundo motivo. Cada item pode referenciar a chave de uma nota anterior — mecânica que aparece na nota de ajuste, no cofaturamento e agora também no pagamento antecipado. Validar mil referências de uma vez é caro para o autorizador, e o teto existe para conter isso. É a mesma mecânica que mapeamos ao mostrar as cadeias de referência que uma nota cria ao apontar para outra.

A própria nota técnica registra que 990 “era como estava estabelecido no início do projeto”, e que o ajuste alinha o padrão com o da NF-e e o da nota de energia elétrica. Ou seja, houve ida e volta — e quem implementou no meio do caminho pode ter gravado outro número.

Para o provedor, 990 itens é folga em fatura residencial e pode ser aperto em fatura consolidada de cliente corporativo com muitos pontos. Vale saber que o limite existe antes de desenhar a consolidação.

O código de retorno cresceu para quatro dígitos

A segunda mudança silenciosa explica algo que salta aos olhos de quem lê as regras novas: o código de status de retorno passou a suportar até quatro dígitos.

Por isso as rejeições recentes têm outra cara. As antigas moram na faixa de três dígitos — 203, 276, 432, 539. As novas já nascem com quatro: 1001 para CNPJ do recebedor de pagamento inválido, 1015 para município fora da área incentivada, 1040 para percentual de devolução não informado.

É uma mudança que não muda nenhuma regra de negócio — e que quebra sistema mesmo assim. Emissor que guarda o código de retorno num campo de três posições passa a truncar, ou a errar, exatamente quando a rejeição é nova. É o tipo de defeito que só aparece no dia em que a nota é recusada por um motivo inédito.

O CNPJ já pode ter letras no schema — e não pode ser usado

A terceira é a mais delicada, porque tem duas metades que se contradizem se lidas pela metade.

As expressões regulares do projeto foram preparadas para o CNPJ alfanumérico. O campo de CNPJ, que aceitava apenas 14 dígitos, passou a aceitar letras maiúsculas nas doze primeiras posições, mantendo numéricas as duas últimas. E a chave de acesso, que era 44 dígitos, passou a admitir letras nas doze posições que correspondem ao CNPJ dentro dela.

A alteração foi feita no arquivo de tipos gerais e, por isso, aplica-se automaticamente a todos os campos de CNPJ e de chave de acesso em qualquer schema do projeto. Ninguém precisou mexer campo a campo.

E aqui vem a segunda metade, que a nota técnica registra em texto: até que seja publicada uma nota técnica que modifique as validações desses campos, as letras não devem ser utilizadas.

Ou seja: o schema aceita, a regra proíbe. Quem testar com letras vai passar na validação de formato e não é isso que autoriza o uso. Vale ler junto com o que já contamos sobre o CNPJ alfanumérico entrando no eSocial e na EFD-Reinf: o mesmo cadastro chega a cada sistema com calendário e condições próprias.

A leitura: passar no schema não é cumprir a regra

Esta é a nossa leitura, e ela vale para além destes três casos: no documento fiscal eletrônico, o schema define o que é aceito na porta, e a nota técnica define o que é permitido — e os dois não coincidem.

O CNPJ alfanumérico é o exemplo perfeito: cabe no campo e é proibido. O contrário também acontece — regra que existe na nota técnica antes de virar rejeição ativa, como a exigência do grupo de compra governamental e as regras que só valem a partir de 2033.

Três consequências práticas:

1. Testar contra o schema não é conferir conformidade. O XSD valida forma. Quem só testa assim descobre o resto na rejeição, em produção, com o faturamento do mês parado.
2. O ponto de checagem é o portal, não o diário oficial. A norma delega ao site a função de esclarecer o manual. Quem acompanha só publicação legal fica sabendo por último — e a pergunta ao fornecedor do emissor passa a ser “em que nota técnica você está?”, não “o sistema está atualizado?”.
3. Guardar a versão do manual não basta. O manual continua 1.00a e continuará correto naquilo que descreve. O que muda vem por fora, e é preciso ler as sete.

A pergunta útil, para fechar: “o meu emissor trata o código de retorno como texto de quatro posições — e alguém aqui lê as notas técnicas quando saem?”

Onde conferir

As notas técnicas são revisadas com frequência e novas versões substituem as anteriores; a contagem acima é a da data desta apuração, feita no portal. Confira sempre a versão vigente antes de implementar, e trate as datas de implantação em homologação e produção como parte da regra.

Fontes: Ajuste SINIEF nº 7, de 7 de abril de 2022, do Conselho Nacional de Política Fazendária — CONFAZ, em texto consolidado (cláusula terceira, segundo a qual Ato COTEPE/ICMS publicará o Manual de Orientação do Contribuinte, disciplinando as especificações e critérios técnicos necessários à integração entre os portais das administrações tributárias e os sistemas das empresas emissoras, e cujo parágrafo único prevê que nota técnica publicada em sítio eletrônico do portal da NFCom poderá esclarecer questões referentes ao MOC); e a área de documentos da NFCom no portal DF-e da SVRS, onde constam o Manual de Orientação do Contribuinte na versão 1.00a — Visão Geral e Anexo I de Leiaute e Regras de Validação — e as notas técnicas 2023.001, 2023.002, 2024.001, 2024.002, 2025.001, 2026.001 e 2026.002, além da nota técnica conjunta dos documentos fiscais eletrônicos sobre o CNPJ alfanumérico; em especial a Nota Técnica 2025.001 — Reforma Tributária do Consumo, versão 1.14a (readequação do schema da NFCom para aceitar até 990 itens, em razão do tamanho do arquivo a ser gerado e transmitido e da performance para validar chaves de acesso anteriores relacionadas nos itens, alinhando o padrão com a NF-e e a NF3e; ampliação do cStat de retorno para quatro dígitos; e preparação das expressões regulares para o futuro CNPJ alfanumérico, alterando a validação do campo CNPJ para aceitar letras maiúsculas nas doze primeiras posições e a da chave de acesso para admiti-las nas doze posições correspondentes ao CNPJ, com a ressalva expressa de que, até que seja publicada nota técnica que modifique as validações desses campos, as letras não devem ser utilizadas).