Formulas
A formula item computes its value from an expression written in the XCubes formula language. Formulas are attached to individual items in a dimension; the engine evaluates them when the cube is computed.
Basic expressions
A formula references sibling items by their code. Codes that start with a letter and contain only letters, digits, and underscores can be written bare. Numeric codes and codes with special characters must be wrapped in double quotes.
Revenue - COGS
"620200" + "22520"
"R&D" + "G&A"
The standard arithmetic operators +, -, *, / work as expected. Parentheses control precedence.
Summing multiple items
To sum a fixed list of items, write an explicit + chain:
ProductSales + ServiceSales + OtherRevenue
This is clearer and more predictable than SetSum(), which takes wildcard patterns (SetSum("Sales*")) and matches by code prefix. Reserve SetSum() for true wildcard aggregations ("everything starting with 6") rather than enumerated lists.
The self keyword
Some time-series functions accept the keyword self as their first argument — it refers to this same item at an adjacent period, so you don't repeat the item's own code. self is supported by Prior, Grow, Feed, FeedFrom, and YoY. For example, Prior(self; 1) reads this line's previous period, and Grow(self; 0.05) grows it 5% each period.
Functions that accumulate or read from the current period's own value — YTD, RollingSum, RollingAvg, Lag, PctChange — reject self, because referring to the value being computed would create a cycle. For those, pass the item's own code (e.g. YTD(Revenue)), or express same-line lookback with Prior(self) / Grow(self; …).
Function arguments use semicolons
Arguments to all functions are separated by semicolons (;), not commas:
Lag(Revenue; -1)
If(Condition; TrueValue; FalseValue)
(Lag's shift is signed — -1 is the previous data period, +1 the next.)
Item codes vs. reference names
Plain identifiers in a formula refer to sibling items in the same dimension. The functions Reference(), Prior(), and PriorDelta() take a reference name (a string in double quotes) that is resolved through the cube's registered cross-cube references — they do not refer to items. See Cube references.
How formulas behave at totals
When a formula item meets a total of another dimension — a quarter or year column, a scenario sum like ACT + PLAN, a subtotal row — the value in that cell depends on what kind of formula it is:
- Additive formulas (
Revenue - COGS,A + B + C) behave exactly as you'd expect: the total of the formula equals the formula of the totals. Both readings give the same number, so there is nothing to remember. - Ratio formulas (anything containing a division — margins, percentages, prices) are recomputed at the total from the totals of their inputs.
Margin = GM / Revenueat the FY column is FY-GM ÷ FY-Revenue — the ratio of the sums — not the sum of the twelve monthly margin cells. For a margin or a percentage this is almost always the number you want; it just isn't the sum of the cells displayed above it.
Two related rules:
- Hierarchy roll-ups only happen on hierarchical dimensions. A parent item on a freeform dimension never aggregates its children — give it a formula (
ChildA + ChildB + …) or convert the dimension to hierarchical. - Plain (non-formula) items crossing a total follow their per-item aggregation setting: sum (default), average, weighted, or none. Use
weightedfor prices and rates so their totals stay meaningful.
If you genuinely need "the sum of the computed cells" for a ratio-like item, model that total as its own explicit additive formula over the detail items rather than relying on the crossing.
Full function list
XCubes ships with functions for aggregation, math, logic, time-series navigation, and cross-cube lookups. The complete list with signatures and examples is in the Formula function reference.