Power BI'da DAX ile Zaman Analizi

The model first: date table and relationship

For DAX time intelligence to work reliably you need an unbroken date table at day level. Relate it one-to-many to the order date in your sales table and make sure the date filter flows into sales. With the classic time-intelligence approach, flag the table with Mark as date table.

Date =
ADDCOLUMNS(
    CALENDAR(MIN(Sales[OrderDate]), MAX(Sales[OrderDate])),
    "Year", YEAR([Date]),
    "MonthNo", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "YearMonth", FORMAT([Date], "yyyy-MM")
)

Sort the Month column by MonthNo — otherwise Power BI orders month names alphabetically and your chart runs April, August, December. The date table must contain unique, non-blank, uninterrupted dates.

1. Build the base measure

Every time comparison is built on a single base measure. Even for something as simple as a total, use a measure that recalculates in filter context rather than a calculated column.

Total Sales =
SUM(Sales[SalesAmount])

Add Date[YearMonth] to a chart and use this measure as the value to see monthly totals. Every measure from here on works by re-evaluating the same calculation in a different date context.

2. Comparing with the previous period

To find the previous month on a monthly axis, shift the current date context back by one month with DATEADD. One thing to watch: the function shifts the range in context. If the visual is at day level, you get that day a month earlier rather than a whole month — for “the previous full month” you need a selection consistent with the visual's period level.

Previous Month Sales =
CALCULATE(
    [Total Sales],
    DATEADD('Date'[Date], -1, MONTH)
)

Change vs Previous Month =
[Total Sales] - [Previous Month Sales]

When there is no data in the previous period, returning blank is usually the correct behaviour — writing zero says “there were no sales”, when the truth may be “that period does not exist yet”. If you still need a zero, use COALESCE([Previous Month Sales], 0) and think about what it means in the report.

3. Monthly change and growth rate

The absolute monthly change is the difference in amount against the previous month. The relative change is that difference over the previous month. If the previous month is zero the division is undefined; DIVIDE returns blank instead of raising an error.

MoM Change =
[Total Sales] - [Previous Month Sales]

MoM Growth % =
DIVIDE(
    [Total Sales] - [Previous Month Sales],
    [Previous Month Sales]
)

Format the measure as a percentage in Power BI; do not also multiply by 100 inside the measure — do both and you will be reporting 1000% growth. For example, a rise from 120,000 to 132,000 is an absolute change of 12,000 and growth of 10%.

4. The same period last year

When seasonality is strong, comparing with the same period last year beats comparing with the previous calendar month. In retail, comparing December with November rarely says anything; comparing December with last December does.

Sales Same Period LY =
CALCULATE(
    [Total Sales],
    SAMEPERIODLASTYEAR('Date'[Date])
)

YoY Growth % =
DIVIDE(
    [Total Sales] - [Sales Same Period LY],
    [Sales Same Period LY]
)

Always verify the expected date alignment in leap-year and fiscal-calendar scenarios. If the calendar year does not start on 1 January, you have to define the year end explicitly in your fiscal measures.

5. Year-to-date totals

YTD is the value accumulated from the start of the selected year up to the date in filter context. It is used to show cumulative progress against an annual target across days or months.

Sales YTD =
TOTALYTD(
    [Total Sales],
    'Date'[Date]
)

You can also write CALCULATE([Total Sales], DATESYTD('Date'[Date])); both give the same result. If you use a fiscal year, pass the year end as a parameter:

Sales FYTD =
TOTALYTD(
    [Total Sales],
    'Date'[Date],
    "6/30"
)

The "6/30" here says the fiscal year ends on 30 June. Verify that format against a matrix in your own model — a wrong fiscal definition quietly shifts every cumulative figure.

6. How filter context changes

CALCULATE evaluates a measure in a new filter context. If March 2026 is selected in the visual, DATEADD shifts the date filter back one month and the base sales measure is recalculated over February's dates. This is exactly why DAX measures respond to slicers, rows and columns.

Other filters such as product or region are usually preserved, so the result becomes “previous month's sales for the current product and region”. When a number surprises you, check in order: is the date relationship active, is the visual using the fact table's date or the date table's, and which slicers are applied?

Which measure for which question?

A checklist for correct results

Common problems

Missing or duplicated dates, an unrelated date table, using the fact table's own date hierarchy, sorting month names alphabetically, and turning blanks into zeros without noticing are the most frequent mistakes. What they share is that none of them raise an error — the report runs, it just shows the wrong number.

That is why the order matters: validate the base sales measure against the date table in a matrix first, confirm the totals match numbers you already know, and then add the time intelligence measures. If the base measure is wrong, everything built on it is wrong too.

The date model is the foundation

All of DAX time analysis rests on one idea: re-evaluating a simple sales measure over different periods using CALCULATE and date functions. Previous month, growth percentage, last year and YTD are all variations on that.

Always report what a measure means together with its filter context and the business calendar. The sentence “12% growth” tells the reader nothing unless you have written down what it is measured against and with which period definition.

Sources

• Microsoft Learn — Set and use date tables
• Microsoft Learn — DAX time intelligence functions
• Microsoft Learn — DATEADD
• Microsoft Learn — SAMEPERIODLASTYEAR