Formulas meet bad input: a divide-by-zero when a denominator is blank, a lookup that finds nothing, a text value where a number was expected. Left alone, these surface as Excel's error values (#DIV/0!, #N/A, #VALUE!, #REF!, #NAME?). One error cell poisons everything downstream, because a SUM that includes an error cell is itself an error. Error trapping is how you decide, deliberately, what should happen instead.
How do IFERROR and IFNA work?
IFERROR(value, value_if_error) evaluates its first argument. If that produces any error, it returns the second argument instead. Otherwise it returns the first argument's normal result. Take a conversion rate that must survive a zero-lead day. =IFERROR(deals/leads, 0) returns the ratio normally and 0 when leads is zero. IFERROR catches every error type without distinction, and that breadth is both its strength and its trap, as you'll see below.
IFNA(value, value_if_na) is the surgical version. It catches only #N/A and lets every other error through untouched. That makes it the right tool around a lookup. There, #N/A is the expected, meaningful signal that a lookup found no match, so you can translate it to "Not found". A #REF! or #VALUE! from the same formula signals a real bug, and you want to keep seeing it. =IFNA(XLOOKUP(A2, ids, names), "Unknown ID") says "no match is fine, show a friendly label; any other error, show me the error so I can fix it." Version note: IFNA needs Excel 2013+, and IFERROR needs 2007+.
Advertisement
Why is it risky to hide errors with IFERROR?
One habit separates a hobbyist from a professional. Wrapping a formula as IFERROR(complex_formula, ""), so that any error becomes an empty string, is one of the most dangerous habits in Excel. It looks tidy, and that's the problem. The exhibit is clean, with no red errors anywhere. But a broken reference (#REF! after someone deleted a column), a mistyped function name (#NAME?) and a genuine #VALUE! from bad data now all vanish into blank cells, identical to the legitimate "no data here" case. You've hidden the errors, which is different from handling them, and a hidden error in a model is a landmine.
Three rules keep you safe. (1) Prefer to fix the cause. A /0 usually means an input is missing, so guard the input itself. (2) If you must trap, catch narrowly. Use IFNA when the only expected error is a lookup miss, so real bugs still shout. (3) When you do use IFERROR, return something visible and specific, such as "CHECK INPUT", "n/a", or a 0 you've reasoned about. Never return a silent "" that makes a broken cell indistinguishable from an empty one.
An error you can see is a problem you can fix. An error you've hidden is a problem you've shipped.