Rejeição 361: confirme o empenho enviado e o retorno da UF

Se a NF-e de uma compra pública retornar 361, compare o empenho informado no XML com o documento confirmado pelo órgão comprador. O retorno aponta que a identificação não foi localizada para a UF. Ele não prova, sozinho, cancelamento do empenho, falta de emissão pelo órgão ou necessidade de aguardar determinado prazo.

A mensagem oficial é “Rejeição: NF-e com Nota de Empenho inexistente na UF.”. Este diagnóstico corresponde à ZB02-30, na autorização de NF-e modelo 55. Preserve a resposta completa e o XML transmitido antes de corrigir o vínculo.

Qual é a verificação documentada

O MOC 7.0, Anexo I, página 127, apresenta o predicado “NF-e com Nota de Empenho inexistente para a UF”, com aplicação facultativa. A observação informa implementação opcional, a critério da UF. A regra não identifica a base administrativa consultada nem define sua periodicidade de atualização.

Por isso, confirme UF, autorizador e ambiente do retorno concreto. A coluna modelo 55 não estende essa condição à NFC-e modelo 65, nem permite interpretar qualquer código semelhante em outro serviço. A versão documental 7.00 do manual também é distinta da versão do leiaute XML.

A tabela oficial paulista consultada em 15/10/2026 publica ZB02-30/361 como Inativa. Esse é o estado divulgado pela página consultada, sem teste de emissão em homologação ou produção ou extensão às demais UFs. A data de atualização da página não foi identificada. Se a resposta parecer atribuída a SP, confira sua origem com o suporte antes de concluir qual validação foi executada.

A NT 2026.002 v1.11, página 19, traz outra condição: a ZB01-10/762 veda o grupo compra na NF-e com DANFE Simplificado Tipo 2, tpImp=6, além da NFC-e. O cronograma dessa alteração indica homologação em 01/07 e produção em 03/08/2026. Confirme a adequação do formato quando ele estiver selecionado; não retire um empenho exigido nem altere a operação para contornar a regra. Essa condição não substitui a ZB02-30 nem esclarece qual base administrativa verifica o empenho.

Distinga os três problemas de empenho

A ZB02-10/359 trata da falta de empenho no cenário de desoneração de ICMS por venda pública definido naquela regra. A ZB02-20/360 trata de empenho inválido para a UF. A ZB02-30/361 trata de inexistência para a UF.

O 361 não é uma confirmação de que o formato passou por todas as verificações. O retorno disponível não descreve a sequência completa de processamento do autorizador. Uma identificação digitada incorretamente também pode apontar para outro documento.

Não transfira para o 361 a condição de desoneração da regra 359. Tampouco escolha como causa uma irregularidade de CNPJ, CPF, contrato ou cadastro apenas pela numeração do código.

Compare o documento e o campo transmitido

Reúna a nota de empenho, o pedido ou a ordem de fornecimento, o XML enviado e a resposta. O comprador deve confirmar qual identificação pertence ao faturamento em análise. Número de processo, licitação, pedido e contrato não substitui automaticamente a nota de empenho.

Localize infNFe/compra/xNEmp. Na página 64 do MOC, esse campo identifica a nota de empenho em compras públicas; o leiaute registra tipo caractere, ocorrência 0–1 e tamanho 1–22. Essa especificação não comprova uma máscara estadual nem a existência do documento. xPed e xCont são campos distintos, para pedido e contrato.

Compare o conteúdo efetivamente transmitido, não apenas o cadastro atual ou a observação do DANFE. Uma integração pode conservar o valor de um pedido anterior mesmo depois de a tela ter sido corrigida. Registre também chave, série, número, horário, ambiente e UF/autorizador para localizar a tentativa.

Como agir em cada cenário

O XML levou a identificação de outra compra

Confira se o pedido foi copiado ou se o campo recebeu um contrato em lugar do empenho. Com a identificação correta comprovada pelo comprador, ajuste o vínculo da nota rejeitada no fluxo do emissor. Gere novamente o arquivo e confira xNEmp antes de transmitir.

Não use um empenho que funcionou em outra NF-e apenas para eliminar a mensagem. A referência deve representar o fornecimento atual. Se houver transformação ou perda do dado pela integração, o suporte precisa corrigir sua origem.

O comprador ainda não confirmou o documento

Solicite ao setor responsável a cópia ou confirmação formal do empenho relacionado à compra. Uma ordem de fornecimento sem essa identificação não esclarece, por si, qual documento deve ser informado.

Cabe ao órgão explicar eventual emissão, substituição ou mudança administrativa. Não conclua cancelamento pelo código 361. Uma nova identificação deve ser conferida com o responsável fiscal e vinculada à operação verdadeira antes de alterar a nota.

Documento e XML coincidem, mas o retorno persiste

Encaminhe a comparação ao suporte e, quando necessário, à SEFAZ competente. Peça esclarecimento sobre a validação aplicada e sobre o procedimento pertinente ao caso.

Indisponibilidade ou falta de sincronização de uma base é hipótese a confirmar. O MOC não estabelece espera universal de minutos, horas ou dias. Se o atendimento confirmar atualização pendente, guarde o protocolo e siga a orientação específica; uma nova tentativa deve ter fundamento, sem repetição automática para descobrir quando a base mudou.

O problema aparece somente em homologação

Confira o ambiente e o endereço do serviço realmente utilizado. A disponibilidade de um documento administrativo de produção numa base de testes não está comprovada por esta pesquisa.

Consulte o procedimento de testes oferecido pela UF. Não troque o empenho real por um dado fictício nem mude o ambiente da operação para contornar a rejeição.

Exemplo hipotético

Uma fornecedora recebe o empenho relativo à entrega de equipamentos. Ao copiar um pedido anterior, a integração conserva a identificação antiga em xNEmp, embora o documento da nova compra esteja correto.

Se a tentativa retornar 361, a equipe confronta o XML com a confirmação do comprador e encontra o vínculo divergente. Corrige sua origem, gera o novo arquivo e confere a identificação antes de transmitir. O exemplo é didático: não houve emissão real ou retorno observado, e ele não atribui formato, base ou prazo a uma UF.

Verifique o resultado e encaminhe as evidências

Leia a nova resposta associada à NF-e correta. O desaparecimento de 361 pode dar lugar a outra rejeição; isso ainda não demonstra autorização. Confirme o resultado e o protocolo correspondentes e preserve os arquivos da operação.

O órgão comprador esclarece o documento administrativo. O suporte investiga divergências entre cadastro e XML. O responsável fiscal analisa o enquadramento e a documentação cabível. A SEFAZ competente esclarece a validação quando a comparação não explica o retorno.

Encaminhe por canal adequado o XML, a resposta, a identificação confirmada, a chave, o horário e o ambiente. Informe o que coincide e o que diverge. Não invente número, altere UF ou modifique o fato fiscal para tentar obter autorização.

Fontes

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

• MOC 7.0, Anexo I: ZB02-30, 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, 361, Berga, 361 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.