How to Analyze a Spreadsheet Someone Else Built (Without Reverse-Engineering It)

Before you trust a number in an inherited workbook, you need three things. The first is which sheet is the real source. The second is which cells hold typed values rather than formulas. The third is where the file reaches outside itself. Everything else is detail.
Most people skip straight to the summary tab and start reading. That is how a hardcoded override from eleven months ago ends up in a board pack.
This guide covers why an inherited workbook resists reading, the three ways people try to decode one, and where each approach runs out.
Why a spreadsheet someone else built is hard to read
A workbook records decisions, not just data. The decisions are invisible, and the person who made them has usually left the team.
The hardest problem is that a cell displaying 48,200 gives no clue about its origin. It might be a formula, a pasted value, or a formula that somebody overtyped during a deadline. All three look identical.
Structure hides too. Sheets can be hidden, rows can be grouped and collapsed, and a named range can point somewhere entirely different from where its name suggests. External links to a file you do not have will keep displaying their last cached result without complaining.
Then there is the version problem. When a folder holds model_v3, model_final and model_final_USE_THIS, the file name is not evidence of anything.
What this costs you
A day before you can answer a question. The first request is usually simple, such as why a total changed. Answering it honestly means mapping the whole workbook first, because you cannot rule out an override you have not looked for.
Confidence you have not earned. The alternative to mapping is trusting the summary tab. That produces an answer quickly and gives you no way to defend it when someone pushes back.
A break that surfaces later. Edit a workbook you have not mapped and you can silently sever a dependency. The number still calculates, so nothing looks wrong until a reviewer notices the figure stopped moving.
The costs land hardest on whoever holds the file last. When a spreadsheet someone else built passes through three owners, each one adds a patch and none of them documents it.
The workarounds people try
Option 1: Separate the typed numbers from the calculated ones
Before reading any logic, find out which cells are inputs. ISFORMULA returns TRUE for any cell holding a formula, so a helper column across a sheet exposes the hardcoded values immediately.
Where you want to see the logic rather than just flag it, FORMULATEXT returns the formula as text. Laid out beside the values, it turns an opaque block into something readable.
This is the highest-value first step and it is genuinely fast. Its limit is coverage: you have to apply it sheet by sheet, and a large workbook has more sheets than patience.
Option 2: Trace the dependencies
Excel's Formula Auditing tools draw the relationships. Microsoft documents displaying the relationships between formulas and cells, where Trace Precedents shows what feeds a cell and Trace Dependents shows what it feeds.
The arrow colours carry information. Blue arrows indicate cells without errors, and red arrows point at cells causing errors. A black arrow to a worksheet icon means the reference lives on another sheet or in another workbook. That last one is how you discover an external dependency.
For a single dense formula, evaluating it one step at a time shows each intermediate result. It is slow and it is reliable.
The ceiling is arithmetic. Tracing is a per-cell operation, and a model with four hundred formulas is four hundred operations.
Option 3: Run a workbook-level inventory
Rather than reading cells, catalogue the file. List every sheet including hidden ones, every external link, every named range, and every place a formula pattern breaks partway down a column.
Microsoft documents an add-in for exactly this, Spreadsheet Inquire, which analyses workbook structure and relationships. Availability depends on your Office edition, so check the page before planning around it. Circular references deserve their own pass, and Microsoft covers finding and handling them separately.
An inventory is the most complete option and the most work. It also answers a different question from the one you were asked.
The shared ceiling. All three explain how the workbook computes. None tells you whether the numbers are right, and none of the work survives contact with version four.
How to analyze an inherited workbook with Powerdrill Bloom
Step 1: Upload the workbook
Upload the file as it arrived, without tidying it first. Powerdrill Bloom profiles every sheet on arrival. Sheet count, column types, blank blocks and inconsistent value types are visible before you read a single formula.
Step 2: Ask structural questions in natural language
Start with the map rather than the numbers. Ask which sheets look like raw inputs and which look like derived summaries, and where the same field appears with different values across sheets.
Then ask the trust question directly. Ask which columns break their own pattern partway down, and which totals fail to match the rows beneath them. Those two answers locate most overrides.
Step 3: Export the chart, report, or deck
Take out a structural summary of the workbook, or a chart from the sheet you decided to trust. A short written note recording what you verified also works.
Why this beats reading formulas cell by cell
| Manual route | Powerdrill Bloom | |
|---|---|---|
| Finding hardcoded values | Helper column per sheet | Ask which values break the pattern |
| Understanding relationships | Trace arrows, cell by cell | Ask which sheets feed which |
| Checking a total is real | Rebuild it manually | Ask whether it matches its rows |
| Version four arrives | Repeat everything | Upload the new file |
The last row is the one that changes behaviour. Mapping a workbook once is a reasonable afternoon. Mapping it again every time a colleague sends a revision is what makes people stop checking.
Common mistakes
Trusting the summary tab. It is the most edited sheet in any workbook and the most likely to contain a manual patch. Verify it against the detail before quoting it.
Editing before mapping. Changing a cell in a structure you have not understood can break a dependency silently. Map first, then edit.
Assuming consistent columns. A formula that runs cleanly for two hundred rows can be overtyped at row 201. Check the pattern down the whole column, not just at the top.
Ignoring hidden sheets. A hidden sheet often holds the lookup table everything depends on. Unhide everything before concluding the file is simple.
Treating file names as versions. A file called final is not evidence. Compare the actual numbers between candidate files before choosing one — our guide to analyzing multiple Excel files at once covers that comparison.
Rebuilding it from scratch. Tempting, and usually a mistake. A rebuild loses the undocumented rules the original encoded, and those rules are often the only reason the numbers reconciled.
Cleaning before understanding. Removing merged cells and blank rows makes the file easier to read and destroys evidence of how it was built. Take a copy first.
Conclusion
An inherited workbook is a reading problem before it is an analysis problem. Find the real source sheet, separate typed values from calculated ones, follow the references outward, and only then answer the question you were asked.
None of this is about distrusting the person who wrote it. A spreadsheet someone else built is a record of decisions made under deadline, and reading it carefully is the cost of using it.
What makes it expensive is doing it again for every revision. If that is where your week goes, try Powerdrill Bloom on the file exactly as you received it. See also our guides to analyzing Excel with AI and cleaning and deduplicating data, plus the Excel AI assistant and AI data cleaning pages.
Frequently asked questions
How do I find hardcoded values in a spreadsheet someone else built?
Add a helper column using ISFORMULA, which returns TRUE for formula cells and FALSE for typed ones. Every FALSE inside a calculated block is a manual override worth investigating.
How can I see the formula behind a cell as text?
Use FORMULATEXT in a neighbouring cell. It returns the formula as a readable string, which makes it possible to scan a column of logic without clicking through each cell.
How do I find out what a cell depends on?
Use Trace Precedents on the Formulas tab to see what feeds the cell, and Trace Dependents to see what it feeds. A black arrow to a worksheet icon means the reference sits outside the current sheet.
Should I clean an inherited workbook before analyzing it?
Not before mapping it. Cleaning removes evidence of how the file was built, including merged cells and blank blocks that mark structure. Keep an untouched copy either way.
What is the fastest way to check whether a total is trustworthy?
Rebuild it from the rows beneath it and compare. If the two disagree, the total contains an override, a filtered range, or a reference to a sheet you have not looked at yet.