Rejeição 1027: nota referenciada indevida no crédito de IBS da ZFM

Quando a NF-e retorna “Rejeição: NF referenciada informada indevidamente”, código 1027, confira primeiro a finalidade e o tipo de crédito selecionados. Nesse contexto, a validação identifica uma referência a outra nota em um documento de crédito de IBS sobre o saldo devedor na Zona Franca de Manaus. Retirar referências de todas as notas da empresa seria uma correção equivocada: outros documentos têm regras próprias de referenciamento.

Há um limite decisivo para quem está trabalhando em 2026: o tipo de crédito envolvido tem uso previsto somente a partir de janeiro de 2029. O código pode constar de documentação, testes e validações preparatórias sem representar uma operação disponível agora. Se ele apareceu numa venda, devolução ou complemento comum, investigue a seleção indevida desse tipo antes de tentar corrigir a referência.

Qual é o contexto desta mensagem

A regra B25-65, na NT 2025.002-RTC v1.52, página 31, trata da NF-e modelo 55. Quando a nota é de crédito do tipo 02 — Apropriação de crédito presumido de IBS sobre o saldo devedor na ZFM, a presença do grupo NFref dispara o 1027. No XML, os campos decisivos são ide/finNFe, ide/tpNFCredito e ide/NFref. A finalidade de nota de crédito é finNFe=5.

O serviço é a autorização da NF-e. A coluna de modelo dessa regra não inclui NFC-e 65. A menção à ZFM descreve o enquadramento do crédito, não uma autorização para qualquer empresa escolher esse tipo por estar no Amazonas. Confirme estabelecimento, operação, fundamento fiscal e período com quem responde pela tributação.

A interpretação depende também do autorizador, da UF e do ambiente informados no retorno. Homologação serve a testes; seu resultado não comprova autorização em produção. Um número 1027 vindo de outro documento fiscal ou de uma rotina interna do emissor precisa ser relacionado ao respectivo serviço e à mensagem completa.

Por que a presença da referência pode estar errada

Uma possibilidade a investigar é o documento nascer de uma duplicação ou de uma integração. A rotina pode reaproveitar informações da nota anterior e conservar uma chave no cabeçalho, mesmo depois de mudar a finalidade. Também pode existir um modelo de operação que preenche referências automaticamente para todos os documentos de crédito.

Nesse cenário restrito, a validação controla a presença de NFref. Uma chave com 44 posições e dígito verificador correto não resolve a incompatibilidade. Trocar a chave por outra também mantém o grupo proibido. O problema pode estar no tipo selecionado, no conteúdo herdado ou na montagem do XML; cada causa exige uma correção diferente.

Verifique ainda a diferença entre o cadastro e o arquivo enviado. Um documento já preparado pode conservar dados antigos. A tela sem referência não demonstra que o emissor retirou o grupo do XML. Peça ao suporte o arquivo efetivamente transmitido e compare-o com a configuração responsável por sua geração.

Como localizar a causa sem alterar a operação

Guarde o retorno completo, o horário, a chave, o modelo, a UF e o ambiente. Registre a versão do emissor e o identificador da operação interna. Depois examine a finalidade e o tipo de crédito no XML, em vez de confiar apenas no nome exibido na tela.

Confirme se existe NFref no grupo de identificação da nota. Localize a origem: preenchimento manual, duplicação, importação, vínculo com pedido ou regra da integração. Verifique quem definiu o crédito tipo 02 e qual documento fiscal sustenta essa decisão. Essa sequência permite identificar o erro sem trocar enquadramentos por tentativa.

Se o arquivo mostrar finalidade diferente de crédito ou tipo diferente de 02, preserve a evidência. Pode haver retorno associado a outra tentativa, documento antigo na fila ou interpretação incorreta do emissor. O suporte deve reconciliar o XML, a resposta e a chave antes de recomendar mudanças.

Correção por cenário

Uma venda comum foi configurada como crédito tipo 02. Confirme o fato real com o responsável fiscal e corrija a parametrização que atribuiu a finalidade errada. Refaça o documento pelo fluxo do emissor. Não mantenha um crédito ZFM fictício apenas porque a retirada da referência eliminaria uma validação.

Um teste preparatório usa o tipo 02 e herda uma referência. Quando o cenário de teste exige esse tipo, ajuste a origem que gera NFref. Gere novamente o arquivo, incluindo assinatura pelo emissor se o conteúdo mudou. Registre as demais limitações do ambiente e do período: resolver o 1027 não torna o tipo permitido antes de 2029.

Um documento futuro corretamente enquadrado mantém referência automática. Depois de confirmar a norma vigente naquele momento e a aplicação ao contribuinte, corrija o modelo da operação para que esse crédito não leve NFref. Preserve vínculos comerciais internos necessários à auditoria; retirar o grupo fiscal não exige apagar documentos ou registros da empresa.

Exemplo para entender a diferença

Uma distribuidora fictícia prepara em outubro de 2026 uma NF-e de venda a partir de um modelo interno. A integração seleciona finNFe=5 e tpNFCredito=02, embora o pedido corresponda a uma venda normal, e leva uma referência ao documento anterior. O retorno apresentado é 1027.

A equipe compara pedido, enquadramento aprovado e XML. O erro principal é o modelo selecionado. Ela corrige a parametrização para representar a venda efetiva e confere as referências que essa operação realmente exige. Apenas apagar a chave preservaria uma finalidade falsa e ainda deixaria o problema temporal do tipo 02. O exemplo é ilustrativo; não constitui resultado real de emissão.

Como verificar o resultado e quando escalar

Na NT v1.52, página 32, a B25.2-30 prevê o retorno 1145 quando o ano de emissão desse tipo de crédito é anterior a 2029. Não altere a data da nota para contornar essa regra. Os cronogramas das atualizações não devem ser transferidos indiscriminadamente a esta regra. A documentação preparatória não torna o crédito tipo 02 utilizável em 2026 nem suspende automaticamente controles anteriores.

Compare o XML novo com o rejeitado e documente exatamente o que mudou. Consulte o novo retorno da chave correta: o desaparecimento do 1027 pode revelar outra rejeição, não uma autorização. Se ocorrer falha de comunicação, consulte a situação antes de repetir a emissão. Confirme protocolo e situação fiscal apenas quando o autorizador os devolver.

Acione o responsável fiscal para definir finalidade, crédito e período. Acione o suporte quando a tela e o XML divergem, a referência reaparece ou a resposta não corresponde ao arquivo. Encaminhe evidências da tentativa, ambiente e versão. Não é necessário inventar uma finalidade alternativa, cancelar uma nota já autorizada ou alterar a realidade fiscal para corrigir um arquivo rejeitado.

Fontes

Conferência documental em 16/10/2026. NT 2025.002-RTC v1.52, páginas 15–16 e 31–32, especialmente B25-65 e B25.2-30. PDF compartilhado capturado em 15/10; publicação de 01/10 confrontada no índice nacional capturado em 16/10. O PNG documental existente da página 31 foi inspecionado na revisão do 678 desta sequência; reutiliza-se essa leitura por identidade, sem novo render. Página 32 foi lida textualmente.

Três apoios específicos foram efetivamente lidos: Migrate/InvoiCy, Sankhya e Tribium. Migrate e Tribium tiveram HTTP200 novo em 16/10; Sankhya foi lido pela ferramenta web, separado do HTTP403 direto. A estrutura NFRefItem e a chave fictícia do exemplo Migrate não foram reproduzidas ou validadas. A ampliação do 1027 para débito, devolução ou ajuste no Tribium não substitui a condição restrita do tipo 02; seus XMLs de crédito em 2026 e o relato de autorização não comprovam liberação desse uso. Nenhum apoio sustenta a utilização antes do limite temporal da NT. Menus externos não representam o ALRA. Sem teste de emissão, validação XSD ou consulta fiscal individual.