Last month I wrote about the agent that posts to your ledger. Two weeks ago I wrote about the one that reads your bank statement and proposes your transfers. So this month I went looking for the third one, the agent I actually want, the one that answers the question I get asked in every single steering committee I have ever sat in.
Which product line is eroding my margin, and why?
It does not exist. And after digging through what SAP announced at Sapphire and what it published this month, I do not think it is late. I think it is structurally difficult in a way the close and the bank statement are not, and I think that tells you something useful about where to spend your own money.
What SAP actually put on the table
Let’s start with the numbers, because they are impressive and I want to be fair about that. At Sapphire in May, SAP announced more than 50 domain-specific Joule Assistants, each orchestrating what it calls a subset of over 200 specialised agents, across finance, supply chain, procurement, HCM and CX. Announced, note. Almost none of it is in a customer system yet.
Seven of those assistants are for Finance. Here are their promised windows, straight from SAP’s own innovation news guide:
- Financial Closing Assistant, Billing Assistant, Tax and Compliance Assistant, Accounts Receivable Assistant: general availability planned for Q2 2026
- Cash and Treasury Assistant: Early Adopter Care in Q2 2026 (and no GA date stated anywhere in that document, which I flagged in my treasury post two weeks ago and still find odd)
- Financial Planning Assistant: GA planned for Q3 2026
- Governance Assistant: GA planned for Q4 2026
Now go looking for profitability in that list. Close, billing, tax, receivables, cash, planning, governance. No margin. No profitability analysis. Nothing that decomposes a P&L.
I did the boring thing and searched SAP’s Sapphire 2026 innovation news guide for the word. “Margin” appears three times in the whole document. Once as a section heading. Once in a sentence about revenue management, where new AI features “help improve margin insights by highlighting anomalies and settlement risks” in rebate and claims processing, with GA planned for Q3 2026 and no margin agent named. And once in procurement, about using requisition aggregation to improve margins on volume discounts.
Then I checked the Q1 2026 Business AI release highlights, the actual shipped-things document. “Margin”, “CO-PA”, “COGS”, “profitability analysis”: zero hits. Not one.
So the biggest agent announcement SAP has ever made contains nothing that answers the first question a CFO asks. Not delayed. Absent.
Why this is the question that matters
I want to be blunt about the ranking here, because I think we get it backwards in SAP projects all the time.
Close speed is an internal metric. It matters, it is expensive, and shaving four days off a close is a genuinely good outcome for the people doing the work. But no board has ever changed strategy because the close got faster.
Margin is different. Gross margin by product line, by market, by customer segment, is the number the business is actually run on. When it moves two points in the wrong direction, somebody has to stand up and say whether it was price, mix, input cost, freight, rebates, or the factory. That is the conversation the CFO owns. And in most of the systems I walk into, the honest answer to “why did it move” is a three-week exercise with four analysts and a spreadsheet.
So of all the places to point a language model, this is the one with the highest value per question answered. SAP knows that. It is not an oversight.
Why SAP cannot just ship it
Here is my read, and this is the part I actually want to argue.
SAP can ship a Financial Closing Assistant because a close is a close. The steps are broadly the same in Utrecht and in São Paulo. Accruals, reconciliations, intercompany, currency translation, error resolution. The process is universal enough that a vendor can encode it once and sell it to everybody.
Margin decomposition is not universal. It is the single most customer-specific thing in the whole Finance stack, and it is customer-specific in a way that lives in your own configuration decisions, not in your data volume.
Think about what “which cost element eroded margin” actually requires at row level in the Universal Journal. It requires that the cost was posted in a form that names itself. And that is a design decision you made, or did not make, years ago.
Take the COGS split. I wrote about this back in 2019, after the enhancements landed in 1809, and it has never been more relevant than it is now. Without it, a goods issue for a delivery posts two lines and tells you nothing:
- 50300000 Cost of goods sold, debit 12.360,00
- 13900000 Inventory finished goods, credit 12.360,00
Twelve thousand three hundred sixty euros of cost, and one word of explanation: “cost”. Now point the smartest model in the world at that row and ask it why margin fell. It cannot tell you. Not because it is not clever enough, but because you never wrote down the answer. There is nothing in that posting to decompose.
With the COGS split switched on and the cost component structure mapped to separate accounts, the same goods issue posts something an analyst, or a model, can actually work with:
- 50300000 COGS material input, debit 8.420,00
- 50310000 COGS production labour, debit 2.150,00
- 50320000 COGS overhead applied, debit 1.180,00
- 50390000 COGS production variance, debit 610,00
- 13900000 Inventory finished goods, credit 12.360,00
Same total, completely different question answerable. This is the bit I like, and it is worth saying plainly: “margin fell because input cost rose 9% while price held” is now a query, not a project. Add the production variance split from Material Ledger actual costing on top, which I also wrote about back in 2020, and you can go one level further and separate a price variance from a usage variance, which is the difference between blaming procurement and blaming the plant.
[SCREENSHOT: Margin Analysis line items in the Universal Journal showing the split COGS accounts against a single sales document, with the profitability characteristics on the right]
And that is only the cost side. On the revenue side you have the same problem with conditions. If your discounts, rebates and freight recoveries are not mapped through to margin analysis as separate values, your “revenue” is one lump too, and the model will confidently tell you revenue was flat while three offsetting things moved underneath it. I wrote a whole post on statistical sales conditions in account-based CO-PA in 2019 for exactly this reason.
Then there is derivation. Every characteristic that is not derived at posting time is a dimension you cannot slice by afterwards. We have all seen the “Not assigned” bucket in a margin report and quietly agreed not to talk about it.
None of this is an AI problem. All of it is a Finance design problem, and it is one that has to be solved before the AI arrives, not after.
What SAP’s own reference customer actually did
Which brings me to the story SAP published on 8 July, and the reason I am writing this now.
The customer story SAP put on its news centre for generative AI in S/4HANA Finance is Natura &Co, the Brazilian group behind Natura and Avon, and it is exactly a gross margin analysis application. Their tech manager for ERP Latam describes integrating margin analysis from S/4HANA with a large language model connected through SAP AI Core, giving what he calls “a stratified and precise view of gross margin offenders and protectors, discriminating exactly which revenue or cost elements were driving market performance.”
Offenders and protectors. That is a good phrase and I am going to steal it.
And I have to say, from the description alone the architecture is the shape I would have drawn. The margin data stays in S/4HANA, the model sits outside it through AI Core, the data goes out anonymised, and the finance team keeps the interpretation. No dragging a copy of ACDOCA into a data lake so a chatbot can guess at it. I have been waiting years for someone to show me this pattern working on real numbers instead of a demo dataset, and now it is here! I want to build a small version of it in my own sandbox against a margin analysis dataset with a proper cost component structure behind it, and I probably will over the summer.
But look at what it took, because this is the part that gets skipped. It was not switched on. It was a co-innovation project, built by Natura together with SAP itself and partner Numen, on SAP Business AI Platform, with a stack of S/4HANA, SAP AI Core, Fiori and BTP. It grew out of a Hack2Build prototype from early 2024. It was then built in a six-month sprint. It went live in August 2025. And as of SAP publishing the story in July 2026, it is running across Natura’s Ecuador operations.
Read that again. SAP was in the room. Its own engineers were on the project. And the answer was still a custom build on BTP, not a switch in the standard product. If SAP could have solved this as a product, that was the project where it would have happened.
I want to be careful here, because it would be cheap to sneer at that. It is not a criticism of Natura, who did the right thing and clearly did it well, and one country in production beats ten in a slide deck. It is a criticism of how these stories get read. Somebody is going to show that article to a steering committee this quarter and say “SAP customers are doing AI margin analysis today.” True. It also took them a prototype, a six-month sprint, and roughly two and a half years from hackathon to that article.
And the tell is right at the end. Natura’s stated next phase is integrating Joule Agents, to automate the extraction of what SAP calls standard analytical content. So the reference architecture for building it yourself already has a plan to move part of itself onto the standard product. Budget accordingly. Some of what you build here you will throw away, and the people who built it are saying so out loud.
What I would actually tell a CFO
For most of these agents, wait. The close assistant, the AR assistant, the tax assistant, those are universal processes and SAP will do them better and cheaper than you will. Sitting on your hands for two quarters is the correct commercial decision.
Margin is the exception. Nothing on the roadmap covers it, and I do not expect anything to, because the answer depends on configuration only you ever made. If margin explanation is worth real money to your business, and in most manufacturing and consumer businesses it is worth more than anything else on this list, then this is the one place where building is defensible.
But build the boring half first. The COGS split, the cost component structure, the condition mapping, the characteristic derivation, the “Not assigned” cleanup. That work has a return whether or not you ever attach a model to it, because it makes the question answerable by a human too. Then put the language model on top, where it is genuinely good: writing the narrative, spotting the anomaly, ranking the drivers. The model is a very good explainer of a well-built number. It is a terrible substitute for one.
What I am not sure about
Let me be honest about the edges of this.
I have not seen the Natura application. I know what SAP’s article says about it and nothing more, so take the architecture from their write-up and not from my reading of it.
The Q3 2026 revenue-management margin insight capability might turn out to cover more ground than the one sentence announcing it suggests. Rebate and settlement anomalies are a real part of the margin story, especially in consumer goods, and if that capability lands well it closes part of the gap I have described. I will look at it when it ships, and if I am wrong about the scope I will say so.
And of course SAP may simply announce a margin agent at the next event and make this whole post look silly. Honestly, I hope so. Nothing would make me happier than being wrong here, because I would rather have the standard product than another BTP build to maintain.
Final thoughts
Two hundred agents is a serious piece of engineering and I do not want the headline of this post to read as cynicism, because the Autonomous Finance direction is right and some of these assistants will be genuinely useful the day they land. But an agent portfolio is a map of what a vendor can standardise, and the hole in the middle of this one is the most valuable question in Finance.
That hole is not going to be filled by SAP. It is going to be filled by whoever did the unglamorous work of making their cost of goods sold say what it is made of.
Which, if I am honest, is the same thing I have been writing on this blog since 2016, only now with a language model sitting on top of it.
What does your COGS account look like? One line, or five? Let me know in the comments, and stay tuned.
Sources
- SAP News Center, “How Natura &Co Is Transforming Finance with Generative AI on SAP S/4HANA”, 8 July 2026: https://news.sap.com/2026/07/natura-co-transforming-finance-generative-ai/
- SAP, Sapphire Innovation News Guide 2026 (Finance assistant availability, margin insights in revenue management): https://www.sap.com/topics/events/sapphire/innovation-news-guide-2026
- SAP News Center, “SAP Unveils the Autonomous Enterprise”, May 2026 (50+ assistants, 200+ agents, Autonomous Finance): https://news.sap.com/2026/05/sap-sapphire-sap-unveils-autonomous-enterprise/
- SAP News Center, “SAP Business AI: Release Highlights Q1 2026”: https://news.sap.com/2026/04/sap-business-ai-release-highlights-q1-2026/
