--- title: "Messy Spreadsheets Aren't Bad Data. They're Business Data." description: "Merged headers, subtotal rows, three tables on one sheet, a column that is text in one month and numbers in the next. Data teams call it dirty. It is the shape business information actually takes, and the tools should meet it there." url: https://d2b.dev/blog/messy-spreadsheets-are-business-data language: en published: 2026-09-22 updated: 2026-09-22 publisher: D2B (600 Inc.) --- # Messy Spreadsheets Aren't Bad Data. They're Business Data. Merged headers, subtotal rows, three tables on one sheet, a column that is text in one month and numbers in the next. Data teams call it dirty. It is the shape business information actually takes, and the tools should meet it there. Every data team has a phrase for the files that arrive from the business: dirty data, messy data, unstructured data. The phrase carries a verdict. The file is wrong, and someone must fix it before real work can begin. Look at the file, though, and the verdict does not hold. Here is a typical one — inventory_2026-08_v3_FINAL.xlsx, sheet "Stock by warehouse": - A title row, then a blank row, then a header row that spans two lines because two cells are merged. - Three regions stacked on one sheet, each with its own subtotal row in bold. - A grand total at the bottom, and a note in red beside it: "excludes the returns depot". - A column, units_on_hand, that someone typed as text in one region and as numbers in the others. Nobody made this file carelessly. Somebody made it carefully, for a person to read on a Monday morning. Every one of those features is information. ## What the mess encodes | The "mess" | What it actually says | |---|---| | Merged header cells | These columns belong together; this is one measure across several periods | | Subtotal rows in bold | The data has groups, and here is where they end | | Three tables on one sheet | These things are compared side by side, by the people who use them | | A note in red | A known exception, written where a reader will see it | | Text in a numeric column | Someone hand-entered these values; treat them with more care | "Clean it first" deletes all of that. The subtotals go, the groups go, the note goes, and the person who knew what the red note meant is now doing data entry instead of their job. ## Business data is data made for people The files a data warehouse expects — one table per sheet, one header row, one type per column — are data made for machines. The files a business runs on are data made for people. Both are legitimate. Only one of them is the source of truth for how the business actually works, and it is not the tidy one. This is why the "clean your data" advice keeps failing in practice. It asks the wrong party to change. The people who make spreadsheets for people are not going to start making them for parsers. The tools have to meet the files where they are. ## Reading a file as it is Meeting the file where it is does not mean guessing. It means three concrete commitments: 1. **Keep the original.** The uploaded inventory_2026-08_v3_FINAL.xlsx stays as it is, byte for byte. Nothing is "fixed" in place. 2. **Structure a typed copy beside it.** From "Stock by warehouse", produce tables with named, typed columns: sku as an identifier, units_on_hand as a number, warehouse as a category. Subtotal rows are recognised as subtotals, not summed twice. 3. **Record how one became the other.** The structuring is itself a step with lineage, so any number in the typed table can be followed back to the cell it came from — including the hand-typed text values, and the rows the red note excludes. That last commitment is the one that separates "reading messy files" from "guessing at messy files". A tool that structures a file and cannot show what it did has just made a second, tidier mess. In D2B this is the default path: a spreadsheet made for people goes in as it is, lands as a faithful raw table and a structured typed table, and every later transformation carries its lineage. The structuring can be reviewed like any other step: ```text inventory_2026-08_v3_FINAL.xlsx → "Stock by warehouse" raw table (every cell, as uploaded) Stock by warehouse (typed) sku: id · warehouse: text · units_on_hand: number lineage typed row → raw cell, for every value ``` ## What changes when you stop calling it dirty When the messy file is the input rather than the obstacle, a few things follow: - The person who understands the file stays in their role. They review structure; they do not retype it. - Exceptions survive. The red note becomes a recorded rule ("exclude the returns depot"), not a thing someone forgets in month three. - Results go back in the form people use. The typed tables exist for the analysis; the Excel people open is still their Excel, values updated, formatting intact. Messy spreadsheets are not the problem to solve before analysis. They are the analysis's actual input, and the record of how a business thinks about its own numbers. The job is to read them faithfully, keep the original, and show the path — not to ask the business to write for machines. ## FAQ **What makes a spreadsheet 'messy' for analysis tools?** Anything that is easy for a person and hard for a parser: merged header cells, subtotal and total rows mixed into the data, several tables on one sheet, decorative rows, inconsistent spellings, and columns whose type changes from month to month. **Should I clean my spreadsheets before using AI on them?** Not as a rule. Cleaning by hand is slow, it discards the layout that carries meaning, and it produces a copy nobody else recognises. A tool should read the file as it is, keep the original, and show what it did to structure it. **How can an analysis stay trustworthy if the input file is messy?** By keeping two things: the untouched original, and a record of every step that turned it into typed tables. Then any number in the result can be followed back to the cell it came from, mess and all.