Não incide tributo, mas o documento fiscal continua obrigatório na transferência

O Decreto nº 12.955/2026 diz duas coisas que soam contraditórias: a transferência de bens entre estabelecimentos do mesmo contribuinte não sofre incidência de CBS, mas a emissão do documento fiscal continua obrigatória nessa mesma operação. Não é contradição. É uma separação que a legislação sempre fez, mas que a rotina fiscal tratou como sinônimo: tributo devido e obrigação de documentar são coisas diferentes, e a Reforma deixou isso mais explícito do que o regime anterior jamais deixou. Quem opera com mais de um estabelecimento sob o mesmo CNPJ raiz, movimentando insumo ou produto entre plantas, filiais ou centros de distribuição, vai encontrar essa separação de frente assim que o motor fiscal do SAP tiver que decidir o que fazer com uma nota sem imposto a recolher.

Duas regras que parecem se contradizer

O art. 6º, inciso II, do Decreto 12.955/2026 lista a transferência de bens entre estabelecimentos pertencentes ao mesmo contribuinte entre as hipóteses em que a CBS não incide. Texto lido por inteiro na fonte oficial: a norma trata como não incidência, não como isenção, não como suspensão. A diferença de categoria importa porque cada uma carrega consequência fiscal própria, e o enquadramento errado no cClassTrib muda o que a nota declara ao fisco.

Isenção depende de ato que a concede e pode ser revista. Suspensão empurra o tributo para um momento posterior, com condição a cumprir. Não incidência é outra categoria: a operação, por definição legal, está fora do campo de aplicação do tributo desde a origem, sem prazo e sem condição pendente. Tratar a transferência como se fosse isenção, na prática do cadastro fiscal, cria uma pendência que a lei não exige e que também não bate com o código correto quando outro sistema ou outra fiscalização lê o documento.

O art. 115, inciso II, da mesma norma, trata de outra coisa: a obrigação de emitir documento fiscal nas operações de transferência entre estabelecimentos do mesmo contribuinte. O texto confirmado na fonte oficial é direto: a emissão continua valendo inclusive quando não há tributo a recolher na operação. Não há condicionante de valor, de tipo de bem ou de distância entre os estabelecimentos.

O erro de leitura mais comum não está em nenhum dos dois artigos isolados. Está em somar os dois errado: ler "não incide" como "não precisa de nota" ou, pior, como "não precisa de campo fiscal preenchido". A norma não libera o documento. Ela libera o tributo. O documento continua precisando declarar corretamente que aquela operação é, de fato, uma transferência sem incidência, e isso exige um código de classificação tributária específico, não a ausência de código.

Na prática do cadastro, isso significa dois campos de decisão separados: um define se há valor de CBS a recolher, outro define qual código de classificação a nota carrega. Tratar os dois como a mesma decisão é o que faz o segundo campo sair errado mesmo quando o primeiro está certo.

O que a NT pede em transferência

A nota técnica que organiza o leiaute da NF-e para a coexistência de ICMS, IBS e CBS trouxe um grupo de campos específico para o cClassTrib: o código que classifica o tratamento tributário de cada item na nota. Operação sem incidência tem código próprio dentro desse grupo. Não é o mesmo código de operação tributada com alíquota zero, não é o mesmo código de isenção, e não é ausência de preenchimento. É uma classificação positiva: a nota declara ativamente que aquele item, naquela operação, está fora da base de incidência pelo motivo correto.

Isso muda o comportamento esperado do motor fiscal dentro do SAP. A rotina de emissão precisa reconhecer o tipo de movimento (pedido de transferência, remessa, entrada correspondente) e aplicar o CFOP e a classificação fiscal compatíveis com não incidência, não simplesmente zerar o grupo de impostos ou herdar a classificação de uma venda comum. Quando o motor fiscal trata a transferência como "operação sem imposto, portanto sem necessidade de parametrização específica", o campo de classificação sai errado, mesmo que o valor do imposto esteja corretamente zerado.

Esse é o tipo de erro que não aparece na emissão. A nota sai, o sistema não acusa falha de cálculo porque não há imposto a calcular, e o processo segue adiante. Na prática, quem costuma pegar esse erro primeiro não é o emissor: é o sistema de destino que recebe a nota, ou uma auditoria que cruza o código declarado contra o tipo de movimento real.

O cClassTrib de uma transferência não é só um dado de saída. É também um dado de entrada no estabelecimento de destino.

Se a nota de remessa carrega a classificação errada, o lançamento de entrada correspondente herda o mesmo erro, e a cadeia de rastreabilidade do item, do estoque fiscal até o relatório de apuração, carrega a inconsistência adiante. Corrigir isso depois de meses de movimentação significa reabrir lançamentos já conciliados, não apenas ajustar um cadastro isolado.

Efeito em uma empresa com várias plantas

Empresas com múltiplos estabelecimentos sob a mesma raiz de CNPJ, típicas de cadeias industriais com plantas de produção separadas de centros de distribuição ou de unidades comerciais, vivem a transferência entre filiais como rotina operacional, não como exceção. Resina, insumo intermediário, produto semiacabado, matéria-prima armazenada num centro e consumida em outro: cada movimento desses, quando cruza a fronteira de um estabelecimento para outro, gera documento fiscal próprio.

O padrão que costuma se repetir na operação de grupos industriais multiestabelecimento é a parametrização de transferência herdada do regime do ICMS, nunca revisitada para a chegada do CBS e do IBS. A lógica de CFOP para transferência já existia e já funcionava. O risco é presumir que, porque o fluxo de CFOP estava certo, o grupo de campos de IBS e CBS também está, sem checar se o cClassTrib correspondente foi de fato mapeado para esse tipo específico de movimento.

Quanto mais estabelecimentos ativos sob a mesma raiz, maior o número de combinações de pares de origem e destino que precisam de teste individual, e essa conta não cresce de forma linear: o número de pares que de fato trocam mercadoria sobe mais rápido do que o número de plantas, porque nem todo estabelecimento troca material com todos os outros. Cada par pode ter configuração de tipo de movimento diferente no SAP. O critério prático de priorização é simples: testar primeiro os pares com maior volume de movimentação recorrente, porque é ali que um cClassTrib errado se multiplica mais rápido em documentos emitidos, e só depois cobrir os pares esporádicos.

A armadilha se repete em outras obrigações da Reforma

Essa distinção entre não incidência do tributo e permanência da obrigação acessória não é exclusiva da transferência entre estabelecimentos. É um padrão que aparece em outros pontos da Reforma Tributária: a suspensão temporária da rejeição automática de uma nota por inconsistência de campo não suspende a obrigação de informar o dado corretamente, só adia a penalidade de rejeição imediata. Quem lê "suspensão da rejeição" como "suspensão da obrigação" carrega o mesmo erro de leitura que aparece na transferência.

Essa é uma leitura nossa, não um fato publicado em norma específica sobre o tema: a Reforma Tributária, ao longo de 2026, tem produzido várias dessas situações de "tolerância sem dispensa", e o time fiscal que trata cada uma isoladamente, sem nomear o padrão, corre o risco de repetir a mesma correção várias vezes em pontos diferentes do sistema.

"O tributo não incide aqui, mas existe obrigação acessória que sobrevive?" Essa pergunta fixa de checklist evita redescobrir o mesmo padrão em cada norma nova.

O ganho prático de nomear o padrão cedo é metodológico, não jurídico: times que tratam cada nova regra da Reforma como um evento isolado acabam revisitando a mesma pergunta de parametrização várias vezes, em pontos diferentes do SAP. Quem registra a distinção "o que o tributo exige" versus "o que o documento exige" como critério permanente de leitura reduz o retrabalho nas próximas obrigações que chegarem com a mesma estrutura.

O teste que o time fiscal deve fazer

A pergunta executiva é direta: qual percentual das notas fiscais emitidas entre estabelecimentos do mesmo grupo hoje tem o grupo de campos de IBS e CBS preenchido com a classificação tributária correta para não incidência, e não apenas com valor zerado? A resposta está na leitura do cClassTrib efetivamente gravado em cada documento de transferência, comparado contra o que o art. 6º e o art. 115 do Decreto 12.955/2026 exigem em conjunto.

O teste funcional correto roda por par de estabelecimentos, não por empresa inteira. Cada combinação de origem e destino precisa de um documento de teste que simule o movimento real: pedido de transferência, remessa, e a entrada correspondente no estabelecimento de destino. O resultado esperado é a classificação tributária de não incidência aparecendo corretamente no grupo de campos, com o CFOP compatível e sem herdar a configuração de uma operação de venda.

O padrão que costuma aparecer quando esse teste é feito pela primeira vez num grupo multiestabelecimento é revelador: o par de estabelecimentos mais antigo, configurado ainda no regime do ICMS, costuma estar correto por acomodação histórica, enquanto o par mais recente, criado depois de uma expansão ou aquisição, é o que carrega a parametrização copiada às pressas e nunca revisada.

Art. 115, II, do Decreto 12.955/2026, confirmado na fonte oficial: a emissão de documento fiscal é exigida também "à transferência de bens entre estabelecimentos pertencentes ao mesmo contribuinte".

Quem já parametrizou esse tipo de fluxo sabe que o teste não termina na primeira nota que sai sem erro. Termina quando cada par relevante foi testado individualmente e o resultado documentado, porque é esse registro que sustenta a resposta no dia em que a malha fiscal ou uma auditoria perguntar como a empresa tratou essa operação especificamente.

Teste de emissão não é teste de ciclo completo. Validar que a nota sai com o cClassTrib correto resolve só metade do fluxo: a outra metade é confirmar que a entrada correspondente, no destino, reconhece essa classificação e não reprocessa o item como se fosse uma aquisição tributada comum. Um teste que para na emissão deixa exatamente o ponto cego que a auditoria costuma encontrar primeiro.

O que verificar antes de considerar o fluxo pronto

Três pontos concentram o risco real. Primeiro, o cClassTrib usado hoje na transferência está mapeado para o código específico de não incidência, ou está herdando um código genérico de outra operação. Segundo, o motor fiscal distingue transferência de produto acabado, insumo e material intermediário, porque a regra de origem pode variar conforme o tipo de bem movimentado. Terceiro, a rotina de teste cobre todos os pares ativos de estabelecimentos, não apenas o par mais usado ou o primeiro que foi configurado no projeto original.

Nenhum desses três pontos aparece como erro na tela do usuário. A nota sai, o processo segue, o relatório de faturamento fecha. O risco fica silencioso até o momento em que alguém de fora da operação lê o documento fiscal isoladamente e espera encontrar ali a prova de que a empresa classificou a transferência corretamente, não apenas que deixou de cobrar imposto sobre ela.

Um quarto ponto, menos óbvio, merece checagem: quem no time fiscal é o dono dessa parametrização depois que o projeto de adequação à Reforma termina. Parametrização de transferência tende a ser configurada uma vez e esquecida, sem dono definido para revisão quando um novo estabelecimento entra em operação. Sem esse dono, a configuração correta de hoje vira a divergência não percebida de daqui a um ano.

O Diagnóstico Fiscal Estruturado da DFSpro mapeia exatamente esse tipo de fluxo: como cada par de estabelecimentos trata a transferência no SAP hoje, onde o cClassTrib está divergente do exigido pelo Decreto 12.955/2026, e o que precisa de ajuste de parametrização antes que a divergência vire achado de auditoria. A tese de classificação tributária continua sendo do cliente. O que a DFSpro prova, com documento de teste real, é como o sistema se comporta em cada tipo de transferência.