Power Query combined the finance files, but did it skip one?

A folder-based finance report can refresh successfully while leaving out an expected source file. The omission may come from a folder filter, a failed transformation or an option that excludes errors. Investigate the population of files before concluding that a lower revenue or expense total represents a change in the business.

Microsoft documents an option called Skip files with errors in the Power Query combine-files process. When selected, files producing errors are left out of the final output. That can be useful during diagnosis, but it changes what a successful result means. Completion of the query does not establish that every required period, entity or source export was included.

Preserve the current result and query version while finding the gap. Keep an earlier accepted output available for comparison, but do not copy its missing amount into the new report as a balancing adjustment. The repair needs to restore the intended records or clearly identify a limited report.

Establish which files the run should contain. Record the business period, entity, source type, file name and version or other stable reference. The list should come from the agreed reporting requirement and actual export handoff, not merely from whatever happens to be in the folder when the query runs.

Distinguish an original export from a replacement. If a corrected March file supersedes an earlier March file, including both can duplicate records while excluding both creates a gap. Preserve the older file according to the records process and identify which version belongs in this run. File modification time alone may not establish that a copy contains newer accounting data.

Review filters applied to the folder listing before combination. An extension, name pattern, path or date condition can exclude a legitimate file before the transformation ever sees it. Keep temporary files and unrelated documents out using an explicit rule, then compare the retained list with the expected manifest. Count the accepted files by period and entity, not only in total.

Power Query analyzes an example file when building the combination, using the first listed file by default. Microsoft explains that the generated example transformation is linked to the function applied across the files. A successful preview of that example therefore does not prove that the transformation suits every other member of the population.

Inspect meaningful differences between files: worksheet or table names, header rows, column labels, types and leading explanatory text. A source-system change can make one month structurally different. A manually prepared replacement may include a title row that the regular export lacks. Ask the source owner to confirm the intended structure before changing the query to accommodate an unexplained variation.

Use representative files to test the transformation. If the intended input formats differ, separate and document their handling rather than making one sample silently define all of them. Changing the example transformation can affect every file, so compare previously correct periods as well as the file that originally failed.

For each expected file, record whether it was found, selected, transformed and included. Retain the reason when a file is rejected or held. These states distinguish a missing upload from an incompatible structure and from a deliberate business exclusion. The next action belongs to the person who can resolve that particular cause.

Consider three invented exports with 40, 60 and 50 transactions, totaling $4,000, $6,000 and $5,000. The complete population contains 150 transactions and $15,000. If the middle file fails and is skipped, the output contains 90 transactions and $9,000. The $6,000 shortfall is explained by a missing file; no amount of inspecting the remaining 90 correct rows can establish completeness.

Check both counts and financial controls. A replacement export can have the expected number of rows while containing changed values, and two omitted files can offset in a net total. Where available, reconcile source control totals and stable transaction references for each accepted file before combining the full output. Preserve enough evidence to reproduce the run without relying on a folder screenshot.

If the source file is damaged or incomplete, obtain a controlled replacement from the source owner. If the file is valid but the transformation is wrong, correct the relevant step and rerun the affected population. Keep the rejected original and error detail where appropriate for investigation, with access suited to the underlying financial information.

Avoid deleting a difficult file just to obtain a clean refresh. Likewise, turning off error visibility does not fix a changed amount format or missing required column. If management needs a partial output before the source is repaired, label the excluded entity or period and the decisions that the limited report can support.

After correction, confirm that the formerly failed file contributes the intended rows once. Check that the folder does not contain an additional copy with a slightly different name that the broad filter also accepts. The completed repair should reconcile the expected file manifest, accepted file outcomes and final transaction totals together.

Keep the expected population and the result summary with the recurring process. Define who investigates a missing period, unexpected file or transformation failure before a report is released. A refresh can remain operationally useful while flagging a specific incomplete component; the warning should survive export into the management pack.

Revisit the combination when the source changes format or the reporting scope gains another entity. Retain a small set of representative accepted files for a focused check of those changes. The team should be able to explain which files produced the current report and which exceptions remain, rather than treating a successful refresh notification as proof that the folder was complete.