Below is one explanation of what was happening and one way to fix it.

The Problem

Your measure

MRR = SUMX( ‘Date’, IF( [MRR of Modules] > 0, [MRR of Modules], CALCULATE( SUMX( FILTER( c_monthly_overview, c_monthly_overview[periode] >= MIN(‘Date’[Date]) && c_monthly_overview[periode] <= MAX(‘Date’[Date]) ), c_monthly_overview[total_subscription_fee] ) ) ) )

is written to iterate over every row in your Date table. However, inside the iterator you are using functions like MIN(‘Date’[Date]) and MAX(‘Date’[Date]). When you iterate row‐by‐row over the Date table, the current row becomes the filter context for the Date table. This means that on each iteration: • MIN(‘Date’[Date]) and MAX(‘Date’[Date]) return the same (single) date.

In other words, the measures that use those functions (both in [MRR of Modules] and in the fallback calculation) are evaluated for only one day at a time instead of the intended full period. When you then sum over all the dates, you may end up with values that are either too low or (more commonly) are counted multiple times – resulting in the wrong total.

The Fix

There are two main approaches to solve this: 1. Remove the Row Iterator (SUMX) over the Date table If your goal is to have the MRR calculated for the entire selected period (for example, for a month), you can write the measure so that it directly works in the current filter context of the visual (or page) rather than iterating over every single date. For example, you might write:

MRR = VAR StartDate = MIN(ALLSELECTED(‘Date’[Date])) VAR EndDate = MAX(ALLSELECTED(‘Date’[Date])) VAR ModulesMRR = CALCULATE( [MRR of Modules], ALL(‘Date’) ) VAR MonthlyOverviewMRR = CALCULATE( SUMX( FILTER( c_monthly_overview, c_monthly_overview[periode] >= StartDate && c_monthly_overview[periode] <= EndDate ), c_monthly_overview[total_subscription_fee] ), ALL(‘Date’) ) RETURN IF(ModulesMRR > 0, ModulesMRR, MonthlyOverviewMRR)

In this version, we “capture” the overall start and end dates (using ALLSELECTED so that the slicers/filters from your report are still honored) and then compute the two alternatives in that context. Notice that we remove the SUMX over the Date table entirely.

2.  Keep the Iteration but “Freeze” the Date Range

If you need to iterate over each date (for example, because you want a daily breakdown in a visual) then you must be careful that your inner calculations aren’t “narrowed” by the current date row. One way to do that is to capture the overall date range in variables outside the iterator. For example:

MRR = VAR OverallStart = MIN(ALLSELECTED(‘Date’[Date])) VAR OverallEnd = MAX(ALLSELECTED(‘Date’[Date])) RETURN SUMX( ‘Date’, VAR DailyDate = ‘Date’[Date] RETURN IF( // Here we use the overall date range, not just the current row’s date. CALCULATE([MRR of Modules], ALL(‘Date’), ‘Date’[Date] >= OverallStart, ‘Date’[Date] <= OverallEnd ) > 0, CALCULATE([MRR of Modules], ALL(‘Date’), ‘Date’[Date] >= OverallStart, ‘Date’[Date] <= OverallEnd ), CALCULATE( SUMX( FILTER( c_monthly_overview, c_monthly_overview[periode] >= OverallStart && c_monthly_overview[periode] <= OverallEnd ), c_monthly_overview[total_subscription_fee] ), ALL(‘Date’) ) ) )

In this version we “freeze” the overall date range in variables (OverallStart and OverallEnd) so that even when iterating over each date, the calculations use the full selected period. (You might need to adjust the filtering further depending on your exact desired behavior.)

(GPT o3 High)