For an aggregate unit price, divide total revenue by total units. Averaging each order's price gives every order equal weight, regardless of how many units it contains. Neither calculation is universally wrong; the metric definition decides which belongs in your report.
Use unequal quantities to expose the difference
This original fictional Orders table has one row per order. Units are positive in this fixture; Revenue is the whole order's revenue:
| Order | Category | Units | Revenue | Revenue / units |
|---|---|---|---|---|
| O1 | Small | 1 | 10 | 10 |
| O2 | Bulk | 9 | 18 | 2 |
Revenue totals 28 and units total 10. Revenue per unit is therefore 2.8. The unweighted average of the two order-level prices is (10+2)/2=6. That is average order-level unit price, not overall revenue per unit.
Microsoft's calculation-options documentation, checked October 24, 2026, distinguishes calculated columns evaluated row by row during refresh from measures evaluated on demand in filter context. Use that distinction when deciding what to ask ChatGPT to write.
Keep the column and measures visibly separate
If you need a stored price for each row, this illustrative calculated column belongs on Orders:
Row Unit Price = DIVIDE(Orders[Revenue], Orders[Units])
For the report's revenue-per-unit metric, these illustrative measures retain the current report context:
Revenue = SUM(Orders[Revenue])
Units = SUM(Orders[Units])
Revenue per Unit = DIVIDE([Revenue], [Units])
Enter each measure separately in the native model. The snippets are authored examples, not an executed PBIX file or a ChatGPT transcript. They assume those table and column names and compatible numeric types. Define your treatment of returns, negative quantities and missing values before adapting them to real transactions.
If you create AVERAGE(Orders[Row Unit Price]) instead, its total is 6 for this fixture. Changing its display format cannot turn it into the ratio-of-sums result. Fix the calculation's meaning before changing decimal places.
Ask for a metric and context review
Help draft DAX for this Power BI model. Do not edit the model.
Table/columns/data types: [PASTE]
Meaning of one row and active relationships: [PASTE]
Metric definition: [STATE EXACTLY WHAT NUMERATOR / DENOMINATOR MEAN]
Report grouping and slicers: [PASTE]
Rules for zeros, missing values and returns: [PASTE OR UNKNOWN]
Permitted sample and independently expected results: [PASTE]
First say whether each requested result needs a calculated column
or measure and explain why. Distinguish an average of row ratios
from a ratio of totals. Show both on the supplied sample if relevant.
For the chosen metric, propose the smallest DAX and trace its inputs
at detail, selected-category and total level. Do not remove filters,
add relationships or redefine a business rule without explaining
the separate proposed change. Keep unknown rules unresolved.
Label expectations as expectations, not native test results.
The task and boundaries follow OpenAI's prompting guidance. The answer should make the aggregation choice inspectable, rather than simply produce code that parses.
Test a selection and the total
With both rows visible, expect Revenue=28, Units=10 and Revenue per Unit=2.8. With Category filtered to Bulk, expect 18, 9 and 2. The stored Row Unit Price values remain 10 and 2; a filter changes which rows are visible, not how those stored values were calculated.
The report's grand total should evaluate the measure in total context. Do not replace it with the average or sum of displayed price cells. A different dataset may make the two results accidentally equal, so keep an unequal-quantity case in your review.
This fixture requires no filter removal. If your actual task is a category's share of a regional or global total, use the separate Power BI denominator guide and name that denominator explicitly.
Run the accepted expressions in a copy of the native model, compare the detail and total values with your defined metric, and keep the definition with the measure. The next analyst should be able to tell why the report shows 2.8 rather than 6.