Rejeição 227: CPF do emitente diferente do certificado digital

A Rejeição 227, regra F03A, ocorre quando a assinatura utiliza um certificado com CPF e esse CPF difere do CPF do emitente. O CPF do responsável por uma empresa, do comprador ou de quem operou o sistema não substitui a identidade fiscal do emitente pessoa física.

Nesta página: Qual CPF comparar · O que muda nos fluxos especiais · Exemplo: operador e emitente são pessoas diferentes · Próximo passo após localizar a divergência

Qual CPF comparar

Localize o CPF em NFe/infNFe/emit/CPF e identifique o CPF do certificado efetivamente usado na assinatura do XML. A comparação é do identificador completo. Nome semelhante, parentesco, procuração ou responsabilidade por um CNPJ não são condições de dispensa descritas pela F03A.

A aceitação da emissão por pessoa física depende do contexto autorizado pela UF e do leiaute aplicável. A rejeição não concede credenciamento. Também não se resolve preenchendo CPF no lugar de CNPJ quando a operação e o emitente reais são outros. Confira a empresa ou pessoa ativa no emissor e o documento que sustentou o cadastro.

O que muda nos fluxos especiais

O MOC 7.0, p. 74, descreve a F03A no grupo de validação da assinatura digital. A NT 2021.002 v1.12, p. 11, registra a exceção NFF: para tpEmis=3, o certificado utilizado é o da SVRS. Isso exige o regime Nota Fiscal Fácil real; não autoriza alterar o tipo de emissão para contornar a comparação.

A NT 2026.001 v1.02b altera a F03 para PAA na SVRS. Essa dispensa da comparação de CNPJ-base não deve ser transportada para a F03A como uma autorização genérica para assinar com qualquer CPF. O PAA tem processo e validações próprios. Se o retorno foi produzido nesse fluxo, a identificação precisa ser investigada com os dados efetivos do provedor e do autorizador.

Exemplo: operador e emitente são pessoas diferentes

Considere uma emissão de pessoa física na qual o cadastro do emitente está correto, mas o repositório de certificados entrega o certificado de outro usuário do computador. O fato de esse usuário ter iniciado a venda não faz dele o emitente. Compare o certificado da assinatura enviada com o CPF em emit/CPF; se diferirem, a causa está identificada sem precisar inventar números.

Um XML sintético não demonstra titularidade nem uma assinatura válida. Esta conferência depende do original da tentativa e do certificado público correspondente. Não publique CPF, XML integral, senha ou chave privada para pedir auxílio. O CPF eventualmente completado para compor a chave de acesso também não muda o CPF de titularidade do certificado.

Próximo passo após localizar a divergência

Preserve envio, retorno e ambiente. Se a configuração escolheu outro certificado, corrija sua associação ao emitente, gere novamente o XML ainda rejeitado e confira a identidade assinante antes da validação. Se o cadastro do emitente estiver errado, valide a identidade fiscal real da operação antes de corrigi-lo. Não modifique um XML já assinado manualmente.

Uma falha de validade, revogação ou cadeia do certificado tem diagnóstico diferente; conseguir conectar por TLS também não comprova a igualdade exigida pela 227. Para concluir, confira a resposta individual do documento e o protocolo, quando houver. Em comunicação incerta, esclareça o estado da tentativa original antes de enviar novamente.

Fontes oficiais

• MOC 7.0 — Anexo I: p. 74 F03A; p. 12 emit/CPF.
• MOC 7.0 — Visão Geral: p. 19 emitente CPF/e-CPF; pp. 52–55 certificados e assinatura.
• NT 2018.001 v1.10: p. 13 F03A e validação da assinatura com CPF; pp. 10–11 contexto de emissão com e-CPF.
• NT 2021.002 v1.12: p. 11 F03A exceção NFF.
• NT 2026.001 v1.02b: p. 11 alteração específica F03.