Dentro de cada NFCom existe um grupo de campos que quase ninguém abre: o do responsável técnico. Ele leva o CNPJ da empresa que desenvolveu o seu emissor, o nome de uma pessoa para contato, o e-mail e o telefone dela.
Ou seja: o Fisco tem, dentro de cada documento emitido, a linha direta de quem escreveu o software. E esse é apenas um dos três níveis de acesso que a NFCom organiza — os outros dois definem quem pode baixar o arquivo e o que aparece na consulta pública.
Neste artigo
- Os três níveis de acesso à sua nota
- O responsável técnico: 475 e 472
- O código de segurança do responsável técnico
- Quem pode baixar o XML: 466, 467 e 468
- O QR Code e o que ele aponta: 464, 465 e 470
- A leitura: não há selo para o software, mas há endereço
- Onde conferir
Os três níveis de acesso à sua nota
A norma que instituiu a NFCom desenha uma escada de acesso bem definida, e vale enxergá-la inteira antes de olhar as regras técnicas:
- Consulta pública. Depois da autorização de uso, a administração tributária do estado do emitente disponibiliza consulta à nota. Ela traz dados resumidos para identificar a condição do documento e exibe os eventos vinculados — exceto os dados que permitam identificar o tomador do serviço, que devem aparecer parcialmente mascarados.
- Acesso restrito. A unidade federada pode, opcionalmente, disponibilizar os dados completos — desde que por acesso restrito e vinculado à relação do consulente com a prestação documentada, com o consulente identificado por certificado digital ou acesso identificado.
- O tomador. Quando solicitado, o emitente deve encaminhar ou disponibilizar o download do arquivo da NFCom e do respectivo protocolo de autorização ao tomador do serviço. É obrigação de quem emite, não favor.
Repare que o cliente não precisa estar autorizado em campo nenhum para ter o XML: o direito dele vem da norma. O grupo de autorizados que veremos adiante serve para terceiros.
O responsável técnico: 475 e 472
O leiaute traz o grupo de informações do responsável técnico pela emissão do documento fiscal eletrônico, com quatro campos de identificação:
- CNPJ da pessoa jurídica desenvolvedora do sistema utilizado na emissão;
- nome da pessoa a ser contatada na empresa desenvolvedora — sendo pessoa física, o nome dela;
- e-mail da pessoa jurídica a ser contatada;
- telefone, com DDD.
Duas regras cuidam disso, e ambas são facultativas — o que aqui tem significado próprio:
- G147 (475) — rejeita quando o grupo não é informado. O manual observa: implementação a critério da unidade federada.
- G148 (472) — informado o grupo, valida o CNPJ do responsável técnico (dígito de controle, zeros, nulo).
A consequência prática é que o grupo pode ser obrigatório no seu estado e opcional no vizinho. Quem emite em mais de uma unidade federada precisa preencher sempre, porque o custo de preencher é zero e o custo de faltar é a nota parada.
O código de segurança do responsável técnico
Há ainda dois campos no mesmo grupo que merecem atenção de quem contrata software: o identificador do código de segurança do responsável técnico e o hash desse código.
Pelo leiaute, o hash é o resultado das funções SHA-1 e base64 aplicadas ao token fornecido pelo Fisco ao responsável técnico, concatenado com a chave de acesso do documento. O próprio manual registra que a implementação virá em nota técnica futura.
O desenho é claro mesmo antes da implementação: o desenvolvedor recebe um código do Fisco e assina, com ele, cada documento gerado pelo seu sistema. Não é uma declaração de quem fez o software — é uma marca vinculada à chave daquela nota específica.
Quem pode baixar o XML: 466, 467 e 468
O leiaute prevê um grupo de autorizados para download do XML com ocorrência de zero a dez. São, portanto, até dez CPFs ou CNPJs por nota.
Três regras validam esse grupo:
- G139 (466) — CNPJ autorizado inválido, com zeros ou dígito inválido.
- G140 (467) — CPF autorizado inválido: zeros, nulo, números repetidos como 111 ou 222, ou dígito de controle inválido.
- G141 (468) — documento duplicado dentro do grupo. O mesmo CPF ou CNPJ não pode constar duas vezes na mesma nota.
Para o provedor, o uso típico é o contador — e é aqui que vale a distinção do começo do texto. O tomador tem direito ao arquivo pela norma; o contador, o auditor ou o sistema de terceiro precisam estar nomeados no grupo. Colocar o próprio cliente ali não é errado, mas também não é o que garante o acesso dele.
E o limite de dez é por nota, não por empresa: quem precisa de mais de dez destinos para o mesmo arquivo tem um problema de processo, não de leiaute.
O QR Code e o que ele aponta: 464, 465 e 470
O documento auxiliar leva um código bidimensional com mecanismo de autenticação digital, e ele também é validado:
- G142 (464) — o endereço do site da unidade federada para a consulta via QR Code não pode divergir do previsto. A regra tem duas notas úteis: maiúsculas e minúsculas não contam na validação, e as URLs de cada estado ficam publicadas no portal DF-e.
- G143 (465) — o parâmetro de chave de acesso dentro do QR Code não pode divergir da chave da própria nota.
- G145 (470) — na emissão Normal, o parâmetro de assinatura não deve ser informado no QR Code.
Essa última é o par simétrico do que já vimos sobre contingência, onde a assinatura no QR Code é obrigatória e validada. Juntas, as três regras dizem a mesma coisa por dois lados: o QR Code muda conforme o tipo de emissão, e sobra ou falta assinatura derruba a nota.
O detalhe da URL por estado é o que costuma pegar quem cresce: um emissor configurado com o endereço de uma unidade federada e usado em outra rejeita — e o erro parece de layout, quando é de destino.
A leitura: não há selo para o software, mas há endereço
Esta é a nossa leitura, e ela fecha uma pergunta que aparece toda vez que um provedor vai trocar de sistema.
Como já tratamos, não existe emissor de NFCom homologado — o credenciamento é do CNPJ da empresa, não do programa. Isso costuma ser lido como ausência total de responsabilidade do fornecedor. Não é.
O que existe não é certificação: é identificação. Cada nota carrega o CNPJ do desenvolvedor, um nome de contato, um e-mail e um telefone — e, quando a nota técnica do código de segurança entrar em vigor, uma marca criptográfica vinculada à chave daquele documento.
A diferença entre as duas coisas é grande e vale entender:
- Selo é anterior e genérico. Diria “este software está aprovado”, uma vez, para todo mundo.
- Identificação é posterior e específica. Diz “esta nota foi gerada por este sistema, e o contato é este” — documento por documento.
Três perguntas práticas que isso levanta na hora de contratar ou trocar de emissor:
- O fornecedor preenche o grupo do responsável técnico com os dados dele, ou com os seus? O campo é do desenvolvedor do sistema. Preenchido com o CNPJ do provedor, ele deixa de significar o que deveria.
- O contato informado é real? É por ali que o Fisco chega ao desenvolvedor. E-mail genérico de formulário não é contato.
- Quem está no grupo de autorizados ao download? Vale conferir se o contador continua na lista depois de uma troca de escritório — e se não sobrou ninguém que não deveria mais estar.
Vale lembrar, por fim, que nada disso valida o conteúdo: como já observamos, a autorização aplica regras formais e não convalida a informação tributária. Identificar quem fez o software é rastreabilidade, não garantia de acerto.
Onde conferir
As regras e os códigos são da versão 1.00a do manual e podem mudar por nota técnica — e o próprio manual registra que o código de segurança do responsável técnico terá implementação em nota técnica futura. A exigência do grupo do responsável técnico é, pelo texto, de implementação a critério de cada unidade federada. Confirme no estado onde você emite.
Fontes: Manual de Orientação do Contribuinte da NFCom — Anexo I, Leiaute e Regras de Validação, versão 1.00a, no portal DF-e da SVRS (grupo gRespTec com CNPJ da desenvolvedora, nome do contato, e-mail e telefone, e os campos de identificador e hash do código de segurança do responsável técnico, com o hash descrito como resultado de SHA-1 e base64 do token fornecido pelo Fisco somado à chave de acesso; grupo autXML com ocorrência de zero a dez; e as regras G139, G140, G141, G142, G143, G145, G147 e G148, com os códigos 466, 467, 468, 464, 465, 470, 475 e 472); e Ajuste SINIEF nº 7, de 7 de abril de 2022, do Conselho Nacional de Política Fazendária — CONFAZ (disponibilização da consulta após a autorização de uso, com dados resumidos, exibição dos eventos e mascaramento parcial dos dados que identifiquem o tomador; a faculdade da unidade federada de disponibilizar dados completos por acesso restrito vinculado à relação do consulente com a prestação, mediante certificado digital ou acesso identificado; a obrigação do emitente de encaminhar ou disponibilizar ao tomador, quando solicitado, o arquivo da NFCom e o protocolo de autorização; e o código bidimensional com mecanismo de autenticação digital no DANFE-COM).