Forum Discussion

jovalles's avatar
jovalles
Regular Visitor
1 year ago
Solved

DSO Measure Returns Different Values in Desktop vs. Web Service (Manual vs Auto Refresh)

I'm experiencing inconsistent behavior with my Days Sales Outstanding (DSO) calculation between Power BI Desktop and the Web Service. The measure shows correct values in Desktop but changes when published, with additional discrepancies between manual and automatic refresh modes.


// Outstanding Invoices
CXCVencida =
VAR PeriodEndDate = MAX(Calendar[Date])
RETURN
CALCULATE(
SUM(DSO[Invoice Amount DOP]),
FILTER(
ALL(DSO),
DSO[Invoice Date] <= PeriodEndDate &&
(ISBLANK(DSO[Payment Date]) || DSO[Payment Date] > PeriodEndDate)
)
)

// Monthly Billing
FacturadoMes =
CALCULATE(
SUM(DSO[Invoice Amount DOP]),
FILTER(
DSO,
MONTH(DSO[Invoice Date]) = MONTH(MAX(Calendar[Date])) &&
YEAR(DSO[Invoice Date]) = YEAR(MAX(Calendar[Date]))
)
)

// Final DSO Calculation
DSO Monthly = DIVIDE([CXCVencida], [FacturadoMes]) * 30



  1. Why would manual refresh in the web service return different results than automatic refresh?

  2. How can I ensure consistent behavior between Desktop and Service when using date-sensitive calculations?

  3. Are there known issues with the FILTER() function behaving differently across environments?

 

  • Anonymous's avatar
    Anonymous
    1 year ago

    Hi jovalles ,

    Thank you for the clarification and for sharing the optimized measure.

     

    Since you’ve already implemented a UTC-neutral column, the discrepancies you see are unlikely to be caused by time zones. In most cases, differences between Desktop and the Service come from the data itself rather than the DAX logic.

    Power BI Desktop refreshes against your local environment, while the Service refreshes directly from the data source so if query folding, source filters, or gateway settings are different, the rows being loaded may not match. I recommend first confirming that the row counts and sample data for the same periods are identical between Desktop and the Service dataset. Next, test the CXCVencida measure in a simple table visual with just Date, Invoice Date, Payment Date, and the measure, and compare results this will show you whether the discrepancy is caused by missing or extra rows, or by the filter context.

    Also review relationships in your model, since KEEPFILTERS and REMOVEFILTERS can behave differently if report-level filters or inactive relationships apply in Service. In short, the FILTER logic itself doesn’t change across environments the issue is almost always either mismatched data after refresh or differences in how context is applied. By validating the data loaded into both environments and simplifying the test context, you should be able to pinpoint the exact cause.

    Hope this helps. Please feel free to contact us if you have any further questions.

     

    Thank you.

9 Replies

  • Aburar_123's avatar
    Aburar_123
    Solution Supplier

    Hi jovalles ,

     

    Based on my understanding it would be the timing and refresh issue. There should not be an issue between manual and automatic refreshed data. Could you provide additional detail or screenshots?

  • Hey jovalles ,

     

    Well, the Power BI Service only operates in the UTC  time zone, so if you are working with non-UTC time zones you might run into discrepancies between Desktop and Service results.

     

    Please refer to this article from RADACAD discussing this in detail and various methods to handle it: https://radacad.com/solving-dax-time-zone-issue-in-power-bi/

     

    Well this usually is the primary reason behind time calculation discrepancy between Service and Desktop (from my experience), I have my doubts as you mentioned that automatic and manual refreshes in Service itself are behaving differently.

     

    Hope it helps!

     

    • jovalles's avatar
      jovalles
      Regular Visitor

      Sorry for my miscomunication, the automatic and manual refreshe are behaving equally.

      Im still having the same issue. I created a UTC-neutral DateUTC column in my Calendar table and modified my measures to use MAX(Calendar[DateUTC]) instead of MAX(Calendar[Date]) to avoid any time zone dependency.

      To illustrate the problem, here is a comparison of the values I get:


      In Power BI Desktop:

      Jan-2025: 635,706,010.66

      Feb-2025: 735,128,011.27

      Mar-2025: 753,983,131.76


      In the Power BI Web Service:

      Jan-2025: 457,431,176.11

      Feb-2025: 544,843,818.70

      Mar-2025: 564,175,021.57

  • Anonymous's avatar
    Anonymous
    Not applicable

    Hi jovalles ,

    Thank you for reaching out to the Microsoft fabric community forum. Also thank you Aburar_123jaineshp and alish_b  for your helpful response.

     

    I understand your concern about the differences between Power BI Desktop and the Service, particularly regarding the DSO measure showing discrepancies between manual and scheduled refreshes. I'll address your questions in detail.

     

    First, manual refreshes in the Service may yield different results than automatic refreshes mainly due to timing and time zone differences. Power BI Service operates in the UTC time zone, while Desktop uses your local machine’s time zone. Manual refreshes happen when you trigger them, but scheduled refreshes run at the planned UTC time. If your calculations depend on the current date or time, such as using MAX(Calendar[Date]), these timing differences can cause inconsistent results.

     

    Next, to ensure consistent behavior between Desktop and the Service, avoid relying on system time. Instead, align your model with UTC or adjust for your business time zone using an offset column in your Date table or DAX adjustments. A structured Calendar table with set date ranges helps maintain consistency across environments, so your DSO measure evaluates against the same time context for both manual and scheduled refreshes.

     

    Finally, the FILTER() function itself does not behave differently between Desktop and Service. The discrepancies are due to the filter context being evaluated at different times. Once you account for time zone and refresh timing, your calculations should be consistent across both environments.

     

    As the next step, I suggest checking your Calendar table to make sure it is set up to use UTC. If you need your reports to match a specific local time zone, you can add offset logic in the Date table or within your measures. For more details on managing time zone differences, see this article provided by alish_b . This approach should help you get consistent DSO calculation results in both Desktop and Service.

    Hope this helps. Please feel free to contact us if you have any further questions.

     

    Thank you.

    • jovalles's avatar
      jovalles
      Regular Visitor

      Hi,

      Thank you so much for your detailed and helpful response. I really appreciate you taking the time to explain the potential issue with the time zone.

      I have tried implementing your suggestion. I created a UTC-neutral DateUTC column in my Calendar table and modified my measures to use MAX(Calendar[DateUTC]) instead of MAX(Calendar[Date]) to avoid any time zone dependency.

      However, I am still experiencing the same discrepancy between the Power BI Desktop and the Web Service. The values for the CXCVencida measure are still different after publishing.

      To illustrate the problem, here is a comparison of the values I get:

      In Power BI Desktop:

      Jan-2025: 635,706,010.66

      Feb-2025: 735,128,011.27

      Mar-2025: 753,983,131.76

      In the Power BI Web Service:

      Jan-2025: 457,431,176.11

      Feb-2025: 544,843,818.70

      Mar-2025: 564,175,021.57

      As you can see, the Web Service values are consistently different. I understand the theory that it must be related to the filter context being evaluated at a different time, but I cannot identify the specific cause.

      Could you please provide further guidance? I am happy to share the exact DAX formula for the CXCVencida measure if that would help.

      CXCVencida Optimizada =
      VAR FechaFinMes = MAX(Query1[DateUTC])
      VAR UltimaFechaConDatos = MAX(DSO[Fecha de la Factura])
      RETURN
      IF(
      FechaFinMes > UltimaFechaConDatos,
      BLANK(),
      CALCULATE(
      SUM(DSO[Monto Facturado total DOP2]),
      KEEPFILTERS(
      DSO[Fecha de la Factura] <= FechaFinMes &&
      (
      DSO[Fecha del Pago] > FechaFinMes ||
      ISBLANK(DSO[Fecha del Pago])
      )
      ),
      REMOVEFILTERS(Query1)
      )
      )

      Let me know if you need anything else,

      Thank you again for your support.

      Best regards,

  • Anonymous's avatar
    Anonymous
    Not applicable

    Hi jovalles ,

    Thank you for the clarification and for sharing the optimized measure.

     

    Since you’ve already implemented a UTC-neutral column, the discrepancies you see are unlikely to be caused by time zones. In most cases, differences between Desktop and the Service come from the data itself rather than the DAX logic.

    Power BI Desktop refreshes against your local environment, while the Service refreshes directly from the data source so if query folding, source filters, or gateway settings are different, the rows being loaded may not match. I recommend first confirming that the row counts and sample data for the same periods are identical between Desktop and the Service dataset. Next, test the CXCVencida measure in a simple table visual with just Date, Invoice Date, Payment Date, and the measure, and compare results this will show you whether the discrepancy is caused by missing or extra rows, or by the filter context.

    Also review relationships in your model, since KEEPFILTERS and REMOVEFILTERS can behave differently if report-level filters or inactive relationships apply in Service. In short, the FILTER logic itself doesn’t change across environments the issue is almost always either mismatched data after refresh or differences in how context is applied. By validating the data loaded into both environments and simplifying the test context, you should be able to pinpoint the exact cause.

    Hope this helps. Please feel free to contact us if you have any further questions.

     

    Thank you.

  • Anonymous's avatar
    Anonymous
    Not applicable

    Hi jovalles ,

     

    I wanted to follow up on our previous suggestions. We would like to hear back from you to ensure we can assist you further.

     

    Thank you.

  • Anonymous's avatar
    Anonymous
    Not applicable

    Hi jovalles ,

     

    I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

     

    Thank you.

  • Anonymous's avatar
    Anonymous
    Not applicable

    Hi jovalles ,

     

    We haven’t received an update from you in some time. Could you please let us know if the issue has been resolved?
    If you still require support, please let us know, we are happy to assist you.

     

    Thank you.