Rejeição 735: unidade tributável da NFC-e e implementação futura
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 735 aparece no MOC como unidade de tributação inválida em NFC-e, regra I13-10: uTrib não consta de tabela específica. O manual assinala implementação futura, sem produção até sua publicação. Na pesquisa documental desta página, não foi localizada confirmação posterior suficiente de ativação e da tabela específica dessa identidade; não cabe tratá-la como exigência universal já implantada.
Onde está a unidade e por que ela importa
uTrib fica em det/prod e descreve a unidade tributável do item. qTrib é a quantidade nessa unidade e vUnTrib o preço unitário correspondente. Esses três campos formam uma representação quantitativa; mudar apenas o texto da unidade pode deixar quantidade e preço incoerentes. uCom, qCom e vUnCom são a representação comercial, que pode usar outra apresentação.
O schema define uTrib como texto de 1 a 6 caracteres. Esse limite não fornece uma lista completa de abreviaturas aceitas pela regra de negócio. Uma unidade caber no XSD não prova pertinência ao produto; uma lista interna do software também não se torna tabela oficial sem fonte e aplicação confirmadas.
Não transportar regras de outros contextos
A 854/I13-20 verifica a unidade kg para o código ANP de GLP especificado na regra. A 817/I14-10 relaciona unidade e NCM em operações documentadas de comércio exterior. Nenhuma dessas condições é a tabela genérica de NFC-e mencionada pela I13-10. Não use uma lista de comércio exterior como resposta automática para a 735.
Cenário sintético: uma operação comercial em caixas tem unidade tributável em unidades confirmada no cadastro, mas a integração copia o rótulo da caixa para uTrib e mantém qTrib em unidades. O primeiro problema demonstrável é a representação inconsistente. Corrigir essa cópia depende do cadastro validado; não exige inventar abreviatura supostamente universal.
Como apurar um retorno que menciona 735
Verifique se a mensagem é retorno real de autorização ou validação local. Preserve modelo, ambiente, UF/autorizadora, data, número do item e XML. Solicite ao emissor a versão da tabela e o ato que sustenta sua aplicação. Compare uTrib ao cadastro aprovado e a relação entre qTrib, vUnTrib e vProd. Se a tabela não estiver identificada, documente essa dependência em vez de testar abreviaturas ao acaso.
Sem tabela de ativação confirmada, um XML com unidade escolhida sugeriria solução indevida; o exemplo trabalha cadastro, campo gerado e relação quantitativa. Corrija apenas erro comprovado de origem ou de serialização. A unidade e os parâmetros fiscais efetivos precisam ser confirmados pelos responsáveis antes da geração de outra nota; preserve documentos autorizados e tentativas incertas.
Fontes oficiais
- MOC — Anexo I, Leiaute e Regras de Validação — 7.0: p.94, I13-10 e observação de implementação futura.
- Leiaute da NF-e e protocolo — PL_010f_v1.04 / leiauteNFe_v4.00.xsd: linhas 1085–1106, uTrib/qTrib/vUnTrib.