Fix a spreadsheet formula with AI

A VLOOKUP that returns #N/A at half past five on a Friday is a good reason to ask an AI chat for help, even if you do not consider yourself technical. The job is small and specific: something in a cell is wrong, and the reason is buried in brackets you half remember writing.

Two things before you start. We do not connect to your spreadsheet and we do not run code. What comes back is a formula in text, and you paste it into the cell yourself. That constraint carries an upside most AI tasks never give you: a formula either returns the number you expected or it does not, so you know within seconds whether it was any good.

Checkability is why a second opinion earns its thirty seconds here. When the first formula fails, ask a second model and paste that one instead; one of them usually works. Switch model in the same thread, or branch the conversation, which opens a new thread carrying the history with it. There is no side-by-side view, so you read one answer at a time.

First, what the model actually sees if you upload the file

This decides how you ask, so it comes first. You can attach the workbook on a Pro or Pro+ plan, spreadsheet uploads being outside the free plan, and what happens next surprises most people. We extract the workbook's text on our side and hand that text to the model. The extraction reads each cell's stored result. It never reads the formula bar.

So a spreadsheet arrives as answers rather than as the formulas that produced them. The thing you wanted looked at does not make the trip. Formatting makes it worse. Number and date formats live in a separate part of the file our extractor does not open, so a cell showing 1,250.00 EUR arrives as a bare 1250, and a date arrives as the five-digit serial number stored underneath. Ask about a column of delivery dates and the model is reading integers in the forty-six thousands.

Two better moves. Paste the formula and describe the columns in words: column A is a product code, columns B to D are last year's monthly totals, and the price list sits on a second sheet with the code in column A and the price in column C. Or screenshot the sheet, which keeps the formula bar, the error text, the currency symbols and the dates as you see them. Forty-six of the 59 models in MultiChats accept an image, 14 of them among the 22 on the free plan; a free account gets one attachment per message at up to 10MB, three a day.

Eight problems, and what to do with each

These are the ones people bring, laid out the same way each time: what to type, what comes back, what to check before it reaches a live sheet, and a verdict on how far to trust it.

You know the result you want and not the function

What you type. The sentence you would say to a colleague, plus the name of the app. Column C has order dates, column F has amounts, I want the August 2026 total in one cell, in Google Sheets. Ask for a one-line explanation too, so you can maintain it in six months.
What you get. A formula with the ranges inferred from your description, usually wrapped in more explanation than you wanted; the one-line request keeps that in check.
What to check. The ranges, against your actual columns. Invented ranges are the standard defect in an otherwise correct formula, and the easiest thing here to catch.
Verdict. The highest-yield question on the list. Right first time more often than not, and wrong somewhere visible when it is wrong.

A VLOOKUP that returns #N/A

What you type. The formula, the exact error, and one sentence on what sits in the lookup column and the table. Say whether the lookup values are text or numbers, because that is usually where this dies.
What you get. A set of possible causes rather than one fix, which is honest. Microsoft's own reference lists two distinct conditions behind a VLOOKUP #N/A, including a lookup value smaller than anything in the table's first column, and an exact-match search that found nothing (Microsoft, VLOOKUP function).
What to check. Whether the diagnosis fits your data before accepting the rewrite. A model handed nothing but the error often returns an IFERROR wrapper, which hides the error and leaves the cause in place. Ask why the lookup fails first.
Verdict. Put it to a second model. The cause is one of several, the first answer sometimes picks wrong, and two models naming the same cause is a strong signal.

A total that quietly ignores half the numbers

What you type. That your SUM returns zero, or a figure far too small, while the cells look like numbers. Mention it if the column came from a CSV, a bank export or a web page.
What you get. The text-in-the-shape-of-a-number diagnosis, plus a repair route: a VALUE conversion, a multiply-by-one trick, or a paste-special route through the menus. Some answers offer all three.
What to check. Which repair survives the next refresh of the source data. A formula holds; a one-off conversion on a column overwritten next month does not. Confirm the diagnosis yourself by putting =ISNUMBER(A2) beside the column and reading the FALSE values.
Verdict. Dependable. Most models recognise this from the symptom alone, and the check costs one cell.

Dates that refuse to sort

What you type. That the column sorts 1 February ahead of 31 January, the format you see on screen, and the region the spreadsheet is set to. The region is what people leave out.
What you get. Usually the verdict that the column holds text shaped like dates, then a conversion: often DATEVALUE, sometimes a split-and-rebuild of day, month and year.
What to check. Which order the model assumed. Day-month-year and month-day-year agree on the 3rd of February and disagree for most of the month, and a silent assumption here corrupts a column without raising one error.
Verdict. Ask twice, stating the region the second time. This is where a confident answer is most often confidently wrong.

Adding up on two conditions at once

What you type. Both conditions and the column you want totalled. Total column F where column B says Paid and column C is after 1 June.
What you get. SUMIFS, and with it a real trap: the argument order does not match SUMIF. Google's references give SUMIF(range, criterion, [sum_range]) against SUMIFS(sum_range, criteria_range1, criterion1, ...), so the range being added up moves from last to first (Google, SUMIF and SUMIFS).
What to check. That the first range is the one you meant to total. Carrying the older argument order into the newer function returns a number rather than an error, which is the expensive kind of wrong.
Verdict. Trust it, then check the first argument by eye. The failure is silent, which makes this the one entry where a plausible answer still deserves a second look.

A nested IF that has grown teeth

What you type. The formula, plus what it is meant to decide, one rule per line. Restating the rules as a list is most of the work, and often shows you the bug before the model answers.
What you get. Either a corrected nest or a proposal to replace it with IFS, a lookup table or SWITCH. Ask for whichever version will be easiest to change later.
What to check. The boundaries. Nested conditions break where two bands meet, so give the model three edge cases (exactly 1000, exactly zero, the last day of the month) and ask what it returns for each.
Verdict. Strong on structure, blind on intent. Nothing in the formula says whether your 5% band includes its upper bound, so you have to.

#REF! down a whole column after a deletion

What you type. That you deleted a column and these formulas now show #REF!. Paste one broken formula, plus the version from before it broke if you have it.
What you get. A rebuild with the references shifted along. Correct in shape, dependent on your description for the details, since the model cannot see what was in the gap.
What to check. One cell first, then the pattern. Repair a single formula, confirm it returns what the old one did, then fill down. Rebuilding 800 rows before checking one turns a small breakage into an afternoon.
Verdict. Mechanical and mostly reliable, with one caveat: if you are still in the same editing session, undo beats all of this.

A formula that works in Excel and breaks in Google Sheets

What you type. Which app you are in, first sentence, every time. If your copy of Excel separates arguments with semicolons rather than commas, say that too.
What you get. Unless told, answers come out Excel-shaped, because that is what most written material describes. Sometimes the function does not exist in the other app at all: ARRAYFORMULA has its own page in Google's function reference and appears nowhere in Microsoft's alphabetical list of Excel functions.
What to check. The function name against your own app's list before deciding the logic is wrong. A parse error on a function your app has never heard of is about dialect rather than your reasoning.
Verdict. Preventable. Name the app and this entry stops happening to you.

When the fixes keep failing

Three failed formulas is the signal to stop rewriting the formula and rewrite the question. By then the model is solving a problem your columns do not contain, because the description it was given did not match the sheet. Describe the data again, with two actual rows this time and the headers attached.

Which raises what spreadsheets are full of: salaries, client lists, bank exports, other people's addresses. We do not train on your conversations. What the provider behind a given model does with them varies by model, and the models where we know of a difference carry a notice on their info card in the picker. When a sheet holds someone else's personal data, retype two representative rows with names and figures changed, and ask about those.

Pick the model on fit. Reach for a reasoning model on a nested IF with six branches, where the difficulty sits in the logic rather than in recalling a function name; a fast general model handles the rest. Pro and Pro+ add the spreadsheet uploads described above, with the caveat that came with them: the workbook arrives as results, so the formula still gets pasted in by you.