The report breaks when the spreadsheet changes shape.

Last month's export had a column called Amount. This month's calls it Net amount. Nobody mentioned it, because nobody thought it was a change.

A client report breaks when the spreadsheet changes for one reason: the report remembers where a number sat, not what the number is, and nothing checks this month's file against last month's before the document is rebuilt.

There are only two ways to remember a column, and both fail. A position survives renaming and dies on reordering. A literal name dies the moment anyone edits a header.

Why a report breaks when a column name changes

This is not one product's bug. It is the same failure everywhere a document is bound to a sheet.

Smartsheet. Rename a column in the source sheet and reports and dashboards keep looking for the old name. They return blank.

SharePoint Online. Renaming a column does not update the formulas that reference it. Existing and new items return errors until every formula is edited by hand.

Power BI. A column rename in the dataset breaks the refresh and takes the dependent visuals with it.

Power Query. Saved steps reference columns by name or by index, so one unexpected change puts every step after it into an error state.

Search any of these and you land in a community forum, not an article. The question is asked constantly, on every platform, and no reporting vendor ranks for the answer. It is the same shape as the rest of client reporting automation: the pipeline is well served and the document is unowned. The closest the industry comes is a pitfalls list: Pointerpro notes that renaming a field silently breaks the flow, then moves to the next bullet.

Why binding by column position backfires

The advice in those threads is consistent: stop using column names. Bind by position, or rename every column to A, B, C on the way in and fix it downstream.

It works in the narrow sense. Renaming a header stops breaking anything, because the report has stopped asking what the column is called. It has also stopped asking what the column is.

Move a column two places left and every number in the document now reads from the wrong source. Nothing is blank. Nothing errors. The numbers are wrong and already on their way to the client.

That is the real trade, and it is rarely stated: position binding converts a loud failure into a silent one. A blank report gets caught before it is sent. A client report full of the wrong column's numbers does not, and a wrong number that reaches the client costs more than a broken one that never leaves.

How to prevent reports from breaking when a column is renamed

None of this requires changing tools. Four things help on the stack you already have.

Fix the shape at the source, not in the report. These breakages usually start upstream, with someone renaming a header because it read better. Agree what the columns are called with whoever produces the export and treat that list as an interface. A rename then becomes a conversation rather than a surprise.

Do the renaming once, at the boundary. If your tool lets you alias a column on import, alias it there and let everything downstream read your name for it. One place to update beats every formula that referenced it.

Check the header row before every refresh. Header detection is a guess in every tool that does it, and exports with a title or a period banner above the table are the common case. It is the highest-yield check on this list.

If you must bind by position, never reorder. Position binding is a real strategy with one condition attached, and the condition is usually broken by someone who does not know it exists. Write it down where the person maintaining the sheet will see it.

What none of these gives you is a report that tells you when something moved. That takes a step that compares the two files before rebuilding anything.

What a report should remember about a column

Both, and separately. A client report should remember a column by name and by position at once, and check the name first.

Rows are remembered as a rule rather than as a list of row numbers: all rows, the first N, or the last N. Next month's file has more rows and the rule still means the same thing. Ask for the last two rows and you have month over month. Ask for a twelve row window and you have year over year. One definition covers both.

The set of available calculations is deliberately closed. Percent change is not in it, because the first convenience function is how a configuration format turns into a formula language, and a formula language is no longer predictable.

The numbers written inside your sentences

A report is not only tiles and tables. Most of them carry sentences with numbers in them: revenue was X this month, up from Y, driven by Z.

Those numbers are usually typed. The tile updates when the data updates and the sentence does not, which is how a report ends up with correct figures above a paragraph describing last quarter.

A number written into a sentence should be bound exactly as a headline figure is, and read from the same place. Change the data and both move together. When a column drifts, both report it, because the sentence is not commentary sitting near the data, it is part of the same document reading the same source.

It is the difference between a document that reads its data and a document that quotes it.

What happens when the column headers change every month

Drop the new file in. Nothing is installed yet. A run plan is computed and held, and the preview switches to showing the file the plan is about rather than the data still loaded.

The run plan states four things:

• how many of the report's bound columns the new file still has under their old names
• how the row count changed
• which rows that were excluded last month are data again
• one decision for each bound column the file no longer has by name

Each decision offers two options: repoint the binding, or unbind it. Where a column is genuinely gone, unbinding is the only honest option, so it is stated rather than dressed up as a choice. Nothing is guessed on your behalf.

Then you press Run, or you cancel. Cancelling touches nothing.

What happens when a column is renamed, added, removed or reordered

Resolution runs in a fixed order. The remembered position is checked first, and used only if it still carries the remembered name. Failing that, the whole sheet is searched for the name, which is why a reordered column is a non-event, as long as that name is present and unique. Failing that, the remembered position is used as a fallback, and if the heading there is different the column is reported as renamed. Failing that, it is reported as missing.

An added column changes nothing for existing bindings, and a block set to read every column simply picks it up, because that instruction describes the sheet rather than a list of names.

Reconciliation costs 0.026 milliseconds on a 42 row file: matching the columns, inferring the rename, computing the row delta, building the decisions. Roughly a quarter of what reading the file costs. It is not a step anyone waits for.

The proportion is the part worth keeping. That report's configuration is 671 bytes. The month of data it renders is 2982 bytes. Next month the same 671 bytes read 48 rows instead of 42, unchanged. The durable thing is the description of the client report, and it is a fraction of the size of a single month's data, which is why we started at the document rather than the pipeline.

A worked example, January to February

The read comes first, and skipping it invalidates everything after it. Plenty of exports open with a banner block: period, basis, currency, each on its own line above the real table. Header detection takes that banner for the column names.

In the preview you set the real header row, and the columns become what they actually are.

With the read corrected, February against January reports three of the four bound columns found by name. One is not: Amount is reported as renamed to Net amount, noting that two bindings read that column. Rows moved from 42 to 48.

Repoint the one column, press Run, and the document is this month's.

What this does not fix

Renames are inferred from position, and nothing else. No value comparison, no type comparison, no similarity between the old name and the new one. Name lookup fails, position fallback succeeds, heading differs, that is a rename. A file that renames a column and reorders it in the same month reports the column as missing instead.

A wrong read produces a confident and wrong reconciliation. An export whose banner line was taken for the header will report renames that are not renames, in the same even sentences it uses when it is right. Reading the file and binding the document are separate stages on purpose, and the first one is still where a person has to look. The preview marks what was detected and invites the correction. It does not flag low confidence, because it has no notion of confidence.

Type changes are not part of this. A number arriving as text is a reading problem, fixed in the preview, and the run plan never sees it. Separation of concerns, not coverage.

It tells you, it does not stop you. Every block carries its status and drift is named in plain words, but nothing prevents exporting a report with marks still outstanding.

The marks are yours, not the client's. A block reading a renamed column renders exactly as a clean one does, and the exported PDF carries no trace of the reconciliation. That is deliberate: the document belongs to the client, the audit trail belongs to whoever produced it.

The timings above are a 42 row file. Reading and planning both touch every row. Fifty thousand rows has not been measured, and we are not going to guess at it.