A SAP embarcou o Claude como motor de raciocínio primário no Joule, o assistente que agora promete agir em finanças, compras e supply — com mais de 30 agentes especializados e milhares de Joule Skills. O discurso é sedutor: o agente “reage em tempo real”, detecta um risco de ruptura, redireciona um pedido, ajusta o plano de compras. E, com a nova safra de modelos mais capazes, a promessa ficou ainda mais convincente.
Só que, no Brasil, cada uma dessas ações não é um evento abstrato — é uma transação fiscal. E o fiscal saiu do calendário e entrou em produção: o destaque de IBS/CBS na NF-e é obrigatório desde 01/08/2026 (com penalidades), os catálogos tiveram de revisar NCM, CST e cClassTrib por SKU, e o split payment já roda em alíquota-teste. Um cérebro mais esperto agindo sobre uma fundação fiscal não reconciliada não corrige o problema — ele escala o erro mais rápido: rejeição de NF-e, crédito calculado errado, conciliação impossível. O modelo melhora a decisão; a sua realidade integrada e localizada continua sendo o terreno onde o agente pisa. (Registro de precisão: a virada do Joule para “front door” e o Autonomous Enterprise foram apresentados no Sapphire, em maio de 2026; o gancho aqui é o contraste, na semana da Dreamforce, entre o agente “em tempo real” e o fiscal brasileiro que virou obrigatório em 01/08 — não um anúncio inédito.)
O que muda com Claude no motor do Joule: um agente que “reage em tempo real”
O SAP Joule é o copiloto/assistente de IA da SAP, integrado ao S/4HANA e ao ecossistema de aplicações da empresa. Com o Claude como motor de raciocínio primário, o Joule deixa de ser apenas um respondedor de perguntas e passa a orquestrar agentes que executam: em compras, ele pode sugerir e acionar um pedido; em supply, redirecionar um envio diante de um risco; em finanças, propor um lançamento ou uma conciliação. A narrativa da SAP é a do “Autonomous Enterprise” — a empresa em que o software não só informa, mas age.
Tecnicamente, é um avanço real. Um modelo de raciocínio mais forte erra menos, entende melhor o contexto e encadeia passos com mais competência. O ponto que este artigo levanta não é contra o Joule nem contra o Claude — é sobre onde a decisão do agente vira resultado. Porque um agente que decide “bem” ainda precisa que a ação que ele dispara aterrisse num sistema íntegro, integrado e, no Brasil, fiscalmente correto. É aí que a conversa muda de “qual modelo” para “qual fundação”.
No Brasil, cada ação do agente vira transação fiscal: IBS/CBS na NF-e obrigatório desde 01/08
Aqui está o detalhe que o discurso de “tempo real” costuma pular. Quando o agente do Joule aciona uma compra, redireciona um pedido ou ajusta um plano de supply, ele não termina numa tela — ele gera (ou depende de) documentos fiscais. E, no Brasil de 2026, esses documentos mudaram.
Desde 01/08/2026, o destaque de IBS e CBS na NF-e é obrigatório, com penalidades para quem não cumprir. Na prática, isso significou que os catálogos tiveram de revisar, por SKU, a classificação fiscal — NCM, CST e o novo cClassTrib — até o início de agosto. Não é uma configuração global que se ativa num botão: é um trabalho de reconciliação item a item, porque a tributação correta de cada produto depende de como ele está classificado. Um agente que “age em tempo real” sobre um catálogo com classificação fiscal inconsistente vai, em tempo real, gerar NF-e que o próprio SEFAZ rejeita — ou, pior, aceitar documentos com tributo destacado errado, que só explodem na apuração.
Vale destacar o que é o cClassTrib, porque ele é a novidade que pega muita operação de surpresa: é o código de classificação tributária introduzido pela reforma para dizer, de forma padronizada, qual regra de tributação de IBS/CBS se aplica a cada item — se há incidência normal, alíquota reduzida, isenção, diferimento ou algum regime específico. Ele não substitui o NCM (que descreve o que é o produto); ele determina como aquele produto é tributado no novo modelo. Preencher o cClassTrib errado, ou deixá-lo em branco, é uma das causas mais comuns de rejeição da NF-e a partir de agosto — e é exatamente o tipo de campo que um agente rápido replica em escala se a base não estiver curada por SKU.
O ponto é estrutural: a velocidade do agente amplifica tanto o acerto quanto o erro. Se a fundação fiscal está reconciliada, o “tempo real” é uma vantagem. Se não está, o “tempo real” é uma máquina de multiplicar rejeição.
Split payment (teste de 1% em 2026, opcional entre empresas a partir de 2027) e o que muda no ERP
A segunda peça é o split payment — o recolhimento do tributo no momento da liquidação financeira da operação. Em 2026, ele roda em alíquota-teste de 1% (composta por 0,9% de CBS e 0,1% de IBS) e, a partir de 2027, passa a ser opcional entre empresas. O Manual de Integração da Plataforma Pública, base técnica desse mecanismo, foi publicado em meados de 2026 (no arcabouço da LC 214/2025 e da LC 227/2026).
Para o ERP e para o agente que age sobre ele, isso não é um detalhe contábil distante. O split payment muda o fluxo de caixa esperado de cada transação e a forma como o valor do tributo é separado, recolhido e conciliado. Um agente de compras ou de finanças que raciocina sobre valores “cheios”, sem entender que parte do pagamento é retida e recolhida na origem, vai propor conciliações que não fecham e decisões financeiras baseadas em números que já não correspondem à realidade da liquidação. De novo: o modelo pode ser excelente; se o dado sobre o qual ele age não reflete o split payment, a decisão nasce errada.
Por que cérebro rápido sobre fundação não reconciliada escala o erro
Junte as duas peças e o padrão fica evidente. Três falhas concretas aparecem quando um agente veloz opera sobre uma fundação que não foi reconciliada.
A primeira é a rejeição de NF-e. Se a classificação por SKU (NCM/CST/cClassTrib) está inconsistente, cada nota que o processo dispara tem chance de ser rejeitada pelo SEFAZ — e um agente que dispara mais rápido apenas produz rejeições mais rápido, entupindo a operação em vez de destravá-la.
A segunda é o crédito calculado errado. No modelo de IBS/CBS, o crédito depende do que foi corretamente destacado nas operações de entrada. Se o fiscal de entrada não está reconciliado, o agente age sobre um saldo de crédito fictício — e decisões de compra e precificação tomadas sobre esse saldo saem distorcidas.
A terceira é a conciliação impossível. Quando dado de ERP (SAP) e dado de sistemas não-SAP (e-commerce, fornecedor, gateway, fiscal) não conversam em tempo real e de forma reconciliada, ninguém consegue fechar o que o agente fez com o que de fato aconteceu. O agente vira uma caixa-preta rápida: age muito, e ninguém consegue auditar se agiu certo. Em todos os três casos, o gargalo não é a inteligência do modelo — é a integridade da fundação embaixo dele.
Como a CCX reconcilia a fundação antes do agente agir
Na CCX, o pré-requisito para soltar um agente sobre o SAP no Brasil é reconciliar a fundação — e isso se apoia em três frentes.
Primeiro, a integração SAP↔não-SAP. Pela frente de Integrações & APIs Enterprise, com expertise em SAP Commerce Cloud e Protheus e nos protocolos nativos do ecossistema — OData, iDoc e RFC —, conectamos o ERP em tempo real ao e-commerce, ao fornecedor, ao gateway e ao antifraude, com arquitetura event-driven (Kafka/RabbitMQ), idempotência e contratos de API explícitos. É o encanamento que sincroniza estoque, preço, pedido e nota fiscal para que o agente aja sobre dado reconciliado ponta a ponta, não sobre silos que se contradizem.
Segundo, o dado e o fiscal de entrada reconciliados. Pela frente de Data & Business Intelligence, montamos os pipelines e a reconciliação que garantem que a classificação por SKU (NCM/CST/cClassTrib), o destaque de IBS/CBS e o split payment estejam corretos antes de o agente tocar a transação — com ferramentas modernas (BigQuery, Snowflake, Looker, Power BI) e o dado de entrada tratado como fonte de verdade.
Terceiro, o clean core e a due diligence. Pela Consultoria em Tecnologia, fazemos o diagnóstico do que precisa estar certo por design antes do agente agir (arquitetura-alvo, roadmap, TCO), respeitando o princípio de clean core do S/4HANA para que a customização não vire dívida. Uma squad dedicada (onboarding em 48h, engenheiros com mais de 10 anos) opera a travessia, com compliance LGPD/SOC 2. Cérebro rápido sobre dado certo é vantagem; sobre dado errado, só erra mais cedo.
Quer reconciliar a fundação antes de soltar o agente? Fale com a CCX sobre Integração SAP ↔ e-commerce. A fundação e o clean core que o Joule precisa vivem em Consultoria em Tecnologia; o dado reconciliado e o fiscal de entrada IBS/CBS, em Data & BI; a frente SAP completa, em ccxcompany.co/br/sap.
Perguntas frequentes (FAQ)
O que é o SAP Joule?
O Joule é o assistente/copiloto de IA da SAP, integrado ao S/4HANA e ao ecossistema de aplicações da empresa. Com um modelo de raciocínio forte no motor (o Claude, como motor primário), ele deixa de apenas responder perguntas e passa a orquestrar agentes que executam ações em finanças, compras e supply — a base da narrativa do “Autonomous Enterprise” da SAP.
O destaque de IBS/CBS na NF-e é obrigatório?
Sim. Desde 01/08/2026, o destaque de IBS e CBS na NF-e é obrigatório no Brasil, com penalidades para o descumprimento. Isso exigiu a revisão da classificação fiscal por SKU (NCM, CST e o novo cClassTrib), porque a tributação correta de cada item depende de como ele está classificado.
Como funciona o split payment em 2026?
O split payment separa e recolhe o tributo no momento da liquidação financeira da operação. Em 2026, roda em alíquota-teste de 1% (0,9% de CBS + 0,1% de IBS) e, a partir de 2027, torna-se opcional entre empresas. Ele altera o fluxo de caixa e a conciliação de cada transação — o que o ERP e qualquer agente que age sobre ele precisam refletir para não propor números que não fecham.
Como integrar SAP com sistema não-SAP no Brasil?
Conectando o SAP (S/4HANA, Commerce Cloud, Protheus) aos sistemas não-SAP (e-commerce, fornecedor, gateway, fiscal) via os protocolos nativos (OData, iDoc, RFC) sobre uma arquitetura event-driven, com idempotência, contratos de API explícitos e reconciliação do dado — incluindo o fiscal de entrada (IBS/CBS) e o split payment. É essa integração reconciliada que permite a um agente agir em tempo real sem multiplicar rejeições.
O Joule com Claude vai tomar decisões cada vez melhores — e isso é ótimo. Mas a pergunta que decide o resultado, no Brasil, não é “o modelo é bom?”, e sim “minha integração SAP↔não-SAP e meu fiscal de entrada estão reconciliados para o agente agir certo?”. Reconciliar a fundação com a CCX →