Fix any spreadsheet error

A #REF! error means a formula is referring to a cell or range that no longer exists. The reference broke — usually because the cells it pointed to were deleted or moved out from under it.

A #DIV/0! error means a formula is trying to divide by zero — or by a cell that is empty, which the spreadsheet treats as zero. Division by zero has no answer, so the cell shows the error instead.

#N/A means "not available" — a lookup function searched for a value and found nothing that matched. It is the single most common error with VLOOKUP, XLOOKUP, and MATCH.

#VALUE! means a formula got the wrong kind of input — most often text where it expected a number. Spreadsheets cannot add a word to a number, so they flag the cell.

#NAME? means the spreadsheet does not recognize a name in the formula. It usually points at a misspelled function, a named range that does not exist, or text that is missing its quotation marks.

#NUM! means a formula tried to produce a number that is invalid or impossible to represent — like the square root of a negative number, or a value too large for the spreadsheet to hold.

#NULL! is an Excel-specific error caused by the intersection operator — a space between two references. It appears when you ask for the overlap of two ranges that do not actually intersect.

#SPILL! is a modern Excel error. A dynamic-array formula (like UNIQUE, FILTER, or SORT) needs to "spill" its results into the cells below or beside it, but something is in the way, so it cannot.

A circular reference happens when a formula depends on its own result — either directly (a cell refers to itself) or through a loop of cells that point back to the start. The spreadsheet cannot settle on an answer.

VLOOKUP returns #N/A when it cannot find the lookup value in the first column of your table range. The error means 'not available' — the match genuinely does not exist, or something is preventing the match from being recognised (a formatting difference, a hidden space, a number stored as text). No data is returned because no row was selected.

VLOOKUP found a row and returned a value, but it is not the value you expected. This happens when the formula is technically valid but one of its arguments is logically wrong — most often the wrong column index number, or approximate-match mode accidentally matching the wrong row in unsorted data.

When someone says VLOOKUP 'is not working', the formula is either returning an error (#N/A, #VALUE!, #REF!), returning a wrong result, or the cell is displaying the formula text instead of a result. Each symptom has a different root cause and requires a different fix.

XLOOKUP returns #N/A when the lookup value is not found in the lookup array and no if_not_found argument was provided. Unlike VLOOKUP, XLOOKUP supports a built-in not-found value, but if that argument is omitted and the match fails, the error propagates to the cell.

#SPILL! is an Excel-specific error that appears when a formula tries to output multiple values (a spill range) but one or more of the destination cells are not empty or are otherwise blocked. XLOOKUP returns #SPILL! when it is asked to return multiple columns or rows and the cells below or beside it are occupied.

INDEX MATCH returns #N/A when the MATCH part cannot find the lookup value in the match_array. MATCH returns #N/A, and INDEX then propagates that error to the cell. The lookup value either does not exist, does not match due to a type or spacing difference, or the arguments point to the wrong range.

When SUMIF returns 0, it usually means the criteria did not match any rows, so there was nothing to sum — but the formula is silently treating every comparison as false. This is different from an error: the formula runs successfully but finds no matches, or matches rows whose sum_range cells contain text numbers that do not add up.

SUMIF 'not working' covers several symptoms: returning 0 when a non-zero sum is expected, returning #VALUE!, returning the wrong number, or the formula showing as text. The root cause is almost always a criteria problem, a range mismatch, or a data-type inconsistency in the sum_range.

SUMIFS returns 0 when none of the rows satisfy all criteria simultaneously. Because SUMIFS applies AND logic — every criteria_range/criteria pair must match the same row — adding more conditions narrows the result, and a mismatch in any one condition causes the whole row to be excluded.

COUNTIF 'not working' usually means it returns 0 when matches are expected, returns a wrong count, or shows a #VALUE! error. The formula itself is rarely broken — the problem is almost always a mismatch between how data is stored and how the criteria is written.

When COUNTIF returns a count but the number is higher or lower than expected, the formula found matches — just the wrong ones. Over-counting is usually caused by wildcard patterns matching too broadly or duplicates in the range. Under-counting is usually caused by data-type mismatches or hidden characters preventing recognition of a cell.

When an IF formula is not working, it either returns the wrong branch (true when false is expected or vice versa), returns a #VALUE! error, or always returns the same branch regardless of the test value. The logical_test is the most common source of bugs — it evaluates to an unexpected TRUE or FALSE.

A nested IF chains multiple IF functions so that the value_if_false of one IF is another IF. When the result is wrong, the most common causes are conditions evaluated in the wrong order, overlapping condition boundaries returning the wrong branch, or unbalanced parentheses causing a parse error.

When CONCATENATE (or the & operator) is not working, the result is either an error, the values are joined without the expected separator, numbers are joined with wrong formatting (e.g. dates appearing as serial numbers), or the formula shows as text rather than computing.

When SUM returns 0 or an incorrect total, the most common cause is that the cells being summed contain numbers stored as text — they look like numbers but the SUM function treats them as zero. Other causes include a circular reference causing a 0 result, or calculation being set to manual so the formula is not updating.

When a cell is formatted as Text before you type a formula, the application stores the entry as a plain string rather than evaluating it. The formula appears exactly as typed — including the leading equals sign — and never computes a result.

Spreadsheet applications can run in Manual Calculation mode, which means formulas only recalculate when explicitly triggered. The cell shows a stale value — or even zero — because the engine has not re-evaluated the formula since the input data changed.

When you fill a formula down a column, relative references like A1 increment automatically to A2, A3, and so on. If a reference is fully locked with '$' signs or the fill does not behave as expected, the formula copies the same fixed values instead of adjusting to each row.

By default, cell references are relative — they adjust when copied. A '$' before the column letter locks the column; a '$' before the row number locks the row. If a reference changes unexpectedly when you copy a formula, the lock is missing or placed incorrectly.

A cell can contain the characters '123' but have those characters stored as a text string rather than a numeric value. SUM ignores text cells, VLOOKUP may fail to match, and sort order is alphabetical instead of numeric. A green triangle in the top-left corner of the cell is Excel's standard warning for this condition.

A cell can display '2024-01-15' or 'Jan 15 2024' but store those characters as plain text rather than as a date serial number. Formulas like DATEDIF, NETWORKDAYS, and date arithmetic fail or produce wrong results because the engine cannot perform math on a text string.

Spreadsheet applications store every date as an integer — the number of days since a fixed start date (January 0, 1900 in Excel; December 30, 1899 in Google Sheets). When a cell's format is set to General or Number, this underlying serial number is displayed instead of the formatted date.

Excel fills a cell with hash marks (####) when the column is too narrow to display the formatted value — most commonly a date, currency, or large number. No data is lost; the value is intact. Widening the column or reducing the number format makes the value visible again.

Excel places a small green triangle in the top-left corner of a cell when its background error checker detects a potential issue. The triangle is a warning, not an error — the cell may still compute correctly. Clicking the cell reveals a yellow diamond icon with options to inspect or dismiss the warning.

A lookup or comparison that should succeed silently fails when one or both values have leading or trailing whitespace. The characters '"Apple"' and '"Apple "' are different strings — the trailing space makes them unequal, so VLOOKUP returns #N/A and IF returns FALSE even though the values look identical on screen.

Standard lookup and comparison functions in both Excel and Google Sheets are case-insensitive — 'Apple', 'apple', and 'APPLE' are treated as identical. However, a few functions like EXACT() and FIND() are case-sensitive. If your data has inconsistent casing and you are using EXACT-based logic, a case mismatch can cause failures.

Spreadsheets store percentages as decimals internally — 25% is stored as 0.25. When you type '25' into a cell formatted as Percentage, the display shows '2500%' because 25 * 100 = 2500%. Confusion between the raw decimal and the formatted percentage is the root cause of most wrong-percentage calculations.

Computers represent decimal fractions in binary (base-2) floating-point, which cannot express most decimal fractions exactly. Values like 0.1 and 0.3 are stored as repeating binary fractions, so arithmetic on them produces tiny rounding residuals (e.g., 1.0000000000000002 instead of 1). These residuals are usually invisible but can break IF comparisons and make totals appear to not sum correctly.

Date arithmetic relies on serial numbers: subtracting two dates gives the number of days between them. Wrong results occur when one or both values are text strings masquerading as dates, when time-of-day components add fractional days, or when DATEDIF arguments are in the wrong order.

A formula that references an empty cell, or performs arithmetic that results in zero, will display 0 rather than leave the cell visually blank. Zero and blank are different values in spreadsheets — 0 is a number, blank is the absence of a value — and they behave differently in charts, counts, and formatting.

When a duplicate-detection formula returns no matches, the values look identical on screen but differ in the data the formula actually evaluates. Common culprits are leading or trailing spaces, inconsistent case sensitivity expectations, mixed data types (number vs. text), or a range reference that does not cover the full list.

A conditional formatting rule using a custom formula fires based on whether the formula returns TRUE or a non-zero value for each cell in the applied range. If the formula always returns FALSE, uses an absolute reference that does not shift per row, or contains a logical error, the formatting never applies even though the rule exists.

A custom data validation formula must return TRUE to allow the entry and FALSE to reject it. When the formula is misconfigured — wrong reference, unsupported function, or incorrect logic — it either blocks all entries, allows all entries, or shows no error indicator at all while silently accepting bad data.

#CALC! is an Excel-specific error returned by dynamic array functions when the calculation cannot complete — most commonly because the function is asked to return an empty array (no results), or because it encounters a logical impossibility such as intersecting empty sets. It signals a calculation boundary, not a syntax error.

#GETTING_DATA is a transient Excel status message, not a permanent error. It appears when a cell depends on data from an external source — Power Query, a data connection, a web query, or a linked workbook — that has not finished loading. The cell recalculates to a real value or error once the data arrives.

#FIELD! appears in Excel when you try to extract a field from a Linked Data Type — such as Stocks or Geography — and the field name does not exist for that record, the data type failed to resolve, or the cell has not been converted to a Linked Data Type yet. It is Excel-specific and does not appear in Google Sheets.

#BLOCKED! appears in Excel when a Linked Data Type field or an external data request is blocked — usually because the workbook's privacy level prevents it from sending data externally, or because an administrator policy restricts the feature. It is a permission error, not a formula syntax error.

#SPILL! occurs in Excel when a dynamic array formula cannot write its results into the spill range because one or more cells in that range are occupied — in this specific variant, because those cells are merged. Excel cannot write individual values into sub-cells of a merged group, so the spill is blocked entirely.

A parse error in Google Sheets means the formula engine failed to tokenize or interpret the formula before it could even begin calculating. Unlike #VALUE! (which is a runtime error), a parse error is a syntax error — a bracket is unclosed, a function name is misspelled, or a locale-specific separator is wrong.

In Google Sheets, when a formula returns multiple values — such as UNIQUE, FILTER, or an ARRAYFORMULA — it attempts to write each value into its own adjacent cell. If any of those destination cells are already occupied by data or another formula, Sheets cannot expand the array and shows the 'Array result was not expanded because it would overwrite data in ...' error.

When IMPORTRANGE is used for the first time between two Google Sheets files, Sheets requires explicit permission before it will read data from the source spreadsheet. Until that permission is granted, every cell using that IMPORTRANGE returns #REF! with the message 'You need to connect these sheets'. This is a one-time authorization step per source spreadsheet URL.

IMPORTRANGE pulls data from one Google Sheets file into another. When it stops working or returns an error, the cause is almost always one of three things: the source URL or range is wrong, access has not been authorized, or the source sheet name has changed. Identifying which one is failing tells you exactly what to fix.

The QUERY function in Google Sheets accepts a SQL-like string (based on Google's Visualization API query language). A parse error means Sheets could not interpret that string — a keyword is misspelled, column labels are used instead of Col1/Col2 references, or string literals are not delimited correctly. The error message usually specifies the position in the query string where parsing failed.

ARRAYFORMULA tells Google Sheets to evaluate a formula across an entire range rather than a single cell, writing results down the column automatically. When it produces only one result, returns an error, or expands into the wrong cells, the inner formula is usually not array-compatible, the ranges are different sizes, or there is an output collision with existing data.

Text to Columns (Excel) and SPLIT (Google Sheets) split cell content on a specified delimiter. When nothing splits, the detected delimiter does not match the actual separator in the data — often because the apparent delimiter is a non-breaking space, a different invisible character, or the data is already a number that cannot be split as text.