xCont na NF-e: contrato de compra e diferença para nota de empenho

xCont informa o contrato de compra no grupo compra. Seu caminho é /nfeProc/NFe/infNFe/compra/xCont. Apesar de nomes comerciais ou rótulos de sistemas poderem divergir, este campo representa o contrato; a nota de empenho é xNEmp e o pedido é xPed, conforme os itens ZB02–ZB04 do MOC.

Que referência deve vir do contrato?

Use a identificação que consta no documento contratual e permite ao comprador relacionar a nota ao contrato correspondente. Não transforme o número interno de uma venda, o número da NF-e ou o empenho em contrato apenas para preencher a tag. Confirme com os documentos da operação quando o comprador usar identificador composto, como número/ano ou código de unidade.

O campo é textual, de 1 a 60 caracteres quando informado, e ocorre 0..1 dentro de compra. Letras, barras e zeros iniciais podem fazer parte da referência. Preserve o conteúdo documental e evite conversão para inteiro, que apagaria zeros. A omissão estrutural é diferente de enviar <xCont/>: elemento presente precisa ter conteúdo válido.

xCont não contém o texto integral de um contrato nem demonstra suas cláusulas ou validade. O tamanho não autoriza cortar um identificador verdadeiro sem analisar o padrão de conciliação. Se o dado exceder o limite, confirme qual referência documental cabe no campo e ajuste a integração de origem.

Como fica o contrato no XML?

Hipótese sintética: contrato identificado como CT-0042/2026. O fragmento é parcial em relação à NF-e e não representa contrato real:

<compra xmlns="http://www.portalfiscal.inf.br/nfe">
  <xCont>CT-0042/2026</xCont>
</compra>

O grupo pode conter só o contrato porque seus outros filhos são opcionais. Se também houver empenho e pedido, eles antecedem xCont, na sequência xNEmp, xPed, xCont. Tags trocadas de ordem podem falhar no XSD mesmo com referências verdadeiras.

O contrato resolve uma rejeição de empenho?

Não. Informar xCont não preenche xNEmp. A regra ZB02-10/359 examina falta de empenho em NF-e com a condição específica de desoneração de ICMS por venda a órgão público (motivo 8), com implementação facultativa por UF. Já 360/361 tratam do empenho inválido/inexistente. O contrato não substitui esse dado, e a compra pública não autoriza escolher um motivo de desoneração.

Em NFC-e, a presença de compra, mesmo contendo apenas xCont, é objeto da rejeição 762. O contexto correto inclui o modelo, não apenas a validade lexical do campo.

Como conferir contrato diferente no recebimento?

Compare o documento contratual, a referência armazenada na venda e compra/xCont no XML efetivo da mesma nota. Se o XML contiver o pedido no lugar do contrato, revise o mapeamento dos três identificadores. Se o XML estiver correto, mas o relatório do comprador mostrar outro valor, examine qual campo esse relatório lê. Quando houver mais de um contrato, a ocorrência única não oferece uma lista ilimitada: confirme o escopo documental e o padrão exigido pelo comprador antes de concatenar ou perder referências. A representação técnica não decide a validade da contratação nem a tributação da operação.

Fontes técnicas

MOC 7.0 — Anexo I — 7.0: p. 64, ZB02–ZB04; p. 127, ZB01-10 e ZB02-10/20/30.

XSD NF-e/NFC-e — PL_010f_v1.04: linhas 6321–6362, compra/xCont.