Enquanto a Dreamforce fazia a IA “substituir a UI”, a SAP fez o movimento espelhado: reposicionou o Joule de assistente de chat para “porta de entrada primária pela qual usuários e sistemas interagem com toda a stack SAP”, com a Autonomous Suite embarcando mais de 50 agentes Joule de domínio — e os 6 assistentes de compras do Ariba entrando em disponibilidade geral (GA) em setembro de 2026. Dos dois lados do mercado, a mesma tese: a IA virou a porta de entrada do ERP.
Uma nota de precisão antes de seguir: o reposicionamento do Joule como “gateway” da suíte e a visão de Autonomous Enterprise foram apresentados pela SAP no Sapphire (maio/2026) e reforçados nas releases de Business AI ao longo do ano; o gancho de hoje é o espelhamento — a SAP faz o Joule virar porta de entrada assim como a Salesforce fez o AIforce, na semana da Dreamforce. E aqui entra o que muda tudo para quem opera no Brasil: essa porta abre para um chão fiscal que é alvo em movimento — e que muda ESTE MÊS.
O que a SAP fez: o Joule como “porta de entrada” da suíte — o espelho do AIforce
O Joule nasceu como copiloto conversacional da SAP: você perguntava, ele respondia sobre os dados da suíte. O reposicionamento muda a ambição. Em vez de um overlay de chat, o Joule passa a ser descrito como a porta de entrada primária — o ponto por onde usuários e até outros sistemas interagem com toda a stack SAP. A Autonomous Suite reforça a direção ao embarcar mais de 50 agentes de domínio (compras, finanças, supply, RH), e os 6 assistentes de compras do Ariba em GA em setembro dão um exemplo concreto de agentes de domínio saindo do laboratório para produção.
É exatamente o mesmo movimento que a Salesforce anunciou com o AIforce na Dreamforce: a interface deixa de ser a tela do aplicativo e passa a ser a IA. Quando dois dos maiores fornecedores de ERP e CRM do mundo fazem a mesma jogada na mesma janela, o recado é de indústria: a IA como porta de entrada do sistema virou padrão. E, como todo padrão de superfície, ele melhora o acesso — dá a mais gente um caminho mais rápido para dentro do ERP. O que ele não muda, sozinho, é a qualidade do que está por trás da porta.
A porta de IA abre para uma transação fiscal — e, no Brasil, o chão muda este mês
Toda compra, todo lançamento, todo pedido que um agente do Joule executa termina virando uma transação fiscal — uma NF-e, um crédito, uma apuração. E no Brasil essa transação pisa num chão que está se movendo agora, com três marcos concretos neste mês.
O primeiro é uma decisão que vence em 30/09: a janela para optar pelo regime regular de IBS/CBS do 1º semestre de 2027 está aberta de 01 a 30 de setembro de 2026 (com efeitos a partir de janeiro de 2027). É uma escolha que a empresa toma este mês e que muda como ela vai apurar tributo no ano que vem. O segundo é o split payment avançando na parte técnica: a Nota Técnica 2026.006 define os campos de split na NF-e/NFC-e, e o Ato Técnico Conjunto RFB/CGIBS nº 4, de 08/09, aprovou os manuais da Plataforma Pública — tudo isso mesmo com a obrigatoriedade estimada apenas para 2028. O terceiro é operacional e imediato: as tabelas de NCM/CFOP da NF-e foram atualizadas em 10/09. Ou seja: a porta de entrada de IA da SAP abre para um piso que mudou de campos, de tabelas e de opção de regime dentro do mesmo mês.
Alvo em movimento: a obrigatoriedade é 2028, mas a técnica já avança
Há uma armadilha de leitura aqui que custa caro. Como a obrigatoriedade do split payment está estimada para 2028, é tentador tratar o tema como “problema do futuro”. Mas a parte técnica já está em movimento: os campos de split já estão especificados (NT 2026.006), os manuais da Plataforma Pública já foram aprovados (Ato Técnico nº 4, de 08/09) e o NCM/CFOP já mudou (10/09). Quem espera 2028 para reconciliar master data e fiscal de entrada vai fazer isso no susto, sobre um alvo que já andou.
É por isso que “alvo em movimento” não é retórica: o ERP e as integrações precisam acompanhar a mudança à medida que ela acontece, não depois. A decisão de opção pelo regime regular de 2027 é a prova viva disso — é uma escolha de setembro de 2026 com efeito em janeiro de 2027, que exige que o dado fiscal de entrada e a apuração estejam prontos para o cenário escolhido. Colocar uma IA como porta de entrada sem essa fundação apenas antecipa o momento em que o erro aparece.
Por que uma “porta de entrada” de IA sobre dado não reconciliado escala o erro
Aqui está o ponto que decide o resultado. Uma porta de entrada de IA melhora o acesso, mas não conserta o dado que está do outro lado dela. Se o master data de fornecedor está inconsistente e o fiscal de entrada não acompanha o NCM/CFOP e os campos de split, dar a um agente Joule acesso mais rápido a esse dado apenas faz o erro acontecer mais rápido e em mais lugares.
Os sintomas são conhecidos de quem opera fiscal no Brasil: rejeição de NF-e (a nota volta porque o NCM, o CFOP ou um campo obrigatório está errado), crédito indevido ou perdido (a apuração de IBS/CBS parte de um dado de entrada que não bate), e conciliação impossível (o que o agente lançou não fecha com o que o fisco espera). Um agente autônomo sobre essa base não elimina o trabalho manual — ele o multiplica na velocidade da máquina, gerando mais notas rejeitadas e mais divergências para alguém resolver depois. A IA vira a porta; a integração SAP↔não-SAP e o fiscal de entrada acompanhando o alvo em movimento decidem o que, de fato, entra por ela.
Um exemplo torna a distância concreta. Imagine um dos assistentes de compras do Ariba criando um pedido a partir de um cadastro de fornecedor com o NCM desatualizado — justamente aquele que mudou em 10/09. O agente faz o lançamento em segundos, com a confiança de sempre; a NF-e correspondente é rejeitada horas depois, o crédito de IBS/CBS entra errado na apuração e a conciliação do fim do mês não fecha. Nada disso é culpa do Joule: ele apenas executou, mais rápido, sobre um dado que ninguém reconciliou. A porta de IA apenas encurtou o caminho até o erro — e é a fundação (master data e fiscal de entrada atualizados), não a interface, que teria evitado a rejeição. Quanto mais autônoma a porta, mais cara fica a ausência dessa base.
Como a CCX reconcilia a fundação antes de abrir a porta de IA
Na CCX, reconciliar a fundação que uma porta de entrada de IA pressupõe é um projeto de engenharia com três frentes — e ele vem antes de a IA virar o gateway.
Primeiro, a integração SAP↔não-SAP. Pela frente de Integrações & APIs Enterprise, com expertise específica em SAP (OData, iDoc, RFC), conectamos a suíte SAP aos sistemas de fornecedor, ao e-commerce, ao Protheus e ao dado que não é SAP, com arquitetura event-driven (Kafka/RabbitMQ), idempotência e contratos explícitos — para que o agente aja sobre master data de fornecedor reconciliado ponta a ponta, e não sobre silos. Segundo, o fiscal de entrada e o dado reconciliado. Pela frente de Data & Business Intelligence, montamos a reconciliação e os pipelines que mantêm o fiscal de entrada acompanhando o NCM/CFOP atualizado (10/09), o IBS/CBS e os campos de split da NT 2026.006, além da habilitação para a Plataforma Pública do split payment — o dado certo que o Joule precisa ler para agir certo.
Terceiro, o diagnóstico e o clean core. Pela Consultoria em Tecnologia, fazemos a due diligence do que precisa estar certo por design antes de abrir a porta de IA — incluindo a própria decisão de opção pelo regime regular de 2027, que vence em 30/09 — com arquitetura-alvo, clean core e compliance LGPD/SOC 2. Quer reconciliar a fundação antes de abrir a porta de IA? Fale com a CCX sobre integração SAP ↔ e-commerce. O fiscal de entrada e o dado reconciliado vivem em Data & BI; a fundação e o clean core, em Consultoria em Tecnologia; a frente SAP completa, em ccxcompany.co/br/sap.
Perguntas frequentes (FAQ)
O que é o Joule da SAP?
O Joule é a IA da SAP, originalmente um copiloto conversacional sobre os dados da suíte. Em 2026, foi reposicionado de “chatbot” para “porta de entrada primária pela qual usuários e sistemas interagem com toda a stack SAP”, acompanhando a Autonomous Suite (mais de 50 agentes de domínio). É o movimento espelhado do AIforce da Salesforce: a IA vira a interface do ERP.
O que é a opção pelo regime regular de IBS/CBS?
É a escolha, por parte da empresa, de apurar IBS e CBS pelo regime regular em determinado período da transição da reforma tributária, em vez do regime padrão. Para o 1º semestre de 2027, a janela de opção está aberta de 01 a 30 de setembro de 2026, com efeitos a partir de janeiro de 2027 — uma decisão que se toma este mês e que exige o dado fiscal de entrada pronto para o cenário escolhido.
Até quando optar pelo regime de 2027?
A janela para optar pelo regime regular de IBS/CBS do 1º semestre de 2027 está aberta de 01 a 30 de setembro de 2026. A decisão vence em 30/09 e passa a valer a partir de janeiro de 2027.
O que é a NT 2026.006 do split payment?
A Nota Técnica 2026.006 define os campos de split payment na NF-e/NFC-e — parte da implementação técnica do recolhimento na transação prevista pela reforma. Ela avança mesmo com a obrigatoriedade do split estimada apenas para 2028; somada ao Ato Técnico Conjunto RFB/CGIBS nº 4 (08/09), que aprovou os manuais da Plataforma Pública, mostra que a técnica já está em movimento.
Como integrar SAP com sistema não-SAP no Brasil?
Conectando a suíte SAP (via OData, iDoc e RFC) aos sistemas de fornecedor, e-commerce e ao dado não-SAP, com arquitetura event-driven, idempotência e contratos de API explícitos, e mantendo o fiscal de entrada (NCM/CFOP, IBS/CBS, campos de split) reconciliado. É essa base — e não a porta de IA — que determina se o agente age sobre dado certo ou multiplica rejeição de NF-e.
A IA como porta de entrada do ERP é uma boa notícia de acesso — e virou padrão dos dois lados do mercado. Mas, no Brasil, a pergunta que decide não é “a porta é inteligente?”, e sim “o master data e o fiscal de entrada acompanham o alvo em movimento — e a opção do regime de 2027 está decidida antes de 30/09?”. A IA vira a porta; a integração e o fiscal reconciliado decidem o que entra. Reconciliar a fundação com a CCX →