Merged spreadsheet cells look tidy and behave badly as data

Merged cells are not always a mistake. A title centered over a report can make a sheet easier to read. The trouble starts when a visual layout device is asked to carry business meaning.

A spreadsheet can be both a report and a dataset, but those are different jobs. Reports use spacing, grouped headings, and visual hierarchy. Datasets need a dependable rectangle: one header row, one value per cell, and complete values on every row where they apply.

A merge says, “Make these cells look like one thing.” Data work depends on those cells remaining distinct positions in rows and columns. People can often infer the intended meaning. Sorting, filtering, exports, screen readers, and other tools cannot safely rely on inference.

The value that looks present but is not

Consider a sales list where “North Region” is vertically merged across five rows of accounts. On screen, the grouping seems clear. A reader understands that all five accounts belong to North Region.

But only one row actually contains that value. If the cells are unmerged, the remaining four rows are blank unless someone deliberately fills in the region. If the range is exported or reused elsewhere, those blank records do not carry the visual context that made the original sheet understandable.

The better layout repeats North Region in the Region column for each applicable account row. Repetition may look less elegant, but it makes every record self-contained.

That distinction matters when another person filters the sheet, imports it into a database, or receives a CSV file. A CSV preserves values and text, not workbook formatting. Excel documents that saving to a text format such as CSV removes formatting, so merged-cell layout cannot carry its meaning into the export.

Everyday spreadsheet work becomes harder

Sorting exposes the problem quickly. Microsoft’s guidance states that Excel does not sort data in a column containing merged cells. Google Sheets also advises users to check for merged cells and try unmerging them when they cannot create a filter.

Merged headers can cause a quieter version of the same problem. A report might place a merged “2026” above Jan, Feb, and Mar, with another merged band for Actual and Budget. That arrangement can work as a visual summary. It is awkward as a data table because the meaning of each column depends on a header above, beside, or across from it.

For data intended for analysis, each column needs its own complete name, such as actual_2026_01 and budget_2026_01. The labels are less decorative, but they remain understandable when copied, exported, or loaded into another tool.

Excel also disables the Merge command for cells formatted as an Excel table. That constraint points to the underlying mismatch: tables are designed around consistent rows and columns, while merges deliberately interrupt that structure.

There is also a direct risk when creating merges. Excel retains only one cell’s content when multiple cells are merged, deleting the contents of the others. In a left-to-right workbook, the retained content is the upper-left cell.

That does not mean every merged range has lost important information. It does mean that merging populated cells deserves care. Save a copy and verify the values before making layout changes. Unmerging later does not recreate content deleted at the time of the merge.

Accessibility is part of the issue

A spreadsheet does not have to be published publicly for accessibility to matter. Colleagues, clients, and future users may navigate it in different ways.

Microsoft warns that merged or split cells can cause screen readers to lose count of their place in a table. Navigation can become very difficult or impossible. A layout that depends on a sighted reader noticing a label spanning several rows is not a reliable table structure.

The flat-table approach helps here as well: use one unmerged header row, give every column a clear name, and keep the values needed to understand a record on that record’s row.

Keep presentation separate from source data

The practical fix is not to ban formatting. It is to separate presentation from the data that supports it.

Keep a source-data sheet flat and regular. If an account belongs to a region, write the region in each applicable account row. If a record needs a status, give it a Status field. If a value belongs to a parent entity rather than every child row, use a related parent table rather than visually implying the relationship with a vertical merge.

Then create a separate report, pivot table, dashboard, or presentation area for grouped headings and spacing. A monthly report title above the data range is generally low risk when it sits outside the table and will not be sorted, filtered, exported, or imported with the data.

For an Excel desktop report heading, Center Across Selection can provide a centered appearance without merging cells. It is a useful visual alternative, though availability varies by Excel version and platform. It also does not solve vertical grouping inside a dataset.

A quick cleanup test is useful: could this row be copied to a CSV and still explain itself without relying on neighboring cells? If not, the sheet is functioning as a report layout rather than dependable row-level data.

Before sharing or reusing a workbook, save a copy, find merged cells in the data range, unmerge them, restore values from a trusted source where needed, and establish one explicit header row. Then test a sort, a filter, and a CSV export.

Merges can make a report look orderly. Flat data makes the work built on that report more reliable.