Document a DAX measure for the next analyst

A measure's formula does not fully explain its business meaning. Document the population, grain, units, filter policy and unavailable states so another analyst can change the model without silently changing the metric.

Good documentation is short enough to maintain and concrete enough to test. A paragraph saying “calculates total sales” leaves too many decisions unresolved.

Start with the business question

For the retail lab, Paid Net Paise answers: “What is the net invoice-line value of Paid records in the current applicable date, product and customer context?”

This wording identifies status eligibility and the kind of value. It does not claim recognized revenue, cash received or accounting profit. Those would need different source evidence and policies.

State the measure's owner and intended use. A measure built for an operational queue may not be suitable for a financial close report even if both display monetary totals.

Record the row and amount contract

The source grain is one unique LineID per order line. OrderID can repeat. Net line value is Quantity × UnitPricePaise − DiscountPaise, with DiscountPaise applied once per line.

Amounts are integer paise. A visual displaying INR divides by 100; formatting alone does not convert units. CostPaise, if used in related measures, is also a line total and must not be multiplied by quantity again.

Record how duplicates, corrections and unknown customer identities are handled. The fixture retains Unknown customer key 0 in monetary totals while excluding it from known-customer counts.

Explain filter behaviour in plain language

The baseline measure is:

Paid Net Paise =
CALCULATE(
    SUMX(
        FactSales,
        FactSales[Quantity] * FactSales[UnitPricePaise]
            - FactSales[DiscountPaise]
    ),
    FactSales[Status] = "Paid"
)

Document that it fixes the same FactSales[Status] column to Paid, replacing a conflicting filter on that column. It retains relevant date, product and customer context unless another model rule changes the path.

Microsoft explains this filter modification in the CALCULATE reference. The documentation should translate that behaviour into what a reader sees when using the report's actual slicers.

Identify the time role and coverage

OrderDate is the active date role. A delivery-date variant has a different name and explicitly activates the alternate relationship. State the reporting timezone or date-normalization policy where source timestamps require one.

Record source-loaded-through metadata and any historical-correction policy. A measure can be mathematically stable while its source snapshot changes, so reproducibility needs both the formula version and the data version.

The synthetic lab covers its stated fixture only; it does not establish complete real-world historical sales.

Define blanks, zeros and exceptions

For a no-qualifying-row context, document the base measure's result and the separate presentation rule. If a display measure replaces blank with zero, state when complete source coverage justifies that choice.

For ratios built from this measure, document zero-denominator handling. Do not let a formatting decision erase the distinction between no activity, unknown data and an undefined rate.

List data-quality failures that should block the measure, such as conflicting line keys or invalid numeric amounts. A formula can execute over bad data, so these controls belong to the contract.

Attach reference cases

Keep a small table of expected results: all Paid 69,500; January Paid 47,500; Software Paid 39,000; January Software 29,000; Unknown Paid 5,000. Link each to an independent source check or inspectable records.

The shared measure-contract file demonstrates a compact implementation reference. Its DAX still requires Power BI application review; SQLite verifies the source controls separately.

Include at least one deliberately conflicting filter and one empty slice. Normal totals alone do not reveal whether a future edit changes filter replacement or unavailable-state behaviour.

Keep change history useful

Record what changed in the final definition, why the business meaning required it, which reports depend on it and which tests were rerun. Avoid a history consisting only of “updated formula.”

Exercise: write a one-page contract for Known Paid Customers. Explain why its unknown-key policy differs from Paid Net Paise and why its grouped counts need not sum to the overall distinct count.

NeuraPath's Data Analytics with Generative AI course connects implementation with maintainable analytical definitions. A documented measure lets the next analyst reproduce its meaning, not merely copy its syntax.

Continue learning

This article is part of the DAX measures and analytical correctness sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Debug a DAX measure with a small validation table.
• Continue with Build a regression checklist for changed dashboard measures.