Power Query used a transaction as the column headings

An import that suddenly creates a column named after a customer, invoice or date may have promoted a transaction row into the header. The missing record can then be difficult to notice because its values still appear somewhere on screen. Start by comparing the original file's first several rows with the query's columns and first surviving record.

Microsoft explains that Power Query analyzes unstructured inputs and may try to promote the first row when it detects a different pattern. That inference is not always correct. A headerless export, an added report title or a changed introductory section can expose the weakness of relying on the same inferred structure each period.

Preserve the raw file before troubleshooting. Record its source, report options, period and export version where available. Use a copy of the query for investigation if changing it would affect an issued report. The goal is to identify which row contains field names and which rows are business records before adjusting transformation steps.

Inspect the query at the point immediately before the header operation. Determine whether a genuine header row is present, whether introductory rows remain above it and whether an earlier connector step already supplied the correct column names. Promoting twice can turn the first data record into another set of headings even when the first promotion was appropriate.

The Table.PromoteHeaders function uses values from the first row as column names. Microsoft documents options governing which scalar values are converted and the culture used for conversion. Those options can affect the resulting labels, but they do not decide whether the first row is actually a header in the business file. That determination needs the export's documented structure and observed content.

Compare the first few records at each step instead of looking only at the final error. A later rename or type-conversion failure may merely be the first visible consequence. If a customer name replaced the expected Amount heading earlier, repairing a later reference to Amount without restoring the correct structure leaves the lost transaction unresolved.

A file with a single header row should produce those names once and retain every subsequent business record. A file with no header needs an agreed column definition rather than promotion of its first transaction. A report containing titles, dates or explanatory notes above the real header needs a controlled way to identify and remove that preamble before promotion.

Do not assume the real header always occupies the same row when export options can change. A new company-name line or warning message can shift it downward. Where the source format is variable, ask the system owner for a stable export or have the query validate the expected field names. An unexplained layout change should create a visible exception rather than a plausible new dataset.

Consider repeated headers inside a file separately. Some reports repeat field names after page breaks or between groups. Promoting the initial header will not remove those later rows. Identify them using an appropriate documented rule, and distinguish them from legitimate records whose text happens to resemble a field name. Keep the rejected-row evidence available for review.

Suppose an illustrative headerless file contains four payments: $125, $80, $60 and $35, totaling $300. If the first payment is consumed as column headings, only three payment rows totaling $175 remain in the data. The $125 difference identifies a real omitted record. Adding $125 to a report total would conceal the structural problem without restoring the transaction.

Repair the interpretation of the source and rerun from the preserved original. Confirm that the first payment appears with its identifier, date and amount in the correct columns. Then reconcile all four rows to $300. Inspect the last record as well, because fixing the first-row issue does not establish that every other filtering or truncation rule is correct.

Use a meaningful population control for the actual export. Where one payment has several detail lines, reconcile line count and payment identifiers separately. If the file includes several currencies, compare each currency rather than adding unlike amounts together. The check should demonstrate restored records on the same basis as the source, not merely a visually fuller table.

After correcting promotion, inspect renames, selected columns, type assignments and later joins. They may have been edited around the mistaken headings during previous troubleshooting. Restore their intended references using the approved schema. Avoid retaining a hard-coded customer name as a column reference simply because it happens to make one sample refresh.

Validate data types only after the columns have the right meaning. A date that became a heading may have encouraged a later step to treat another field as the transaction date. Check representative values against the original records, including blanks and unusual text. A technically successful conversion is not proof that the right field was converted.

Run the repaired query against more than the one failed file when those files represent known supported layouts. Include an ordinary export and the changed layout that caused the incident. Keep the comparison bounded to the formats the process accepts. The objective is a clear, maintainable input rule, not an importer that guesses its way through every unrelated report.

Document the accepted header arrangement, required field names and treatment of any introductory rows. Give the receiving team an example without sensitive business content. If the exporting system changes its layout, the team should know which owner can confirm the new structure before the data enters reporting or an accounting import.

Retain the original failed file, corrected query version and reconciliation within the authorized evidence location. Explain whether prior periods used the same faulty layout and require review. A durable repair preserves the first business record and makes the source's structure explicit, so a new customer name can never silently become the definition of a finance column.