É a mensagem de rejeição da NFS-e que mais aparece nas buscas hoje — e ela existe em duas versões que dizem o contrário uma da outra.
Entre as mensagens de rejeição da NFS-e no grupo de IBS/CBS, uma aparece com frequência bem maior que as outras na internet, e quase sempre colada inteira, do jeito que o sistema devolveu:
"Código do tipo de Operação (tpOper) não pode ser informado quando não se tratar de uma compra governamental ou um dos serviços da LC 116/2003 listados: 25.05; 15.09; 17.12; 10.05."
Quem cola essa frase no buscador normalmente está com a nota parada. E costuma procurar a resposta no lugar errado, porque a mensagem tem uma irmã gêmea que diz exatamente o contrário.
Duas regras, não uma
O campo tpOper, dentro do grupo de IBS/CBS da DPS, tem duas regras de negócio opostas:
Uma exige o campo. O texto oficial: "tpOper deve ser informado se tpEnteGov for informado ou se o serviço prestado (cTribNac) corresponder aos serviços listados da LC 116/2003 (e seus correspondentes na NBS): 25.05; 15.09; 17.12; 10.05."
A outra proíbe o campo. O texto oficial: "tpOper não pode ser informado se tpEnteGov não for informado ou o serviço (cTribNac) não corresponder aos serviços da LC 116/2003 (e seus correspondentes na NBS): 25.05; 15.09; 17.12; 10.05."
As duas rejeitam — não são avisos. E as duas nascem no mesmo lugar do XML, dentro do grupo IBSCBS da DPS. Ou seja: o campo é obrigatório num conjunto fechado de situações, e proibido em todo o resto. Não existe terreno neutro, e é por isso que preencher "por garantia" produz rejeição em vez de segurança.
Que serviços são esses
A mensagem cita quatro subitens por número, e não diz o que são. São estes, na lista da LC 116/2003:
Repare na companhia: cemitério, leasing, administração de bens de terceiros e corretagem. Não é um grupo que o emissor comum reconheça como "o meu caso". Por isso a rejeição costuma pegar de surpresa — o campo foi preenchido por quem não presta nenhum desses quatro serviços.
A outra porta de entrada é a compra governamental: o tpEnteGov. Se o tomador é ente governamental e o campo foi informado, o tpOper passa a ser exigido. Se não é, e o serviço não está entre os quatro, o tpOper não pode aparecer.
Como depurar em três perguntas
A pergunta não é "qual valor pôr no tpOper". É "este campo deveria existir nesta nota".
Primeira: o tomador é ente governamental, e o tpEnteGov está preenchido? Se sim, o tpOper é exigido.
Segunda: o serviço desta nota corresponde a 25.05, 15.09, 17.12 ou 10.05 — pelo código de tributação nacional, não pela sua impressão? Se sim, exigido.
Terceira: se as duas respostas forem não, o campo precisa sair da nota. Não é preencher com zero nem com um valor neutro: é não informar.
O lugar de corrigir quase nunca é a nota. É o cadastro do serviço, ou o trecho do sistema que monta o grupo de IBS/CBS e inclui o campo sempre, por padrão. Um emissor que escreve o tpOper em toda nota vai acertar nas quatro situações e errar em todas as outras.
O texto integral das regras de negócio está no Anexo VI da Nota Técnica SE/CGNFS-e nº 009/2026, publicado no portal da NFS-e: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc — e a lista pública dos códigos de rejeição, com o campo do XML de cada um e o efeito declarado, está em https://kalvi.com.br/rejeicoes
O resumo para o escritório
A mensagem do tpOper não é um erro de digitação, é um erro de regra: o sistema está dizendo que o campo não deveria estar ali. Preencher por precaução, nesse campo, produz exatamente o problema que se queria evitar. E como o erro nasce na configuração, uma nota conferida resolve a fila inteira daquele cliente.
Por: Marco Aurélio
Fonte: Portal Contábeis.
