Rejeição 227 do CT-e: Erro na composição do Campo ID
A chave de acesso gravada no XML não confere com os dados do próprio conhecimento. É erro de geração do arquivo, não de preenchimento.
A Rejeição 227 acontece quando a chave de acesso gravada no XML não corresponde aos dados do próprio conhecimento. A SEFAZ refaz a conta com os campos que recebeu, compara com a chave informada e recusa quando dá diferente.
Esta é uma rejeição de geração do arquivo, não de preenchimento. Não há campo na tela que a pessoa tenha errado.
O que a SEFAZ responde: "Erro na composição do Campo ID"
Por que acontece a Rejeição 227
A chave de acesso do CT-e tem 44 dígitos e não é um número sorteado: ela é montada a partir dos próprios dados do conhecimento, nesta ordem — código da UF, ano e mês de emissão, CNPJ do emitente, modelo, série, número, tipo de emissão, código numérico aleatório e um dígito verificador.
O campo ID do XML carrega essa chave precedida do literal CTe. A validação faz duas conferências:
- Falta o literal. O campo tem que começar com
CTeseguido dos 44 dígitos. - A chave não bate com a concatenação. Algum campo do conhecimento mudou depois de a chave ter sido gerada, ou o dígito verificador foi calculado errado.
Na prática, a causa é sempre uma dessas duas famílias:
- O documento foi alterado depois de a chave existir. Trocar a série, o número, a data de emissão ou o CNPJ do emitente muda a chave. Se ela não for recalculada, a conta não fecha.
- Defeito no sistema emissor. Cálculo do dígito verificador, montagem do literal ou tratamento do código numérico aleatório.
No Berga
DFe › CTe, na própria listagem do conhecimento.
Deixa que o Berga resolve. A chave é calculada pelo sistema no momento do envio, a partir dos dados do conhecimento — não é campo digitado, e não fica guardada de uma tentativa para a outra. Cada nova transmissão gera número e chave coerentes entre si. Conheça o Berga — a emissão de CT-e já vem pronta.
Como resolver a Rejeição 227
- 1Tente transmitir o CT-e novamente. A chave é refeita no envio, e se o problema veio de uma alteração feita depois da primeira tentativa, o reenvio já resolve.
- 2Se a rejeição repetir, confira os dados que entram na chave: CNPJ do emitente, série, número e data de emissão. Um deles alterado manualmente entre tentativas é a causa mais comum.
- 3Persistindo, abra um chamado. Chave que não fecha depois do reenvio indica defeito na geração do arquivo, e isso se resolve no sistema, não no cadastro.
O CT-e recusado por validação não consome numeração — a sequência é reaproveitada.
Como evitar a Rejeição 227
Não altere série, número ou data de emissão de um conhecimento que já teve uma tentativa de envio. Se precisar mudar algum desses dados, o caminho seguro é emitir um novo documento em vez de editar o que já foi transmitido.
Quando a emissão vem de integração própria, garanta que a chave seja recalculada a cada montagem do XML, e não reaproveitada de um envio anterior.
Se a Rejeição 227 continuar
Se o reenvio não resolve, o problema não está no seu cadastro. Ao abrir o chamado, informe o número e a série do CT-e, a data de emissão e o CNPJ do emitente — com esses quatro dados é possível refazer a chave e comparar com a que foi enviada.
Se você emite por integração, anexe o XML rejeitado: o campo ID mostra na hora se falta o literal ou se o dígito verificador está errado.
Consulte a tabela de rejeições do CT-e para procurar outro código.
Referência: MOC CT-e 4.00 — Anexo I, regras de validação G014, H011 e I11.