An order received on Monday and dispatched on Wednesday belongs to different days depending on the question. Changing a chart's title to Dispatches does not change the relationship that carries its date filter. Inspect the model path used by the calculation.

Use a local practice import model without security roles. It needs an Orders table with OrderDate, DispatchDate and Units, plus a Calendar table whose Date column has one entry for every relevant day. For the first witness record, use order date 28 September 2026, dispatch date 30 September 2026 and Units 4.

Identify the existing paths

In Model view, inspect the relationship endpoints. An active relationship appears as a solid line; an inactive one is dashed. For this exercise, Calendar[Date] relates actively to Orders[OrderDate] and has an existing inactive relationship to Orders[DispatchDate]. Both date roles must be represented in the calendar and use compatible date values.

Create these measures, using the existing relationship columns exactly:

Ordered Units = SUM(Orders[Units])
Dispatched Units = CALCULATE(SUM(Orders[Units]), USERELATIONSHIP(Orders[DispatchDate], 'Calendar'[Date]))

USERELATIONSHIP selects an existing relationship for the duration of the calculation; it does not create a missing link. In this arrangement it uses the dispatch path instead of the default order-date path for that measure. Put the Calendar date field, rather than an Orders date field, in the comparison visual or date selection.

Follow the witness record through both dates

With 28 September selected, the four units belong to Ordered Units but not Dispatched Units. With 30 September selected, they belong to Dispatched Units but not Ordered Units. An absent contribution may display as blank rather than zero, so inspect membership and the underlying record instead of insisting on a particular empty display.

Add a second fictional order with different dates and units, then check each date separately. This prevents a single matching total from concealing a swapped endpoint. Label the measures by their date roles so a reader can explain why they disagree on one day.

This pattern is not a design for independently filtering both date roles at once. Microsoft recommends active relationships where possible and documents separate role-playing dimensions for that need. RLS filters never propagate through inactive relationships merely because a measure uses USERELATIONSHIP; security models require their own supported design and review. Preserve the working model and accept this change only for its declared reporting question.

Sources: Microsoft: model relationships; Microsoft: supporting procedure; Microsoft: supporting procedure.