What AI can actually do with a spreadsheet
How to tell the difference between asking a model about a table, running code over one, and predicting a column you do not have yet.
on this page · 0 / 0 checked
The parts of your business that matter most are already in tables. The invoice ledger. The Stripe export. The timesheet CSV. The sheet where you track which clients pay in 40 days and which pay in 90. Almost all AI advice, though, is written about text: draft this email, summarise that document, tighten this page. So the first time you drag a spreadsheet into a chat window you are working without instructions, and the results are strange. Sometimes it finds a pattern in four seconds that you had missed for a year. Sometimes it hands you a total that is confidently, quietly wrong.
That happens because pointing AI at a table is not one activity. Three different mechanisms sit behind the same chat box, they fail in different ways, and most of the disappointment comes from using one where you needed another. This guide is about telling them apart, and about the one check that catches most of the damage. If you have a data warehouse and someone whose job title contains the word analyst, none of this is news to you. It is for the person whose analytics stack is a folder of exports and one spreadsheet with too many tabs.
Three machines are hiding behind one chat box
The first job is reading and reshaping. Joining two exports on email address, deduplicating a contact list, pivoting 18 months of invoices by client and month, finding the rows in one file that are missing from the other. This is ordinary data work, the answer is arithmetic, and it has to be computed rather than described.
The second job is generating something for each row. Reading 800 free-text support messages and tagging each with a category. Turning terse product codes into readable titles. Rating whether a review is a complaint or a question. Here the model is doing the thing it is genuinely good at, once per row, and the output is text a person can read and spot-check.
The third job is prediction: filling in a column you do not have yet. Which open invoices will go past 60 days. Which trial accounts convert. Which supplier slips next quarter. This is not a language problem at all, and a chat model asked to do it directly will produce a fluent answer with nothing underneath it.
The failure modes are what make the distinction worth keeping. Reshaping fails loudly, because broken code throws an error you can see. Labelling fails quietly and one row at a time, which is why you sample. Prediction fails as a number that looks entirely reasonable and is worth nothing until you compare it against the obvious guess you would have made anyway.
Numbers have to come out of code that ran on your file
When ChatGPT does data analysis it runs your file inside what OpenAI describes as “a stateful Jupyter notebook environment” [1]. Claude’s code execution tool has the same shape: Python 3.11 in a sandboxed Linux container, with pandas, numpy, scipy, scikit-learn and statsmodels available, plus openpyxl and pyarrow for reading the files themselves [2]. The valuable property in both cases is identical. The model writes code, the code runs against your actual rows, and the number in the answer is the number the code produced.
Both environments are cut off from the network. OpenAI states that “The Python environment used for data analysis cannot make external web requests or API calls” [1]. Anthropic’s documentation puts it as “Internet access: Completely disabled for security” [2]. Read that as a guarantee rather than a restriction. Nothing in the total came from a web page the model half-remembered.
So your check is visual and takes a second: did code appear. If you get a paragraph of prose containing a figure and you never saw a line of Python, the figure was written, not calculated, and it deserves no more trust than a guess. OpenAI’s own guidance is to “review the generated code, outputs, and assumptions before relying on the result”, and it warns that ChatGPT “may choose an analysis method or chart type that does not match your intent on the first try” [1]. That is the honest version of what these tools are: a fast analyst who does not ask clarifying questions.
One consequence is about file format rather than prompting. OpenAI notes that ChatGPT “may not reliably extract exact values from image-based tables, scanned files, or files with complex visual layouts” [1]. A screenshot of a table is an image, and reading numbers off an image is a different and worse operation than parsing a CSV. Export the file.
Upload limits decide the shape of the work before you start
The caps are lower than people expect, and they are lower for spreadsheets than for documents. ChatGPT applies “a hard limit of 512MB per file”, but for spreadsheets and CSVs the “file size cannot exceed approximately 50MB”, while text and document files are “capped at 2M tokens per file” [3]. Volume is capped too: users “can upload up to 80 files every 3 hours”, the free plan is “limited to 3 file uploads per day”, and each end user is “capped at 25GB” of storage [3]. Claude’s execution container gives you 5 GiB of RAM, 5 GiB of workspace disk and 1 CPU, billed at $0.05 per hour per container after 1,550 free hours per organisation per month [2].
None of that is generous enough to let you dump a five-year ledger and ask a vague question, and you should not want to. Sending fewer rows is better analysis, not a compromise. Cut the export to the columns the question actually needs, cut the date range to the period you are asking about, and aggregate anything you are not examining individually. A question about seasonality needs monthly totals, not 400,000 line items. Every row you leave out is a row the model cannot misread.
rows × columns × characters ÷ 1,000,000, an approximation. Compare the result against the spreadsheet upload cap on your plan. Computed in the page; nothing is sent anywhere.
A formula that calls a model is not a formula
The other way AI arrives in a spreadsheet is as a function in a cell. Google Sheets has one, written as AI("prompt", [optional range]), which will generate text, summarise, categorise, analyse sentiment, and access real-time information from Google Search [4]. It is genuinely useful for the second job above, the per-row labelling, and it is the wrong tool for the first.
The constraints tell you why. Only “the first 350 selected cells with AI functions will be generated” [4]. Responses “are limited to text” [4]. If the data feeding a prompt changes, “you don’t get a prompt to refresh the data”, so the cell keeps its old answer until you go and regenerate it [4]. And “You can’t undo or redo your function”, you can only regenerate the output [4]. The function also “doesn’t have access to your entire spreadsheet or other files in your Google Drive” [4], so it cannot reason about the whole workbook the way you might assume from the chat product of the same name. Google’s standing caution applies as well: Gemini features “may suggest inaccurate or inappropriate information” and should not be relied on “as medical, legal, financial or other professional advice” [4].
Put those together and the rule is clean. A model in a cell is for turning content into a label. It is not for turning numbers into other numbers. SUM is exact, recalculates when the inputs change, and costs nothing. A model’s opinion about a sum is none of those things, and once generated it sits there as static text that no longer knows its source data moved.
Predicting a column you do not have is a separate category of model
The third job has its own family of models, and they are not language models. Tabular foundation models are trained to make predictions on rows and columns directly. The relevant result was published in Nature in 2025: TabPFN, a model that “outperforms all previous methods on datasets with up to 10,000 samples by a wide margin” [5]. The headline number is not accuracy but time. “In 2.8 s, TabPFN outperforms an ensemble of the strongest baselines tuned for 4 h in a classification setting” [5], which is the part that matters for a small business, because four hours of tuning by someone who knows how to tune was never going to happen.
The current release has grown past those bounds. Prior Labs documents TabPFN-3 as supporting datasets up to 1,000,000 rows by 200 features, 100,000 by 2,000, or 1,000 by 20,000, with a GPU recommended and the default model capped at 5,000 samples when it runs on a CPU [6]. It handles classification, regression and missing values, and the guidance is to skip the preprocessing habits you might bring from older tools, such as scaling or one-hot encoding [6].
Two things follow for an operator. The first is that this does not live in a chat window. It is a Python library today, which means either someone on your side writes the fit-and-predict call from the project’s quick start, under ten lines including the import [6], or you wait for the capability to appear inside software you already run. The second is that the waiting is a reasonable strategy, because large vendors are funding exactly that. SAP announced on 17 July 2026 that it had “completed the acquisition of Prior Labs, the pioneer of Tabular Foundation Models (TFMs)” [7], saying the lab “will continue to operate as an independent entity, with SAP committing to investing more than €1 billion over the next four years to scale it into a globally leading frontier AI lab for the structured data that underpins the world’s businesses” [7]. Treat that as evidence about where the category is going, not as a reason to change anything this month.
The file you just uploaded is a customer list
Before any of this, look at what you are handing over. An invoice export contains names, email addresses, amounts and payment behaviour for real people and real companies, and the defaults for what happens to it differ by plan rather than by product. OpenAI states that for business users “By default, we do not train on any inputs or outputs from our products for business users”, while content from its individual services may be used for training unless you turn that off through the privacy portal [8]. That is one vendor’s arrangement, and it is the kind of setting that is worth confirming on your own account rather than assuming.
The stronger move is upstream of the setting. Most analytical questions do not need identity at all. Replace names and emails with a customer id before you export, keep the mapping in your own file, and join the answer back afterwards. Aggregating has the same effect for free: monthly revenue by segment carries no personal data. Fewer identifying columns also means fewer columns for the model to latch onto spuriously, so the privacy move and the accuracy move point in the same direction.
What still goes wrong
The cleaning decisions are invisible and they are where the errors live. Somewhere in that generated code, something decided how to parse a date column with two formats in it, whether a blank means zero or unknown, whether the text “N/A” became a missing value or a category, and which rows got dropped by a join that did not match. All of that runs without error and produces a clean-looking result. The only defence is to ask how many rows went in and how many came out, and to have the model say what it did with the ones that disappeared.
Per-row labelling degrades in a way that reviewing cannot catch at scale. You check 20 rows out of 800, they look right, and you ship a column where the other 780 are unverified. Sheets caps generation at the first 350 cells with AI functions [4], which is a limit and also an accidental warning about how much unchecked output one action can create. Decide in advance what error rate you can live with, and pick the job accordingly: fine for triaging your own inbox, not fine for anything a client sees as fact.
Prediction remains the hardest to evaluate and the easiest to be impressed by. The Nature paper is candid that memory usage “scales linearly with dataset size, which can be prohibitive for very large datasets” and that its evaluation “focused on datasets with up to 10,000 samples and 500 features; scalability to larger datasets requires further study” [5]. Even where the model fits comfortably, a prediction is only worth what it beats. Hold back the last three months, predict them, and compare the result against the rule you already use in your head. If the model cannot beat “clients who were late last quarter will be late again”, you have learned something useful and it cost you an afternoon.
- 01OpenAI Help — Data analysis with ChatGPThelp.openai.com
- 02Anthropic — Code execution toolplatform.claude.com
- 03OpenAI Help — File uploads FAQhelp.openai.com
- 04Google Docs Editors Help — Use the AI function in Google Sheetssupport.google.com
- 05Hollmann et al. — Accurate predictions on small data with a tabular foundation model (Nature)nature.com
- 06Prior Labs — TabPFN (GitHub)github.com
- 07SAP News — SAP Completes Prior Labs Acquisitionnews.sap.com
- 08OpenAI Help — How your data is used to improve model performancehelp.openai.com