Rejeição 818: CNPJ incorreto na assinatura da NFF

A rejeição 818 indica uma incompatibilidade entre o regime de emissão informado e o certificado usado para assinar o documento. Na regra F03B da Nota Técnica 2021.002 v1.12, ela ocorre quando a nota está identificada como Nota Fiscal Fácil, com tpEmis=3, e o CNPJ-base do certificado de assinatura difere do CNPJ-base da Sefaz Virtual do Rio Grande do Sul, a SVRS.

O primeiro passo é descobrir se a operação realmente pertence ao fluxo da NFF. Um documento comum marcado indevidamente como NFF exige uma correção diferente daquela necessária quando a solicitação foi feita corretamente pelo aplicativo do regime. A mensagem, sozinha, não demonstra que o CNPJ cadastrado da empresa esteja errado nem que seu certificado tenha vencido.

Por que a assinatura da NFF é diferente

A NFF utiliza um aplicativo para coletar os dados da solicitação e um sistema centralizado para gerar o documento fiscal. A NT explica que o XML será gerado pelo Portal Nacional da NFF e que, para esse fluxo, o certificado utilizado na assinatura deve ser da SVRS. Por isso, um certificado válido de uma empresa não se torna adequado à NFF apenas por pertencer ao emitente.

A comparação da F03B é de CNPJ-base do certificado de assinatura, e não simplesmente do CNPJ completo digitado no cadastro do emitente. Não se deve substituir o CPF ou CNPJ de quem realizou a operação pelo identificador do prestador do serviço para tentar satisfazer essa verificação. A identidade fiscal do emitente e a identidade responsável pela assinatura têm funções diferentes nesse regime.

O quadro da F03B aparece como obrigatório, sem coluna individual de modelo. As regras vizinhas da mesma NT possuem indicações próprias para os modelos 55 e 65. Essa organização não autoriza transformar a 818 em um erro genérico de todo documento fiscal, nem escolher outro modelo como solução. Registre o modelo efetivamente transmitido e confirme a regra do serviço utilizado.

Confirme o retorno e o arquivo transmitido

Guarde o retorno completo, com cStat, xMotivo, horário, ambiente e identificação da tentativa. Confira o XML que foi efetivamente enviado, pois uma tela de configuração pode mostrar valores diferentes daqueles gravados por uma integração. Identifique ide/tpEmis, modelo e origem da geração do arquivo, além do certificado usado na assinatura.

Peça à equipe responsável que verifique os dados públicos do certificado associado à assinatura e a cadeia de processamento do documento. Não é necessário compartilhar senha, arquivo de certificado com chave privada ou credenciais para relatar o erro. O diagnóstico deve indicar quem gerou, quem assinou e quem transmitiu o XML, sem tratar essas etapas como se fossem uma única ação.

Também confirme a situação da operação antes de iniciar outra emissão, especialmente se houve tentativas anteriores com respostas incompletas. Um retorno de rejeição dessa tentativa não comprova a situação de todas as outras transmissões. Havendo resultado de autorização anterior, o tratamento deve considerar o documento já autorizado e os procedimentos cabíveis, evitando duplicidade.

Quando o documento comum recebeu o tipo de emissão errado

Imagine uma empresa que emite pelo seu sistema habitual, usando seu próprio certificado, e uma atualização de integração passa a gravar tpEmis=3. O documento passa a declarar o regime NFF, embora não tenha percorrido esse fluxo. A comparação prevista na F03B pode então identificar a assinatura incompatível.

Nesse cenário, a correção começa no mapeamento que produziu o tipo de emissão. A equipe deve confirmar a modalidade realmente utilizada, corrigir sua origem e gerar novamente o documento pelo procedimento adequado. Não basta alterar um número no XML já assinado: o arquivo corrigido precisa ser novamente gerado e assinado pelo processo correspondente à emissão real.

O valor 3 identifica o Regime Especial NFF na documentação atual consultada. A referência antiga a SCAN não é motivo para utilizar esse valor como contingência de um emissor comum. Do mesmo modo, não se deve escolher emissão normal ou outra contingência sem verificar se ela corresponde às condições reais e às regras aplicáveis ao caso.

Quando a solicitação realmente pertence à NFF

Se a solicitação foi criada no aplicativo NFF e deveria seguir o serviço centralizado, preserve os dados e encaminhe o retorno ao suporte responsável pelo fluxo. Informe UF, ambiente, identificação da solicitação e horário, para permitir a correlação com a geração e a assinatura do documento.

A investigação deve esclarecer se algum componente intermediário gerou outro XML, reassinou o arquivo com certificado da empresa ou encaminhou uma versão diferente da esperada. Essas são hipóteses a verificar, não causas automaticamente provadas pela rejeição. O retorno também não estabelece um prazo universal para o suporte corrigir a situação.

Não procure instalar ou obter o certificado privado da SVRS para assinar localmente. A documentação descreve uma responsabilidade do serviço da NFF. A solução deve restabelecer o fluxo legítimo de geração e assinatura, mantendo os dados da operação e a rastreabilidade da solicitação.

Diferencie assinatura, transmissão e solicitação

A rejeição 832, associada à regra A08, compara o CNPJ-base do certificado usado na transmissão. A 818, da F03B, compara o certificado da assinatura. Embora ambas envolvam a SVRS no regime NFF, corrigir a configuração de comunicação não prova que a assinatura do XML também esteja correta.

A 819 trata de outra condição: informações de solicitação da NFF presentes quando o tipo de emissão é diferente de 3. Já a 834 trata da ausência dessas informações quando o tipo é 3. Apagar ou acrescentar o grupo de solicitação não substitui a investigação da assinatura exigida pela 818.

Depois da correção, confira o novo arquivo e a resposta efetivamente recebida. A ausência da 818 não garante que todas as demais validações tenham sido superadas. Encerre o atendimento com o resultado documentado, mantendo a vinculação entre solicitação, XML e retorno, sem presumir autorização pela simples conclusão do envio.

Fontes e limites

Pesquisa documental em 16/10/2026. Não houve emissão, validação de certificado de cliente, teste de autorizador ou certificação do fluxo ALRA.

• NT 2021.002 v1.12, p21: F03B/818 e A08/832 íntegras na imagem existente inspecionada; textos1/3/4/6/7/8/9/21 lidos. PDF oficial recapturado em15/10 e reutilizado por hash. A capa indica janeiro2025; o controle de versões interno escreve janeiro2024. A entrada do índice nacional, capturado em16/10, registra publicação28/01/2025. O imediato da versão1.12 refere-se à série e à chave, não a uma nova ativação comprovada da818.

• Vinco818: ficha específica inteira lida em HTTP200; mensagem correta, seção Solução sem orientação. Não foi contada como tutorial completo.

• Sonda, nota14458: corpo textual inteiro lido em HTTP200; tabela distingue818/819/820/832. Atualização de2022 do próprio software não é procedimento ALRA nem prova de defeito da SEFAZ neste caso.

• FiscoScan, NT2021.002: análise contextual inteira e transcrição da seção8 lidas em HTTP200. O publicador declara análise por IA sem revisão humana; suas recomendações amplas de desativar regras não foram adotadas. Não substitui a primária.

• Buscador818: corpo específico lido e confrontado. O título apresenta a mensagem de solicitação, enquanto o corpo cita F03B/assinatura. Essa associação divergente não foi usada para redefinir818/819.

Os três apoios ativos têm profundidades diferentes, sem três guias completos disponíveis nesta busca. A pesquisa delimitada em seis caches de NTs2026 não encontrou818/F03B. Menções a NFF em regras cadastrais e de QRCode foram lidas em contexto e não modificam o predicado aqui descrito. Não se afirma varredura de toda regulamentação ou implantação individual por UF/ambiente.