Rejeição 360: confira o empenho informado e o critério da UF

Se uma venda a um órgão público recebeu a rejeição 360, reúna a nota de empenho e o XML enviado antes de repetir a transmissão. A identificação pode ter sido digitada incorretamente ou trocada pela de um contrato. Também pode faltar orientação sobre o critério estadual. Compare os arquivos e os fatos da compra para localizar a divergência.

A mensagem documentada é “Rejeição: NF-e com Nota de Empenho inválida para a UF.”. O contexto deste artigo é a autorização de NF-e modelo 55, pela regra ZB02-20. O código não informa, sozinho, qual caractere ou vínculo o autorizador considerou inválido.

O que está documentado no MOC

O MOC 7.0, Anexo I, página 127, descreve a invalidade do empenho para a UF. A coluna de aplicação é facultativa, com a observação: “Implementação opcional, a critério da UF.” A linha não estabelece máscara ou algoritmo nacional, nem define a UF de destino como critério. Não complete essas lacunas por suposição.

Na página 64, xNEmp identifica a nota de empenho no grupo compra. O leiaute documenta texto de 1 a 22 caracteres, com ocorrência estrutural 0–1. Isso não define o formato administrativo válido de cada estado nem permite omitir uma informação exigida pela operação. Pedido e contrato possuem campos distintos, xPed e xCont.

A versão documental do manual é 7.0, diferente da versão 4.00 do XML. A documentação foi conferida em 15/10/2026, com consulta atual da tabela paulista e cotejo das notas técnicas preservadas. Isso não comprova implantação individual. Identifique UF, autorizador, ambiente e versão do emissor no caso real. Um resultado em homologação não comprova o comportamento em produção.

Como interpretar a publicação paulista

A tabela oficial paulista consultada em 15/10/2026 publica ZB02-20 / 360 / Inativa. Esse é o estado divulgado pela página consultada; não constitui teste de emissão em homologação ou produção, nem informa a configuração de outros estados. A data de atualização da página não foi identificada.

Se um retorno atribuído a São Paulo informar 360, preserve a resposta completa e confirme sua origem com o suporte. Verifique ambiente, endereço do serviço e autorizador utilizado antes de concluir que a publicação e o retorno são incompatíveis. A publicação não autoriza descartar um retorno real sem investigar sua origem.

Há também uma condição distinta na NT 2026.002 v1.11, página 19: a ZB01-10/762 veda o grupo compra na NF-e com DANFE Simplificado Tipo 2, tpImp=6, além da NFC-e. Seu cronograma indica homologação em 01/07 e produção em 03/08/2026. Se esse formato foi selecionado, confirme sua adequação com o responsável fiscal; não remova um empenho exigido para contornar a regra. Essa alteração não fornece máscara para a 360 nem modifica expressamente a ZB02-20.

Separe invalidade de ausência e inexistência

A 359 trata da falta de empenho na condição própria de sua regra; a 360 indica invalidade para a UF; a 361 informa inexistência na UF. A linha 360 não repete a condição motDesICMS=8 da 359. Use essa distinção para organizar o atendimento, sem presumir que todas as validações anteriores foram executadas ou aprovadas.

Não conclua apenas pelo 360 que o empenho foi cancelado, que o órgão não o emitiu ou que uma base está atrasada. Essas hipóteses precisam de evidência específica. Uma mudança posterior de mensagem também não prova que o formato passou a estar correto.

Compare documento, cadastro e XML

Separe a nota de empenho relacionada à compra, pedido ou ordem de fornecimento, XML efetivamente transmitido e resposta completa. Registre horário, chave da NF-e, UF e ambiente. Um PDF do documento administrativo ajuda a confrontar a identificação, mas não demonstra qual valor entrou no arquivo fiscal.

No XML, localize infNFe/compra/xNEmp. Compare esse conteúdo com a identificação verdadeira do empenho. Confira se a equipe não usou o número de contrato, licitação ou processo. Verifique também o vínculo com o órgão comprador e com o fornecimento faturado.

Ano, prefixos e zeros são pontos de comparação, sem representar uma regra universal. Uma integração pode ter truncado o identificador ou agregado texto de outro campo. Não retire símbolos ou complete números por tentativa: preserve o documento original e obtenha a orientação aplicável.

Confira se o dado exibido na tela pertence à nota preparada. Alterar o pedido ou o cadastro do cliente pode não modificar o XML já gerado. Após qualquer ajuste autorizado, compare novamente o arquivo que será transmitido.

Como agir por cenário

Digitação ou documento selecionado incorretamente

Corrija a identificação com base no empenho correspondente à venda. Se houve confusão com o contrato, confirme o dado com o comprador. Se foi escolhido um empenho de outra compra, revise o vínculo entre pedido, órgão e faturamento.

Um empenho aceito em outra NF-e não serve automaticamente para esta operação. A correção precisa preservar a relação verdadeira com o fornecimento, sem inventar documento ou reaproveitar uma identificação apenas porque ela passou antes.

O emissor transformou o valor

Quando a tela e o documento mostram a identificação completa, mas o XML contém outro valor, encaminhe os registros ao suporte. Peça investigação do armazenamento ou mapeamento conforme a diferença comprovada.

Gere novamente a nota pelo fluxo do emissor e confira o conteúdo. Não edite diretamente um XML assinado. No ALRA, o suporte deve verificar a tela e a versão efetivamente utilizadas; esta análise documental não confirma um caminho de preenchimento no sistema.

O valor coincide e a rejeição permanece

Solicite ao órgão comprador a confirmação da identificação e das instruções administrativas da compra. Com o responsável fiscal ou suporte, busque esclarecimento do critério publicado pela UF e do canal oficial pertinente.

O MOC não fornece uma máscara estadual para preencher essa lacuna. Não mude UF, destinatário ou tributação para obter aceitação. Preserve os arquivos e peça que o autorizador esclareça qual informação está sendo considerada inválida.

Exemplo fictício e condicional

Uma fornecedora de móveis mantém contrato e empenho em campos separados. Uma integração poderia copiar o contrato para xNEmp. Se a validação estadual estivesse aplicada e considerasse essa identificação inválida, o cenário poderia resultar em 360.

A equipe compararia o XML com o empenho verdadeiro, demonstraria a troca e corrigiria a origem do vínculo. O novo arquivo ainda precisaria atender às demais regras. O exemplo não estabelece formato estadual, não relata emissão testada e não oferece autorização garantida.

Verificação final e encaminhamento

Depois de conferir a correção, faça uma transmissão controlada e leia a resposta associada à chave correta. Se surgir outra rejeição, investigue sua condição. Considere a autorização comprovada somente pelo resultado e protocolo correspondentes, preservando o XML.

Se o 360 persistir sem divergência demonstrada, suspenda tentativas idênticas. Encaminhe ambiente, UF/autorizador, horário, chave, XML, retorno e comparação documental por canal adequado. O suporte investiga a geração do arquivo; o comprador esclarece a identificação administrativa; o responsável fiscal analisa o enquadramento; a SEFAZ esclarece sua validação.

Fontes

Documentação conferida em 15/10/2026.

• MOC 7.0, Anexo I: ZB02-20, página 127; grupo compra e xNEmp, página 64; mensagem, página 145.

• SEFAZ-SP, regras facultativas: situação publicada para São Paulo, consultada em 15/10/2026; não é teste de emissão.

• NT 2026.002 v1.11: ZB01-10/762 e DANFE Simplificado Tipo 2, página 19; cronograma, página 3. Documentos SVRS: índice de publicações.

• Confronto prático: Buscador NCM, 360, Berga, 360 e catálogo RWA. Os dois primeiros tratam do código; o catálogo apenas auxilia na identificação das mensagens. O MOC fundamenta a regra, e o critério administrativo concreto depende da UF.