For over two decades, Multidimensional Expressions (MDX) has been the standard language for querying data in Oracle Essbase and EPM Planning Cloud. It is powerful, precise, and deeply integrated into the platform. It is also one of the primary reasons that EPM data access remains restricted to a small group of specialists within most organizations.
Natural language AI offers a fundamentally different approach. Instead of learning a query language, users describe what they want in plain English. The AI handles the translation. This article examines both approaches, compares them directly, and explains why an increasing number of finance teams are embracing natural language as their primary interface to EPM data.
MDX: The Established Standard
MDX was designed for multidimensional databases. It provides a structured way to specify exactly which data points you want from a cube by defining members on rows, columns, and filter axes. For Oracle EPM, MDX is the native query language for Essbase, and it powers the calculations behind SmartView reports, Financial Reporting, and ad-hoc analysis.
A well-crafted MDX query is precise and efficient. It can handle complex member selections, calculated members, time-series functions, and cross-dimensional aggregations. For EPM administrators and power users who write these queries daily, MDX is an indispensable tool.
The problem is not with MDX itself. The problem is with the gap between what most people need from EPM and the expertise required to write correct MDX.
The Learning Curve Problem
Consider what a finance analyst needs to know to write a basic MDX query against an EPM Planning cube:
- Dimension names and structures: You need to know every dimension in the cube, how members are organized hierarchically, and which member codes correspond to which business concepts
- MDX syntax: The SELECT, FROM, WHERE, and ON keywords have specific semantics. Axis definitions require exact syntax. Member references use a bracket-and-dot notation that is unforgiving of typos
- EPM-specific functions: Functions like .Children, .Descendants, .Parent, CrossJoin, and Filter have specific behaviors. Using the wrong function produces wrong results, not errors
- Cube-specific conventions: Different cubes may use different member naming schemes, have different required dimensions, or require specific members in the POV
Training a new analyst to be proficient with MDX typically takes three to six months of regular practice. During that time, they rely on senior team members for data requests—creating a bottleneck that compounds as organizations grow.
Side-by-Side: MDX vs Natural Language
The difference becomes tangible when you compare specific examples. Here are three common EPM queries expressed in both MDX and natural language:
Example 1: Revenue by Entity
MDX:
SELECT {[Account].[Revenue]} ON COLUMNS,
{[Entity].[North America].Children} ON ROWS
FROM [Finance]
WHERE ([Scenario].[Actual], [Year].[FY25], [Period].[Q4], [Version].[Final])
Natural Language:
Show me actual revenue for North America entities in Q4 FY25
Example 2: Budget vs Actual Variance
MDX:
WITH MEMBER [Measures].[Variance] AS [Scenario].[Actual] - [Scenario].[Budget]
SELECT {[Scenario].[Actual], [Scenario].[Budget], [Measures].[Variance]} ON COLUMNS,
{[Account].[Operating Expenses].Children} ON ROWS
FROM [Finance]
WHERE ([Entity].[Total Company], [Year].[FY25], [Period].[YearTotal], [Version].[Final])
Natural Language:
Compare actual vs budget for operating expense accounts, full year FY25, total company
Example 3: Headcount Forecast by Department
MDX:
SELECT {Descendants([Period].[Q3], 1)} ON COLUMNS,
{[Department].Children} ON ROWS
FROM [Workforce]
WHERE ([Account].[Headcount], [Scenario].[Forecast], [Year].[FY26], [Version].[Working])
Natural Language:
Show headcount forecast by department for Q3 FY26, monthly breakdown, working version
In each case, the natural language query conveys the same intent in a fraction of the words. More importantly, it requires no knowledge of dimension naming conventions, axis placement, or MDX syntax. The AI infers the cube, resolves member names, applies appropriate functions like Descendants or Children, and fills in default dimension values—all from a single sentence.
Benefits Beyond Syntax
The advantages of natural language extend well beyond eliminating MDX syntax. Several capabilities are either impossible or impractical with traditional query approaches:
Context retention across queries. In a natural language conversation, the AI remembers previous selections. If you ask about Q4 revenue and then say "now show me Q3," the system carries forward all other dimension selections. With MDX, every query is independent—you rewrite the full statement each time.
Intelligent error prevention. Type "Nort America" in an MDX query and you get an error. Type it in a natural language query and the AI recognizes the intent, resolves it to "North America," and proceeds. The system handles typos, abbreviations, alternative names, and partial matches through semantic search against the metadata index.
Automatic default handling. MDX requires you to specify every dimension in the POV. Natural language queries apply intelligent defaults—the current fiscal year, the Actual scenario, the Final version—unless you explicitly state otherwise. This alone eliminates the most common source of MDX errors: missing or incorrect POV dimensions.
Multi-turn analysis. A typical analysis session involves iterative exploration. Start with a high-level view, drill into specific entities, switch scenarios, change time periods. Natural language supports this as a continuous conversation. MDX requires a completely new query for each iteration.
When MDX Still Matters
Natural language is not a wholesale replacement for MDX. There are scenarios where MDX remains the better choice:
- Complex calculated members: Custom calculations involving conditional logic, time-series transformations, or cross-dimensional formulas are still more precisely expressed in MDX
- Automated reporting: Scheduled reports and batch processes that run unattended rely on deterministic MDX queries that produce identical results every time
- Performance tuning: When query performance is critical, an experienced MDX developer can optimize axis placement and member selections in ways that a natural language layer may not
- Integration scripts: ETL processes, data validation routines, and system-to-system integrations use MDX as a programmatic interface
The key insight is that these are specialized use cases handled by a small number of technical users. The vast majority of day-to-day EPM interactions—data lookups, variance checks, scenario comparisons, hierarchy exploration—are far better served by natural language.
The Transition: Using Both Together
The most effective approach is not an abrupt switch from MDX to natural language. It is a gradual expansion of EPM access. Power users continue to write MDX when it serves them. Meanwhile, the broader finance organization gains direct access to EPM data through natural language—access they never had before.
This coexistence creates a multiplier effect. The EPM team spends less time fielding ad-hoc data requests and more time on the complex analytical work that genuinely requires their expertise. Business users get faster answers and develop a better understanding of the data available to them. And the AI layer continuously improves as it processes more queries and accumulates organizational context.
The goal is not to eliminate MDX expertise from your organization. It is to ensure that MDX expertise is no longer the bottleneck standing between your team and the data they need.
For finance teams still debating whether to adopt AI-powered EPM tools, the question is straightforward: how much of your team's time is currently spent translating data requests into queries, and what would they do with that time if the translation happened automatically?