Na compra de grão, quem emite a nota de crédito presumido é você, não o produtor

Quando uma agroindústria compra grão de um produtor não contribuinte, é ela quem emite o documento fiscal da operação, e é ela quem responde pelo campo que discrimina o crédito presumido ali dentro. Isso inverte uma lógica que boa parte do time fiscal ainda carrega de cabeça: a de que erro de nota é problema de quem vende. Nessa operação específica, quem vende não emite nada. Quem compra, emite tudo.

A Resolução CGIBS 6/2026, no artigo 246, trata exatamente dessa inversão. Para fins de apropriação do crédito presumido, o adquirente deve emitir documento fiscal relativo à aquisição que discrimine o valor da operação, o valor do crédito presumido e o valor líquido pago ao fornecedor. Não é o produtor rural que presta essa informação ao fisco. É quem compra.

Essa inversão de papel costuma passar despercebida justamente porque o produtor não participa do processo de emissão. Ele recebe o pagamento líquido e segue a vida dele. O risco fica inteiro do lado de quem compra, sem que ninguém do lado de fora da operação precise avisar.

O que o regulamento exige discriminar

Três valores precisam aparecer de forma separada e coerente entre si no documento emitido pelo comprador: o valor total da operação de aquisição, o valor do crédito presumido calculado sobre essa operação, e o valor líquido que efetivamente sai do caixa da empresa compradora para o produtor.

Esses três números não são independentes. Eles se amarram por uma fórmula, e se um dos três estiver errado, a inconsistência aparece na escrituração, não necessariamente na nota em si.

O crédito presumido existe porque o produtor não contribuinte não recolhe IBS nem CBS na venda, mas a cadeia precisa manter a não cumulatividade do tributo. A solução regulatória foi atribuir ao comprador o cálculo e o registro desse crédito presumido no próprio documento de aquisição, como se o comprador estivesse ao mesmo tempo comprando o grão e emitindo, para si, o crédito que a operação gera.

Essa discriminação não é um campo de observação livre. Ela segue leiaute técnico definido por Nota Técnica e por tabela de classificação, e é exatamente aí que o risco técnico se concentra: o valor pode estar certo e o documento ainda assim sair inválido, porque o código de classificação usado não corresponde à versão vigente da tabela.

Vale notar que o percentual ou a base de cálculo do crédito presumido pode variar conforme a natureza do produto e a hipótese legal enquadrada, o que significa que um erro na classificação não é apenas um problema de formato de leiaute. Ele pode alterar o próprio valor do crédito calculado, gerando uma apropriação a maior ou a menor sem que ninguém perceba até a conciliação com a escrituração.

O documento também precisa manter numeração sequencial própria e rastreável dentro da série fiscal do emissor, assim como qualquer outro documento fiscal de aquisição. Tratar essa emissão como um registro à parte, fora do controle sequencial padrão, é o tipo de atalho operacional que parece inofensivo até o momento em que a escrituração fiscal precisa reconciliar essa série específica com o restante das notas emitidas no período.

O que a versão 1.52 da NT e a tabela 1.70 trazem

O Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 8, de 2026-09-29, aprovou a versão 1.52 da NT 2025.002, que trata das adequações de NF-e e NFC-e para o novo modelo tributário, e o Informe Técnico 2025.002, que na versão 1.70 traz as tabelas de Código de Classificação Tributária, de CST e de Classificação do Crédito Presumido do IBS e da CBS.

A tabela de Classificação do Crédito Presumido é a peça que interessa diretamente a esse tipo de operação. Ela define, por código, em qual hipótese legal aquele crédito presumido específico se enquadra, e o emissor precisa escolher o código certo entre as opções disponíveis na versão vigente da tabela, não em uma versão anterior que ele ainda tem configurada no sistema.

A tabela de classificação de crédito presumido já mudou várias vezes ao longo de 2026, e o campo que parece puramente administrativo é exatamente o que sustenta o crédito diante da fiscalização.

Um código de classificação desatualizado não necessariamente impede a emissão do documento. O risco mais comum em leiautes técnicos desse tipo não é a rejeição na hora, que ao menos avisa que algo quebrou. É a aceitação silenciosa de um código que tecnicamente existe, mas que já não corresponde à hipótese correta da operação, gerando crédito mal classificado que só aparece como divergência numa auditoria posterior.

Aceito na hora não significa correto na origem.

O CST associado à operação também muda de versão para versão, e nem sempre na mesma velocidade que o código de classificação do crédito presumido. Isso cria uma janela em que os dois campos podem estar desalinhados entre si: um atualizado, o outro não, produzindo um documento que passa na validação técnica do schema, mas que descreve uma combinação fiscal que não existe mais na forma como foi registrada.

Onde o SAP gera e valida esse documento

No ambiente SAP, a emissão de um documento fiscal de aquisição desse tipo passa por uma camada de determinação de código fiscal que lê parâmetros de material, de fornecedor e de operação para decidir qual classificação tributária se aplica. Essa camada precisa ter a tabela de Classificação do Crédito Presumido parametrizada na versão correta, e precisa saber, para cada combinação de material e tipo de fornecedor, qual código discriminar.

Quando a camada de cálculo fiscal roda sobre Guepardo Tax ou sobre outra camada de cálculo acoplada ao SAP, essa tabela de classificação normalmente não vive dentro do próprio SAP core. Ela vive numa tabela de parâmetros fiscais mantida à parte, e a sincronização entre a versão publicada pelo órgão regulador e a versão parametrizada nessa camada depende de alguém atualizar manualmente, ou de uma rotina automatizada que poucas operações têm implementada hoje.

Cadastro de fornecedor também entra nessa cadeia de determinação. Se o cadastro do produtor rural não estiver corretamente identificado como não contribuinte no sistema, a lógica de determinação de código pode nem acionar a rota de crédito presumido, tratando a operação como uma aquisição comum e deixando de gerar o documento com a discriminação exigida.

Vale testar também o cenário de aquisição mista, quando um mesmo lote de nota agrega grão de produtores com naturezas tributárias diferentes dentro de uma mesma operação logística. Nesse cenário, a determinação de código precisa segregar corretamente cada origem, porque aplicar um único código de classificação para o lote inteiro é o tipo de simplificação que funciona na prática até a primeira auditoria cruzar volume físico recebido com documento fiscal emitido por fornecedor.

Outro ponto que costuma escapar da revisão inicial é o tratamento de devolução ou de cancelamento de uma aquisição já documentada com crédito presumido discriminado. O estorno precisa desfazer, de forma simétrica, tanto o registro do crédito quanto o valor líquido pago, e a camada de determinação de código raramente é testada para esse caminho inverso com o mesmo rigor aplicado à emissão original.

A unidade federativa de origem do produtor também pode influenciar a hipótese de crédito presumido aplicável, dependendo de como o CGIBS regulamentar situações de alíquota diferenciada por operação interestadual. Um cadastro de fornecedor sem o estado de origem corretamente atualizado é outro ponto silencioso de falha na determinação do código correto.

Rotina de atualização por versão

Tabela de classificação tributária publicada pelo órgão regulador não é documento estático. Ela já teve mais de uma versão em 2026, e cada nova versão pode adicionar código, descontinuar código ou alterar a descrição de uma hipótese já existente sem necessariamente renumerar o código correspondente.

Isso exige uma rotina formal de comparação entre a versão vigente no sistema e a versão publicada pelo Portal, não uma atualização reativa feita só quando alguma nota começa a ser rejeitada. A pergunta prática que sustenta essa rotina é simples: quando foi a última vez que alguém comparou, código a código, a tabela parametrizada no SAP ou na camada de cálculo fiscal com a versão mais recente publicada.

Essa comparação não precisa ser feita a cada publicação de ato técnico, mas precisa ter dono definido e periodicidade mínima estabelecida, porque o calendário de publicação de novas versões tem acompanhado de perto o calendário mais amplo de implementação da Reforma Tributária, e não há sinal de que a frequência de mudança vá cair tão cedo.

Quem assume essa manutenção também precisa estar claro: time fiscal interno, integrador de sistemas, ou prestador de AMS Fiscal contratado para sustentação. É esse nome que normalmente é chamado quando a fiscalização questiona um código específico, e é a existência ou não desse nome que determina se a defesa do crédito começa no mesmo dia da notificação ou só depois de uma negociação interna sobre quem assume a resposta.

Dono definido para a tabela é o que separa atualização programada de atualização descoberta sob pressão de fiscalização.

Vale também manter um histórico documentado de qual versão da tabela estava vigente em cada período, não apenas a versão atual. Esse histórico é o que permite, meses depois, reconstruir com segurança por que um determinado documento usou um código específico, em vez de depender da memória de quem fez a parametrização naquele momento.

Além do histórico de versão, vale manter registro de quem aprovou cada mudança de parametrização antes de ela entrar em produção, com data e ambiente de teste onde a mudança foi validada. Esse registro evita que uma alteração feita sob pressão de prazo seja aplicada direto em produção sem o mesmo rigor de homologação que qualquer outra mudança fiscal relevante deveria receber.

O campo de classificação do crédito presumido parece burocracia de leiaute. Na prática, é o dado que a fiscalização usa para validar se o crédito apropriado tem lastro.

A amostra de teste e o controle mínimo de versão

Antes de assumir que o leiaute está correto, vale rodar uma amostra real de documentos de aquisição emitidos no período mais recente e verificar, nota a nota, se o código de classificação de crédito presumido usado corresponde à versão vigente da tabela na data da emissão, não na data da verificação.

Essa amostra deveria cobrir diferentes combinações de material e de tipo de fornecedor não contribuinte, porque a determinação de código no SAP costuma variar por essas duas dimensões, e um teste que valida apenas um cenário comum deixa de fora justamente as combinações menos frequentes, que são as que recebem menos atenção na manutenção do dia a dia.

A amostra também deveria incluir pelo menos um caso de devolução ou cancelamento, exatamente pelo risco já descrito de o caminho inverso não receber o mesmo cuidado de parametrização que a emissão original recebeu.

O controle mínimo de versão combina três elementos: um responsável nomeado pela comparação periódica entre tabela parametrizada e tabela publicada, um registro de quando cada versão entrou em vigor no sistema, e uma amostra recorrente de documentos emitidos para confirmar que o código aplicado é o esperado para aquele período. Sem esses três elementos juntos, a conformidade do leiaute depende de sorte, não de processo.

Três elementos, um só dono, nenhuma lacuna de versão sem explicação registrada.

Vale também conferir se o volume de documentos emitidos nessa modalidade é compatível com o volume físico de aquisição de produtor não contribuinte registrado em outras frentes da operação, como o controle de recebimento no pátio ou na balança. Divergência entre esses dois números é sinal de que parte das aquisições pode estar sendo documentada fora da rota correta de crédito presumido.

Esse é o tipo de verificação que um Diagnóstico Fiscal Estruturado em ambiente SAP mapeia na camada de determinação de código fiscal e na parametrização de tabelas, antes que uma divergência de classificação vire questionamento sobre crédito já apropriado.