Excel has a quiet bug, and it has been there long enough that users should be angry about it. A Reddit post this week documents a behavior in SUMIF, SUMIFS, COUNTIF, and COUNTIFS where text that looks like scientific notation, something like "10359E2", gets coerced into a number during evaluation. The result is that a search for a literal text string can match entirely different numeric values, and your totals come out wrong. The column can be formatted as Text. The data can look spotless. The bug still triggers on current versions of Excel 365. This is not a data-entry problem or a formatting oversight. It is a flaw in how Excel handles criteria matching, and it has been flying under the radar for years.
What this means in practical terms is that anyone working with part numbers, serial codes, lot identifiers, or any text field that happens to contain an "E" followed by digits is at risk of silent data corruption. You could be running a COUNTIF to check for duplicates and getting inflated counts. You could be summing a column based on a product code and pulling in values that have no business being summed. The dataset passes a visual check because the matching rows look correct when inspected individually. The bug only reveals itself when you cross-reference totals against a manual count or a different tool. For a user managing thousands of rows, that kind of cross-check is rarely done. The error becomes invisible, embedded in reports that people trust.
Microsoft has been aware of scientific-notation coercion in Excel for a long time. It is the same mechanism that turns a long numeric string into something like "1.23E+10" when you close and reopen a CSV. What is less widely documented is that this coercion also affects the IF-family functions during criteria evaluation. The Reddit user is right to ask for a documented warning or a fix. A function like COUNTIF should treat a text criterion as text, period. Converting it to a number and then matching against a mix of text and numeric representations creates a category error that spreads through any downstream analysis. It is the kind of bug that erodes trust in a tool that many professionals rely on as their primary data environment.
Our take is straightforward: this needs to be addressed as a correctness issue, not a niche edge case. If Excel cannot guarantee that a text criterion stays text inside a conditional aggregation function, then the tool is not reliable for a huge swath of real-world use cases. Until Microsoft documents the behavior or ships a fix, the only safe workaround is to add an explicit check, something like appending a non-numeric character to the criterion or using SUMPRODUCT with a double unary minus. That is a workaround, not a solution. Users should not have to build defensive logic around a function that is supposed to match what you give it. The burden should be on the software, not the analyst.