ReconVerify

POWER QUERY SOURCE TROUBLESHOOTING

Power Query column not found after refresh: how schema drift breaks recurring files

A recurring Power Query workflow can work for months and then suddenly report that a column is missing. The source may have changed, or an earlier transformation may have changed the table before the failing step ever sees it.

Published · Last reviewed

Short answer

A “column wasn't found” error usually means a Power Query step expects a column name that is not present in the table produced by the previous step. The useful question is not only whether the column exists in the original file, but whether it still exists under the expected name at that point in the transformation chain.

THE STRUCTURAL CHANGE

What do we mean by schema drift?

In this guide, schema drift is shorthand for a change in the structure or expected interpretation of a recurring source. It can involve names, headers, data types, file structure, or the object Power Query expects to navigate to.

Expected sourcetransaction_idtransaction_datedescriptionamount
New sourcetransaction_idtransaction_datedescriptionamount_local

The files still look very similar, but one assumption changed: amount became amount_local. If a later step still expects amount, the query can fail.

Not every structural change produces an error. Some allow the query to continue while changing what information reaches the final result.

COMMON PATTERNS

Six ways a recurring Power Query source can drift

01

A required column was renamed or removed

If an upstream export changes amount to amount_local, a later step that selects, renames, converts, or calculates from amount may fail. Before replacing the old name, establish whether the new field actually has the same meaning, units, sign convention, and population.

02

A new source column disappears without an error

An existing transformation can explicitly keep only the original columns. If a later source adds a field such as currency, that new field can be excluded downstream while the query still refreshes. The field may be irrelevant, but the structural change is worth understanding rather than assuming the input contract is unchanged.

03

The wrong row became the column headers

A recurring report may normally have two introductory rows before the real headers. If a later report adds another line, a fixed “remove top rows” step can leave the wrong row in first position before headers are promoted. The visible missing-column error may then occur several transformations after the underlying change.

Monthly Reconciliation ReportDepartment: FinanceGenerated: 2026-08-31transaction_id | date | amount
04

The column still exists, but its values changed type

A numeric amount field can begin containing text such as N/A, or a recurring date field can arrive in a different representation. The field name is unchanged, but its values no longer satisfy the same type assumption. Removing the error row merely to complete the refresh can turn a visible conversion problem into an omitted reconciliation record.

05

One file in a combined folder has a different structure

Power Query's Combine Files workflow uses an example transformation and applies the resulting logic across the files being combined. Previous files working does not establish that the newest file has the same structure. Compare a problematic file directly with a known-good file: names, headers, object names, format, delimiters, required fields, and expected value types.

06

The expected Excel object changed

Power Query may navigate to a specific worksheet, Excel table, or named object. A replacement workbook can look nearly identical to a person while the expected table has been renamed, removed, or replaced with a normal range. Visual similarity does not prove that the object Power Query expects still exists.

A USEFUL EXCLUSION

What usually isn't the problem: simple column ordering

Moving columns into a different visual order generally should not be treated like renaming or removing them. Power Query typically operates on column names rather than relying only on their positions.

transaction_id | date | amountamount | transaction_id | date

If a query reports that a column cannot be found, look first for the actual field name, header promotion, selected or removed fields, worksheet/table structure, value types, or transformations earlier in the query.

DIAGNOSIS

How to diagnose a sudden schema problem

  1. Find the first failing step. Move through Applied Steps and identify the first point where the query no longer produces the expected structure.
  2. Inspect the step immediately before it. Look at the table Power Query is actually passing into the failure: exact column names, headers, expected values, and selected worksheet or table.
  3. Compare a known-good source with the new source. Compare structure, not just visible values. Check expected and unexpected columns, header position, object identity, format, and data types.
  4. Understand the change before repairing it. A new field name or extra header row may be a legitimate upstream change. Establish what it means before making the query accommodate it.
  5. Repair the intended assumption and refresh again. Once the structural change is understood, update the query deliberately rather than changing several steps until the error disappears.

AFTER THE REPAIR

Repairing the query is not the same as verifying the reconciliation

Restoring a successful refresh shows that the configured transformations can execute against the changed source. It does not by itself establish that the resulting reconciliation still contains the expected records, relationships, amounts, or exceptions.

If a recurring reconciliation broke because its source changed, treat repair and verification as two separate steps.

The query refreshes again. Is the reconciliation actually right?See what refresh completion proves—and what it does not.Review the reconciliation after the repairUse the dedicated checklist for population, keys, unmatched records, amounts, structure, and review evidence.

RECONVERIFY

Validate the refreshed reconciliation after the structural repair

ReconVerify is a browser-local validator for existing recurring reconciliations. It currently checks blank and duplicate match keys, unmatched keys on either side, invalid mapped amount values, and amount differences beyond the tolerance you choose. It also reports source row counts and valid amount totals as review metrics.

ReconVerify does not currently inspect the Power Query M transformation chain or perform a complete source-schema audit. Supported reconciliation inputs are processed locally in the browser rather than sent to ReconVerify infrastructure.

Try ReconVerify

PRIMARY REFERENCES

Power Query behavior referenced in this guide

Microsoft documents common data-source and schema errors, header promotion, data-type behavior, and the example-file transformation model used when combining recurring files.

The reconciliation-verification recommendations are ReconVerify's control-oriented interpretation of those documented behaviors. They are not claims that Microsoft requires a particular reconciliation-review procedure.