Na semana em que o agente de IA virou item de prateleira, a SAP entregou a versão dela do “agente que faz”: a 2ª onda de assistentes Joule de compras atingiu disponibilidade geral (GA) em setembro de 2026. São seis novos — Category Management, Supplier Management, Requisition, Buying, Receiving e Services Procurement Assistants — que se somam aos cinco que entraram em junho, totalizando onze assistentes, dentro do guarda-chuva do “Autonomous Spend Management” (automação de source-to-pay em Ariba e Fieldglass). E há um sinal de fase: o teste grátis do Joule para desenvolvedores termina em setembro — a etapa de brincar acabou; a de operar (e pagar) começou.
O movimento é forte. Um agente que requisita, compra e recebe sozinho promete cortar ciclo e erro no procurement. Mas há um recorte que o keynote não cobre — e que decide se isso vira ganho ou risco no Brasil: um agente que compra e recebe autonomamente esbarra exatamente no que o Joule não padroniza por você. O fiscal do fornecedor, a integração com o mundo dele e o dado reconciliado que o agente lê para decidir. A tese deste artigo é direta: a SAP automatiza o ato de comprar; ela não automatiza o fiscal do seu fornecedor, a integração com o mundo dele nem a reconciliação do seu dado — e, no Brasil, é isso que separa a automação da compra do risco tributário automatizado.
O que a SAP entregou: a 2ª onda de assistentes Joule de compras em GA
Os assistentes Joule de compras vêm sendo entregues em ondas desde o Sapphire (maio de 2026). O marco datado de agora é a segunda onda chegando a GA em setembro: Category Management (estratégia de categoria), Supplier Management (gestão de fornecedores), Requisition (requisição), Buying (compra), Receiving (recebimento) e Services Procurement (compra de serviços). Juntos com os cinco de junho, formam um time de onze assistentes que cobre boa parte do ciclo de source-to-pay. Não é um anúncio isolado de produto — é a consolidação de uma capacidade que a SAP vinha liberando aos poucos, agora entrando no regime de produção.
Autonomous Spend Management: o agente requisita, compra e recebe
O nome do guarda-chuva já entrega a ambição: gestão autônoma de gasto. A ideia é que o ciclo do procurement — da requisição à ordem de compra, passando pela seleção de fornecedor e chegando ao recebimento — possa rodar com intervenção humana mínima, orquestrado por agentes sobre Ariba e Fieldglass. Para operações grandes, com milhares de pedidos, o apelo é óbvio: menos trabalho manual, menos erro de digitação, ciclos mais curtos. O problema não está na promessa. Está no que acontece quando esse agente autônomo encontra a realidade fiscal e de integração de uma empresa brasileira.
O que a SAP automatiza — o ato de comprar — e o que ela não automatiza
Vale ser preciso, porque a distinção é toda a tese. O que os assistentes automatizam é o ato: gerar a requisição, escolher o fornecedor conforme a política, emitir a ordem, registrar o recebimento. O que eles não automatizam — e não deveriam mesmo, porque é específico do seu país e do seu ambiente — é a camada que decide se aquela compra fecha certo: o documento fiscal de entrada, a integração com o sistema do fornecedor e o dado reconciliado que sustenta a decisão. A plataforma automatiza o gesto de comprar; a correção da compra depende de três coisas que continuam sendo suas.
Um exemplo torna a diferença palpável. O Buying Assistant recebe uma requisição, consulta a política de categoria, escolhe um fornecedor homologado e emite a ordem de compra — tudo em segundos, sem intervenção. Impecável, do ponto de vista do ato. Mas quando a mercadoria chega e o Receiving Assistant dá o recebimento, entra em cena o que o agente não faz: a nota fiscal de entrada precisa ser validada contra o pedido, o crédito tributário precisa ser apurado, a obrigação acessória precisa ser gerada. Se essa conciliação não acontecer — ou acontecer “depois, no fechamento” —, a empresa acumula uma pilha de entradas não conciliadas na exata velocidade em que o agente compra. O ato ficou rápido; a correção ficou para trás.
O fiscal de entrada no Brasil: NF-e/NFS-e, IBS/CBS com crédito, SPED
Aqui está o fator Brasil. Uma compra não termina quando o pedido é emitido — ela termina quando o documento fiscal de entrada é conciliado. E a entrada, no Brasil, é densa: NF-e e NFS-e do fornecedor, apuração de crédito de IBS/CBS no regime dual (obrigatório em produção desde janeiro de 2026), obrigações de SPED e a camada de localização. Um Buying ou Receiving Assistant que fecha um pedido e dá o recebimento sem conciliar o documento fiscal de entrada não está automatizando o procurement — está gerando risco tributário em escala. Porque o crédito não apurado, a nota que não bate e a obrigação acessória não cumprida não somem quando o agente age rápido; eles se multiplicam na velocidade do agente.
A integração SAP↔fornecedor: onboarding, EDI, portais, ERP do fornecedor
A segunda camada que continua sua é a integração com o fornecedor. Um agente só compra “de verdade” se existir a costura que o conecta ao mundo do outro lado: onboarding de fornecedor, EDI, portais, catálogos externos e o próprio ERP do fornecedor. Sem isso, o agente até emite uma ordem, mas ela não vira uma transação sincronizada entre os dois lados — não há confirmação, não há status, não há rastro. A costura SAP↔fornecedor é feita com contrato: OData, iDoc, RFC e arquitetura event-driven para garantir entrega. É trabalho de integração enterprise clássico, e é exatamente o que o assistente pressupõe pronto.
O dado reconciliado que o agente lê para decidir
A terceira camada é o dado. O agente lê cadastro de fornecedor, preço, contrato e saldo para decidir o que comprar e de quem. Se esse dado está espalhado — o cadastro num sistema, o preço num contrato em PDF, o saldo num terceiro lugar — o agente compra com convicção sobre uma base errada. E, diferentemente de um comprador humano que desconfia de um número estranho, o agente executa. Reconciliar o dado antes é o que garante que a autonomia se aplique sobre uma verdade, e não sobre um retrato desatualizado da sua operação.
Compra autônoma sem conciliação fiscal = risco tributário em escala
Junte as três camadas e o retrato fica claro. Autonomia sobre gasto real, sem fiscal de entrada conciliado, sem integração de fornecedor e sem dado reconciliado, não é eficiência — é a industrialização de um erro. Cada compra que o agente fecha “por fora” dessas camadas é uma nota que alguém terá de acertar depois, um crédito que talvez se perca, uma obrigação que pode falhar. O paradoxo é cruel: quanto mais rápido e autônomo o agente, maior a escala do problema se a fundação não estiver pronta. A mesma lição já apareceu neste blog quando falamos que o cérebro do ERP virou um modelo alugado e o fiscal continua seu e que o agente que executa sobre dado ruim automatiza o erro em escala.
Clean core: o que fica no Joule e o que precisa ser seu por design
A resposta arquitetural tem nome: clean core. A disciplina de manter o núcleo do SAP limpo e padrão, empurrando customização e lógica específica para camadas de extensão, é o que permite que você use os assistentes do Joule sem renunciar ao controle do que é seu por design — o fiscal brasileiro, a integração com fornecedores, o dado reconciliado. Definir a arquitetura-alvo — o que fica na plataforma e o que precisa viver na sua camada, com contrato — é uma decisão de projeto, não de configuração. É ela que decide se a autonomia do agente vai render ou vai cobrar caro.
Há ainda um sinal econômico que não pode passar batido: o teste grátis do Joule para desenvolvedores termina em setembro. Isso muda a conversa de “experimentar” para “operar com custo”. Quando o uso começa a ter fatura, a pergunta deixa de ser “o agente consegue comprar?” e passa a ser “cada compra que ele fecha está fechando certo, ou está gerando retrabalho e risco que custam mais do que o agente economiza?”. A resposta depende, de novo, da fundação: um agente autônomo rodando sobre integração e fiscal maduros é economia; o mesmo agente sobre uma base frágil é um multiplicador de custo escondido. A hora de arrumar a fundação é antes de ligar a autonomia — não depois da primeira fatura.
Como a CCX integra o fornecedor e reconcilia dado e fiscal por trás do agente
A SAP colocou onze assistentes de compras em produção — o agente requisita, compra e recebe. No Brasil, o que decide se a compra fecha certo não é o agente: é o fiscal do fornecedor, a integração SAP↔fornecedor e o dado reconciliado. É essa camada que a CCX entrega. Em Integrações & APIs Enterprise, costuramos a ponte SAP↔fornecedor/não-SAP com OData, iDoc e RFC sobre arquitetura event-driven — onboarding de fornecedor, EDI e portais — para o agente comprar “de verdade”, com confirmação e rastro. Em Data & BI, reconciliamos o dado (cadastro, preço, contrato, saldo) e tratamos o fiscal de entrada — NF-e/NFS-e, apuração de crédito de IBS/CBS no regime dual, SPED — para que o Buying/Receiving Assistant não gere risco tributário ao fechar um pedido.
E porque a decisão começa no desenho: em Consultoria em Tecnologia definimos o clean core e a arquitetura-alvo — o que fica no Joule e o que precisa ser seu por design. Quanto mais o agente ganha autonomia sobre gasto real, mais o diferencial se concentra nessa camada durável. Comece com um diagnóstico de integração e fiscal do seu SAP com a CCX: o agente compra; você é quem faz a compra fechar.
Perguntas frequentes (People Also Ask)
O que é o Autonomous Spend Management da SAP? É a automação autônoma de source-to-pay em Ariba e Fieldglass, orquestrada por assistentes Joule de compras (requisição, compra, recebimento, gestão de fornecedor e de categoria). A 2ª onda atingiu GA em setembro de 2026.
Um assistente Joule de compras concilia a nota fiscal de entrada? Não. Os assistentes automatizam o ato de comprar e receber. O fiscal de entrada brasileiro — NF-e/NFS-e, crédito de IBS/CBS no regime dual, SPED — continua sendo sua responsabilidade, e precisa ser conciliado para a compra fechar certo.
Por que a integração SAP↔fornecedor importa para a compra autônoma? Porque o agente só compra “de verdade” quando existe a costura com o fornecedor (onboarding, EDI, portais, ERP do fornecedor) via OData/iDoc/RFC e event-driven. Sem ela, a ordem não vira transação sincronizada.
Compra autônoma no Brasil sem fiscal conciliado é seguro? Não. Fechar pedidos e recebimentos sem conciliar o documento fiscal de entrada industrializa erro tributário na velocidade do agente. A fundação — integração, dado reconciliado e fiscal — precisa vir antes da autonomia.