Incremental refresh is the Power BI dataset feature that partitions a table’s data by date range and refreshes only the partitions containing data that has changed since the last refresh — leaving historical partitions unchanged and loading only the recent data window. Without incremental refresh, a finance GL fact table with five years of history must be fully reloaded on every scheduled refresh — even if only the current month’s data has changed. With incremental refresh, historical partitions (data older than the defined rolling window) are preserved in the model without reloading; only the current and recent partitions — where new journals, adjustments, and corrections are posted — are refreshed. This reduces refresh duration, reduces source system load, and enables more frequent refresh cycles on large datasets.
How It Works
Incremental refresh requires two parameters defined in the Power Query M code: RangeStart and RangeEnd, which are used to filter the source query to a specific date range. Power BI uses these parameters to partition the dataset’s data by date. At each refresh cycle, Power BI evaluates which partitions fall within the defined refresh window — typically the last N months — and refreshes those partitions only. Partitions outside the refresh window (historical data) are retained in the model unchanged.
For the incremental refresh to function, the RangeStart/RangeEnd filter must fold to the source system — it must be translated into a native source query with a date predicate, not applied locally after downloading the full dataset. If query folding is not achieved for the date filter, incremental refresh still operates (partitioning the model), but the source query downloads the full table for each partition — eliminating the source system load benefit while retaining the model partitioning structure.
Design Decisions and Trade-offs
The incremental refresh window must accommodate the restatement behaviour of the finance data. Finance GL data is frequently restated — journals are reversed and reposted, period-end adjustments are backdated, intercompany adjustments are applied to prior periods. If the refresh window covers only the current month, a prior-month restatement will not be captured in the next refresh, and the model will retain the pre-restatement data for that period. The refresh window must extend back to cover the maximum realistic restatement horizon — typically three to six months for active close and restatement environments — to ensure that restated data is captured on the next refresh cycle.
Common Implementation Errors
The specific incremental refresh configuration error that produces the most confusing finance data discrepancies is configuring a historical data freeze without accounting for late-arriving adjustments. Power BI Premium’s “detect data changes” option can mark historical partitions as frozen — never refreshed even if they contain corrections. When an auditor requires a prior-year restatement that posts journals to a period covered by a frozen partition, the Power BI model does not reflect the restatement. Finance users see a discrepancy between the BI report and the ERP trial balance that cannot be explained without understanding that incremental refresh has frozen the affected period. Frozen historical partitions must be explicitly listed in the data governance documentation and the operations team must have a manual partition refresh procedure for restatement scenarios.
How Loop Wise Solutions Designs for This
We document the incremental refresh configuration — the rolling window, the freeze policy, and the manual refresh procedure for out-of-window restatements — as a data operations governance document alongside the model architecture. We also validate the query folding of the RangeStart/RangeEnd filter before go-live, confirming that source queries include the date predicate rather than downloading the full table for each partition evaluation.
