What is stored, not what Excel would calculate next
When Excel calculates a cell that fails, it stores an error value and marks the cell with type e. This checker reads those stored values: #REF!, #VALUE!, #N/A, #DIV/0!, #NAME?, #NULL!, #NUM!, and newer codes such as #SPILL! and #CALC! when they are present. It lists counts and sample addresses. It does not recalculate the workbook, so it will not discover an error that appears only after a refresh you have not saved. If the file was saved after the last calculation, the stored errors are the ones Excel is showing.
How to tell the errors apart
#REF! means a reference was deleted or a sheet in the reference is gone. Cutting a column out from under a formula is the usual cause, and so is a broken external workbook. #VALUE! means a formula received the wrong kind of argument, such as text where a number was required. #N/A is what VLOOKUP and XLOOKUP return when the key is missing. It is sometimes intentional. #DIV/0! is division by a zero or a blank. #NAME? usually means a misspelled function or a name that is not defined. #SPILL! means a dynamic array could not write its result into empty cells.
The repair steps live in the guide on what those cached errors mean.
Where to look after the list
Start with #REF!, because those cells will not repair themselves when data comes back. The address list is capped for display, and the count is complete. If many #REF! cells sit on one sheet, that sheet lost a range. If #N/A is scattered through a lookup column, the lookup table or the key column changed. External links and broken defined names are the other two places #REF! hides when the cells themselves look untouched. This site’s link finder and name auditor cover those.
What the checker skips
It does not evaluate your formulas on a blank input and invent new errors. It does not follow precedent trees. Conditional formatting can display an error icon without a cached error value; that icon is not this report. On .xlsb files, cell records are binary and are not scanned. A green zero on a binary file means the check did not run. After you repair a cluster of #REF! cells, save and run the check again. The count should fall. If it does not, the remaining errors are on a sheet you have not edited, or they come back on calculation from a broken name.
Fixing without making a second mess
Save a copy. Correct one #REF! pattern, recalculate, and save. Then run this check again. Replacing every error with IFERROR too early hides the broken reference and makes the next audit worse. IFERROR is appropriate when a missing lookup is a normal outcome, and it is a bad idea when the formula points at a sheet that was renamed.