The symptom
You open the file. The monthly total says zero.
Nothing changed. It worked last week.
This is a common glitch, easy to miss, and the fix doesn't require becoming a formula expert.
The setup is always the same. You export payroll data as a CSV each period. A SUMIF or SUMIFS adds up wages by month.
Zero looks like a quiet month. That is why this failure hides for so long.
What is actually happening
When you open a CSV in Excel, date columns usually look right. They show 18/09/2026 or 18-Sep.
Underneath, they are often stored as text, not as real dates.
Excel's date functions need a real date, a number stored underneath, to do range comparisons. Your formula asks for anything in September 2026 and gets nothing, because it cannot compare a text string to a date range.
The giveaway is alignment. Real dates sit to the right of the cell, like numbers. Dates stored as text sit to the left, like words.
If your date column is left-aligned after opening the CSV, it is text.
Three ways to fix it
Option 1, paste-special multiply (a common workaround; check it on your version): In any empty cell, type the number 1 and copy it. Select your date column. Right-click → Paste Special → choose Multiply. This converts text dates only when their order matches your computer's regional settings. A US-order date such as 09/18/2026 will not convert on an Australian PC, and 09/10/2026 can silently become 9 October. After conversion, apply a Date format if Excel shows serial numbers such as 46283.
Option 2, Text to Columns: Select the date column. Go to Data → Text to Columns. Click Next twice without changing anything. On the last step, choose Date as the column data format and pick the order that matches your file. Check a known date in the export to be sure which order it uses. Click Finish. Nothing moves; the dates just become real.
Option 3, add a helper column: DATEVALUE on the criteria does not convert text dates in the source column. Add a helper column (column D here) and enter =DATEVALUE(A2) in D2, then fill it down. Point SUMIFS at that helper column. Use DATE to set the month boundaries: =SUMIFS(C:C,D:D,">="&DATE(2026,9,1),D:D,"<"&DATE(2026,10,1)). Here, column A holds the imported text dates, column C holds the amounts, and column D holds the converted dates. DATE(2026,9,1) means 1 September regardless of regional date settings. DATEVALUE still reads the text using your computer's date settings, so check one known date in column D.
Options 1 or 2 are better. Fix the data once so the formula never has to guess.
Making failure obvious
Any of these fixes will hold until something shifts. The CSV format changes, a new payroll provider writes dates differently, or someone runs the file on a machine with different regional settings.
Then the zero comes back, and nobody notices until month-end.
Add one check cell, and give it a conditional format that turns it red when it is not zero:
=SUMPRODUCT(--ISTEXT(A2:A5000))
Replace A2:A5000 with your actual date column range.
When this cell shows zero, every date in the column is a real date and your monthly totals are trustworthy.
When it shows anything else, the dates have come in as text again. The cell turns red, and whoever opens the file knows to stop before trusting any number.
Put it at the top of the sheet, not buried on a working tab. The rule is simple: red means fix before you read the totals.
The keep / clean / connect / convert read
This is a clean problem. The data is fine. The right amounts and the right dates are in the file, and they need one small step of cleaning before formulas can use them.
You don't need to buy anything, change payroll software or rebuild the report from scratch.
The fix takes about two minutes. The check cell takes two more. It is the part that stops you spending another afternoon looking for a quiet month that was never quiet.