The energy and commodities trading software market has spent thirty years selling complexity as a feature. The argument was always implicit but effective: our system handles the hard stuff — the edge cases, the obscure derivatives structures, the cross-border compliance requirements. The complexity is the product. Pay for it, live inside it, and don't ask too many questions about whether it was ever necessary in the first place.
AI is about to ask those questions at scale. And the answers are going to be uncomfortable.
This isn't an argument that AI will add intelligence to ETRM and CTRM platforms. That's the story vendors want you focused on — the predictive analytics, the intelligent reporting, the "AI-powered" dashboards bolted on top of systems whose core data models haven't meaningfully changed since 2005. The more interesting story is structural: AI is acting as a diagnostic, exposing the difference between complexity that reflects genuine market and regulatory requirements and complexity that reflects poor architecture dressed up as sophistication.
When a well-prompted language model can parse a physical gas contract and extract risk positions in seconds, it starts asking uncomfortable questions about why that process previously required a $400,000-a-year specialised module and a team of consultants.
The SAP Analogy Is More Precise Than It Looks
SAP didn't fail organisations because it was bad software. It failed them because it encoded 1990s business process assumptions into concrete, then charged them to live inside that concrete for decades. The ERP's data model became its moat — everything had to flow through SAP's schema, and once you were inside it, extraction was almost as painful as staying.
What disrupted SAP wasn't a better ERP. It was unbundling. Workday took HR. Salesforce took CRM. Coupa took procurement. Point solutions that did one thing exceptionally well, built on modern architectures, made the question "do I need SAP for this?" answerable with a clear no.
ETRM and CTRM vendors have built the same moat using the same logic. The data model is proprietary. Implementation takes 18 to 36 months. Consulting dependency runs three to five times the software licence cost. Switching costs are so high they functionally eliminate competition — not because your current system is good enough, but because leaving is brutal.
Now consider what's hitting the ETRM market simultaneously: commodity markets are structuring new contract types monthly as carbon markets mature; renewable intermittency is forcing real-time operational adjustments that batch-processing systems handle badly; and regulatory requirements are fragmenting across jurisdictions faster than vendors can update their compliance modules. That's not one disruption. That's three. And the architecture underneath most ETRM platforms was designed for none of them.
The Spreadsheet Shadow Tells You Everything
There's a pattern so common in mid-market energy companies that most people inside these organisations treat it as normal. Call it the spreadsheet shadow: a parallel Excel or Google Sheets infrastructure that traders, risk managers, and schedulers use for the calculations they actually trust, which they then reconcile with ETRM outputs before submitting regulatory reports.
This isn't laziness or change resistance. It's a rational response to a system that takes 30 to 90 minutes to run a calculation cycle, can't be interrogated ad hoc without raising an IT ticket, and has a UI designed for implementation consultants rather than traders. The spreadsheet shadow exists because the ETRM failed to replace the cognitive workflow it was supposed to support.
Here's why this matters now: when an AI tool can replicate those same calculations in real-time, against better data, with natural language queries, the ETRM's value proposition collapses to something much smaller and more commoditised. It becomes: we store the official records and generate regulatory reports. That's a data warehouse with compliance formatting. It's not a $2 million platform with five years of consulting embedded in it.
The spreadsheet shadow has always been the tell. The question was never whether traders would use spreadsheets alongside their ETRM. The question is what happens when the spreadsheet's replacement is smarter than the ETRM.
The Data Model Is the Prison
For engineering leaders evaluating these platforms, the core technical problem is specific: most ETRM complexity lives in the data model, not in the business logic.
An ETRM is, at its core, four things bolted together — a trade capture system, a risk engine, a logistics and scheduling module, and a financial settlement system. The complexity these systems sell is their ability to handle variations across all four domains simultaneously, across different commodity types, contract structures, and regulatory jurisdictions. What this produces architecturally is a labyrinthine schema designed to capture every possible variation of every possible trade structure in every possible commodity market. The schema is supposed to be comprehensive. It becomes a prison.
When you try to build an AI layer on top of a legacy ETRM, you hit the data model immediately. Positions are stored in normalised tables that require twelve-join SQL queries to reconstruct. Risk calculations are buried in vendor-proprietary formula engines. Contract terms live in free-text fields or, worse, in the heads of the consultants who implemented the system.
An AI agent trying to answer "what is our current net exposure to European gas if TTF moves ten percent against us?" should be a tractable question. On most ETRM platforms, answering it requires navigating a data model designed in the early 2000s — before anyone imagined asking that question via natural language, or in many cases asking it at all without running an overnight batch.
The practical failure mode looks like this: a risk dashboard powered by machine learning shows portfolio exposure metrics built on a data model where fifteen to twenty percent of positions carry classification errors, hedge designations are inconsistently applied, and physical-to-financial position netting logic was customised differently for each business unit during implementation. The AI generates confident-looking outputs. The traders learn the outputs are unreliable. The tool gets quietly abandoned. The ETRM's data quality problem, which existed long before the AI layer arrived, becomes the AI layer's reputation problem.
OTRM Is the First Visible Crack in the Monolith
The emergence of OTRM — Operations and Trading Risk Management — as a distinct software category is being read by many as a new entrant competing in an adjacent space. The more accurate reading is that it's the first visible fracture in the ETRM monolith, and it maps almost exactly to the ERP unbundling pattern.
OTRM takes the back-office and operational execution layer of an ETRM, strips out the front-office trading intelligence, and rebuilds it with modern automation primitives focused on nomination matching, scheduling workflows, document processing, and exception management. What was described for years as an area of "high complexity and low automation" turns out to be highly automatable once you're no longer constrained by the ETRM's data model.
The architectural implication is significant. Traditional ETRM is a system-of-record architecture: data flows through a defined sequence of states — confirmed, scheduled, delivered, settled — and each state transition updates a central record. This works when markets are slow, contracts are standardised, and exceptions are rare. Modern energy markets, particularly with renewable intermittency creating constant intraday adjustments, generate continuous event streams that system-of-record architectures handle badly.
The better-capitalised trading operations are already executing an architectural inversion. Rather than treating the ETRM as the hub that everything integrates to, they're building an immutable event log — Kafka or equivalent — as the source of truth. The ETRM becomes one consumer among many: it receives events, writes back settlements, generates compliance reports, but no longer owns the data model. AI agents, risk systems, and operational tools all read from the same event stream independently. When this pattern becomes the default rather than the exception, the ETRM's structural position in the technology stack changes permanently. It stops being infrastructure and becomes a legacy application running alongside the actual infrastructure.
What Vendors Will Tell You Is Happening vs. What's Actually Happening
Every major ETRM vendor is currently announcing an AI strategy. The pattern is predictable: year one brings an AI roadmap revealed at the annual user conference; year two produces a bolt-on analytics module with basic forecasting features, marketed as "AI-powered"; year three involves acquiring a small AI startup and announcing deep integration that will take eighteen months to materialise; by year four, the underlying platform still has the same 2005-era data model.
The vendor narrative positions AI as additive — new intelligence layered on proven systems. This framing is both accurate and misleading. It's accurate that AI can add genuine value to workflow automation, document processing, and pattern detection on top of existing systems. It's misleading because it obscures the more significant dynamic: agentic AI systems — those capable of autonomous reasoning and action across multiple systems — don't require the ETRM's proprietary data model as an intermediary.
If an AI agent can reason about positions, exposures, and hedging strategies from raw data — market feeds, contract documents, logistics data, exchange APIs — the ETRM's data model goes from being a competitive moat to being an obstacle. This is the precise parallel to what happened to SAP. SAP's moat was that its data model was the connective tissue of enterprise operations. That moat eroded when point solutions demonstrated they could operate effectively without it.
The question a CTO needs to ask any ETRM vendor presenting an AI roadmap is not "do you have an AI strategy?" It is: can an external AI agent access your data model cleanly enough to be useful, and what does your API surface look like against a modern event-driven architecture? A vendor who can't answer that in concrete technical terms is selling you a roadmap, not a capability.
The Diagnostic You Can Run This Week
If you're running technology at an energy or commodities firm with an ETRM or CTRM in production, start here: find your spreadsheet shadow.
Identify the three to five calculations or workflows that your traders, risk managers, or schedulers are running outside the ETRM because they don't trust what's inside it, or can't access it without friction. Document them with enough specificity to understand the data inputs, the calculation logic, and the frequency of use. Then ask a single question: what would it take to run these workflows against clean data using a modern AI tool, bypassing the ETRM entirely?
You're not committing to a replacement programme. You're running a diagnostic. Specifically, you're testing whether your ETRM's complexity is load-bearing — whether it's doing something irreplaceable — or whether it's been the source of the friction all along.
Two outcomes are possible. The first: the workflows are genuinely complex, the ETRM's data model is handling something real, and the path forward is improving how AI tools consume that model. The second: the workflows are straightforward, the ETRM's involvement is adding latency and unreliability rather than value, and you now have a concrete, business-justified case for beginning to route around it.
Either outcome is more useful than anything a vendor demo or consultant assessment will tell you. And it will take a week, not six months.
The SAP Moment for ETRM vendors isn't coming because AI is smarter than their software. It's coming because AI will finally make the cost of complexity visible to the people paying for it — not as a theoretical argument, but as a live comparison running on their own data, answering their own questions, in the time it used to take to raise an IT ticket.
That's when the conversation changes. And for most vendors, the conversation is already starting.