A SAP levou o Autonomous Spend à produção: seis assistentes Joule de compras entram em disponibilidade geral (GA) em setembro — Buying, Receiving, Requisition, Supplier e Category Management, Services Procurement — somando onze assistentes no ano. E foi além do próprio ecossistema: o Joule agora conversa com o Microsoft 365 Copilot via A2A, o protocolo agent-to-agent que permite handoff entre agentes de fornecedores diferentes. Na prática, o agente compra e recebe sozinho — e ainda passa o bastão para um agente da Microsoft.
É um avanço concreto de automação de compras. Mas, no Brasil, ele encontra um contexto que a autonomia do agente não resolve por conta própria. O Split Payment começou a reter o imposto na hora da transação, e o preenchimento de IBS/CBS na NF-e é obrigatório desde 03/08/2026 (com NFS-e entrando entre outubro e dezembro). A compra autônoma só fecha certo quando o dado do fornecedor, o crédito de entrada (IBS/CBS), a NF-e/NFS-e e a integração SAP↔não-SAP estão reconciliados — e o split payment ainda mexe no capital de giro. Essa camada continua sua.
O que a SAP entregou: Autonomous Spend, 6 assistentes Joule em GA e A2A com o Copilot
O Autonomous Spend é a aposta da SAP em tirar a compra corporativa do modo "assistente que sugere" e colocá-la no modo "agente que executa". Os seis assistentes Joule que entram em GA em setembro cobrem o ciclo de procurement de ponta a ponta: o Buying conduz a compra, o Receiving confirma o recebimento, o Requisition trata a requisição, o Supplier e o Category Management cuidam de fornecedores e categorias, e o Services Procurement cobre a compra de serviços. Onze assistentes no acumulado do ano indicam que não é um piloto isolado — é uma frente de produto.
A peça que muda o jogo de integração é o A2A. Ao fazer o Joule conversar com o Microsoft 365 Copilot, a SAP admite o óbvio: nenhuma operação vive dentro de um único fornecedor. O agente de compras da SAP precisa, em algum momento, delegar ou receber tarefas de agentes que vivem noutro ecossistema. O A2A padroniza esse handoff. O que ele não padroniza — e aqui está o ponto do artigo — é quem valida o quê quando a tarefa cruza a fronteira do Brasil, com suas regras fiscais próprias.
O agente compra e recebe sozinho — e passa o bastão para o agente da Microsoft
Vale desenhar o fluxo para ver onde mora o risco. Um assistente Joule identifica a necessidade, seleciona o fornecedor, emite a ordem de compra e, na chegada, o Receiving confirma o recebimento — tudo sem intervenção humana em cada passo. Se a operação exige uma etapa que vive no ambiente Microsoft (uma aprovação, um documento, uma checagem), via A2A o Joule passa o bastão ao Copilot e retoma quando a resposta volta. É eficiente e, no papel, elegante.
O problema não está na autonomia em si; está no que ela pressupõe. O agente executa o ato — compra, recebe, delega — assumindo que os dados sobre os quais age estão corretos e que as obrigações que decorrem do ato serão cumpridas. Num mercado sem particularidades fiscais fortes, essa suposição passa despercebida. No Brasil de 2026, ela é justamente o que separa uma compra autônoma bem-sucedida de um passivo fiscal automatizado.
No Brasil: o Split Payment retém o imposto na transação e o IBS/CBS na NF-e é obrigatório desde 03/08
Duas mudanças da reforma tributária tornam a compra autônoma um problema de dado e integração, não só de automação. A primeira: o preenchimento de IBS/CBS na NF-e passou a ser obrigatório desde 03/08/2026, com a NFS-e entrando na sequência (outubro a dezembro). A segunda, mais disruptiva para o fluxo financeiro: o Split Payment retém o imposto no momento da transação — em vez de o comprador recolher depois, parte do pagamento é separada e destinada ao fisco na hora, com alíquota-teste inicial de 1% (0,9% de CBS + 0,1% de IBS).
Para um agente que compra sozinho, isso muda tudo silenciosamente. O valor que efetivamente sai do caixa na transação não é mais só o preço combinado com o fornecedor — é o preço menos a parcela retida, ou o preço acrescido da mecânica de crédito, dependendo do desenho. Se o agente não "enxerga" o split payment, ele planeja o caixa com um número e a realidade entrega outro. E como o imposto é retido na transação, o capital de giro sente o efeito imediatamente, não no fechamento do mês. Autonomia sem reconciliação fiscal não é eficiência — é surpresa no caixa, em escala.
Multiplique isso pelo volume de uma operação de compras real. Um agente que executa centenas de ordens por dia, cada uma com uma fração retida na fonte e um crédito de entrada a apropriar, produz um descasamento entre o caixa planejado e o caixa realizado que cresce em silêncio. Individualmente, cada transação parece correta; no agregado, o planejamento financeiro trabalha com uma projeção que a soma das retenções já desmentiu. É por isso que a resposta não é frear o agente — é dar a ele, e ao ERP, uma visão do fiscal de entrada e do split payment tão em tempo real quanto a decisão de compra. A autonomia da ponta precisa de reconciliação na mesma cadência; caso contrário, quanto mais rápido o agente compra, mais rápido o caixa se desalinha.
O que a autonomia não faz: conferir NF-e/NFS-e de entrada, crédito de IBS/CBS e dado do fornecedor
É importante separar o que o agente resolve do que continua sendo responsabilidade da operação. O Joule resolve o ato: decide, compra, recebe, delega. O que ele não resolve, sozinho, é a reconciliação de entrada: conferir se a NF-e/NFS-e do fornecedor está correta e válida, se o crédito de IBS/CBS foi apropriado corretamente, se o dado cadastral do fornecedor bate com o que o ERP espera, e se o registro fiscal (SPED) reflete a operação. Essas verificações dependem de o SAP conversar com sistemas que muitas vezes são não-SAP — o portal do fornecedor, o sistema fiscal, o middleware de nota.
Quando essa reconciliação não existe, o agente automatiza a compra e deixa um rastro de pendências: crédito de entrada não aproveitado (imposto pago a mais), nota divergente que trava a escrituração, fornecedor com cadastro incompleto que gera retrabalho manual. A autonomia, nesse cenário, não elimina o trabalho — ela o empurra para depois, transformado em conciliação e correção. O ganho de velocidade na ponta da compra vira perda de tempo na ponta fiscal.
Integração SAP↔não-SAP, dado reconciliado e capital de giro: a camada que continua sua
A conclusão prática é que a compra autônoma no Brasil só fecha certo com uma camada de integração e reconciliação que o agente não traz embutida. São quatro elementos. Primeiro, a integração SAP↔não-SAP/fornecedor: o Joule precisa trocar dados em tempo real com o portal do fornecedor, o sistema fiscal e o middleware de nota — via OData, iDocs, RFC ou APIs modernas. Segundo, o dado reconciliado: fornecedor, pedido, nota e crédito de entrada precisam bater entre si e com o ERP, com fonte de verdade definida.
Terceiro, o fiscal de entrada propriamente dito: IBS/CBS na NF-e/NFS-e, aproveitamento de crédito, aderência ao SPED — tudo isso precisa ser validado antes de o agente considerar a compra "fechada". Quarto, a visibilidade do capital de giro: como o split payment retém na transação, o fluxo de caixa precisa refletir a retenção em tempo real, para o planejamento financeiro não trabalhar com um número que a operação já desmentiu. Esses quatro elementos não vêm no agente — eles vêm da engenharia de integração que você mantém em volta dele.
Como a CCX integra e reconcilia para o agente de compras fechar certo
Na CCX, essa é exatamente a camada que entregamos. Pela frente de Integrações & APIs Enterprise com foco em Integração SAP, costuramos o SAP↔não-SAP/fornecedor em tempo real — expertise em OData, iDocs e RFC, arquitetura event-driven (Kafka/RabbitMQ), idempotência e sincronização de estoque, preço, pedido e nota entre o ERP e os sistemas de venda e de fornecedores. É o mesmo padrão de engenharia dos produtos próprios da CCX, que operam entrega garantida por transação e reconciliação contínua.
Pela frente de Data & BI, reconciliamos o dado do fornecedor, o crédito de entrada (IBS/CBS), a NF-e/NFS-e e o efeito do split payment no capital de giro — com fonte de verdade e visibilidade em tempo real do caixa. E pela frente de Consultoria em Tecnologia, ajudamos a definir o clean core: o que precisa ser seu por design e o que pode ficar no padrão do agente, para a autonomia não virar dependência cega. Tudo com squad dedicada (onboarding em 48h, engenheiros com 10+ anos) e compliance LGPD/SOC 2. O resultado: o Joule compra e recebe sozinho, mas cada compra chega ao fechamento com nota válida, crédito apropriado e caixa previsto — porque a integração e o fiscal de entrada estavam reconciliados.
Quer que a compra autônoma do agente feche certo — e o caixa não seja surpreendido? Conheça a Integração SAP ↔ E-commerce da CCX — SAP↔não-SAP em tempo real, dado e fiscal de entrada reconciliados. A reconciliação de dado e do split payment vive em Data & BI; o clean core e o que precisa ser seu por design, em Consultoria em Tecnologia; a frente SAP completa, em SAP.
Perguntas frequentes (FAQ)
O que é o SAP Autonomous Spend?
É a frente da SAP que coloca a compra corporativa em modo autônomo por meio de assistentes Joule. Seis assistentes de compras (Buying, Receiving, Requisition, Supplier/Category Management, Services Procurement) entram em disponibilidade geral em setembro, cobrindo o ciclo de procurement. O agente compra, recebe e, via A2A, pode delegar tarefas a agentes de outros fornecedores, como o Microsoft 365 Copilot.
Os assistentes Joule de compras respeitam o fiscal brasileiro?
Os assistentes executam o ato de comprar e receber, mas a conformidade fiscal brasileira — IBS/CBS na NF-e/NFS-e, aproveitamento de crédito de entrada, split payment e SPED — depende da reconciliação entre o SAP e sistemas frequentemente não-SAP (portal do fornecedor, sistema fiscal, middleware de nota). Sem essa camada de integração, a compra autônoma pode gerar crédito não aproveitado, nota divergente e surpresa no caixa.
O que é split payment na reforma tributária?
É o mecanismo que retém o imposto (IBS/CBS) no momento da transação, em vez de o comprador recolher depois. Uma parcela do pagamento é separada e destinada ao fisco na hora — com alíquota-teste inicial de 1% (0,9% CBS + 0,1% IBS). O efeito prático é imediato sobre o capital de giro e sobre a conciliação, exigindo que o ERP e os agentes de compra enxerguem a retenção em tempo real.
Como integrar SAP com sistema não-SAP?
A integração SAP↔não-SAP se apoia em interfaces como OData, iDocs e RFC, ou APIs modernas, orquestradas por uma arquitetura event-driven com idempotência e reconciliação. O objetivo é que fornecedor, pedido, nota e crédito de entrada batam entre si e com o ERP, com fonte de verdade única — para que a compra autônoma feche com dado válido e fiscal de entrada correto.
A plataforma executa e interopera o ato. O dado reconciliado, a integração e o fiscal de entrada continuam seus. Integrar SAP↔não-SAP e reconciliar o fiscal de entrada →