From spreadsheet process to AI-assisted service.

The reliable way to turn a spreadsheet process into an AI-assisted service is to automate the manual work around the sheet first, and to give AI only the jobs that involve reading, sorting or writing language. Calculations of record, approvals and anything an auditor may need to reproduce stay in ordinary code that gives the same answer every time. Done in that order, the process keeps running throughout, and the sheet can stay as the view your team already knows.

Somewhere in most companies there is a spreadsheet that runs something important. It has been maintained for years, one person understands all of it, and every proposal to replace it has stalled. The instinct is to treat it as technical debt, but it is better read as documentation: the clearest description of how the process actually works that the business has.

The spreadsheet is the specification

A spreadsheet that has survived years of use has been debugged by reality. Its formulas encode pricing rules, approval thresholds, regional exceptions and seasonal adjustments that exist in no policy document anyone can produce. The nested conditional that nobody dares touch often turns out to be a contract term or a regulatory requirement that someone added for a good reason and never wrote down anywhere else.

That is why replacements fail. A team gathers requirements in meetings, builds a clean system, and discovers in the first month that it does not handle a dozen situations the sheet handled silently. The knowledge was never in the meetings. It was in column P.

The same applies to AI. A model given a vague description of the process fills the gaps with plausible guesses, so the rules need to be on paper before anyone writes a prompt.

How do you read a spreadsheet before automating it?

Read the formulas before you interview anyone, then interview people about the formulas. Work through the sheet in the order the data flows and note everything that is not obvious.

• Hardcoded values. A 0.92 inside a formula or a date typed into a condition. Each one is a decision someone made.
• Conditional logic. Every branch of a nested IF is a business rule, and the order of the branches often matters.
• Manual overrides. Formulas typed over with plain values. These are exceptions the process relies on that nobody has listed.
• Hidden tabs, columns and colour. Hidden ranges often hold lookup tables, and a yellow cell may mean something specific to whoever shaded it.
• Macros and scripts. Anything that runs from a button or when the file opens is part of the process.

Then ask the people who use the sheet about each item, and you get the history, the exception and the person who owns it. The result is a written list of rules, each with its source cell and a named owner, which becomes the test cases for everything that follows.

Where does the real cost of a spreadsheet process sit?

The real cost sits in the manual work around the spreadsheet, not in the calculation inside it. The sheet itself is rarely the bottleneck.

Follow a typical cycle. Someone exports a report each morning and pastes it into a tab, then fixes the date format because the export uses one convention and the sheet another. Someone reconciles the rows that did not match, emails the result to four people, and copies the approved figures into a third system by hand.

The calculation in the middle takes milliseconds. The copying takes people's time every day, and it is where errors come from, because retyping data between systems is the least reliable step in any process. It is also where the unstructured input arrives: supplier emails, scanned forms and free-text notes that someone has to interpret.

Time the steps before designing anything

Sit with the person who runs the process for a normal cycle, and for a month end or quarter end if there is one, because peaks are where exceptions show up. Record every step, how long it takes, how often it happens, who does it and what goes wrong, including time spent waiting for files that arrive late.

As an illustrative example with round numbers, not a result from any real project: six manual steps of ten minutes each, run every working day, come to an hour a day and roughly twenty hours a month, before counting the time spent finding and fixing mistakes. In projects like these, the arithmetic is a small part of the total and the transport is most of it.

That measurement changes the plan. It says to automate the movement of data before touching the logic, and it shows which steps involve reading or interpreting text, which is where AI can earn its place.

Can AI automate a spreadsheet process?

AI can automate the parts of a spreadsheet process that involve reading, interpreting or writing language, but it should not automate the parts that must produce an exact, repeatable number. Most processes contain both, so the useful question is which steps suit AI.

Here AI usually means a large language model: software trained on large amounts of text that reads an input and generates a response, which makes it good with messy inputs and wording. Deterministic code is ordinary software that follows written rules and returns the same output for the same input every time. A good service uses each for what it does well.

Reading emails, PDFs and notes into rows

The most valuable AI step in many spreadsheet processes is turning unstructured input into structured rows. Today a person reads each supplier email, scanned form or site note and types the relevant values into the sheet. A model can read the same input and return those values in a fixed structure, such as supplier, date, quantity and reference, ready to be checked.

Many model providers can return data in a defined format, which stops the output drifting into prose, but a well-formed answer can still contain a wrong value. Every extracted row goes through the same validation as any other input. Scans bring their own problems, covered in document extraction that survives a bad scan.

Classifying and tagging entries

A model can assign each row to a category from a fixed list: an expense description to a cost code, a request to a team, a free-text supplier name to a supplier record. Give it the allowed labels plus an explicit unclear option, so it has a sanctioned way to say it does not know.

Where a label must match a real record, let the model suggest and let code confirm. A suggested supplier missing from the master list is rejected automatically, and a person picks the right one.

Flagging unusual rows for a person to check

Experienced staff notice rows that look wrong before they can say why. Part of that instinct can be written as rules: a value outside a plausible range, a duplicate reference, a blank required field. Those rules should run every time, with no AI involved.

The rest is harder to write down, and this is where a model helps. It can notice that a note says the goods came back while the row is marked as a sale, or that a description does not fit its category. The flag goes to a person with a short reason, and it never changes the data by itself.

Drafting summaries and status updates

Many spreadsheet processes end with someone writing an email: the weekly position, the exceptions list, the note to an account manager. A model can draft it. Have the model write the wording around placeholders and let code fill in the figures from the calculated data, so the numbers never pass through the model, and have a person read the draft before it goes out.

Answering plain-language questions about the data

People often want to ask the data a question without building a pivot table, such as which orders from the north region are late this week. A model can turn the question into a query, ordinary code runs it against the data, and the answer comes back with the query shown so anyone can check what was counted. Give this feature read-only access, and never paste rows into a model and ask it to add them up.

Where should AI not be used in a spreadsheet process?

AI should not be used for calculations of record, for approvals, or for any step that must give exactly the same result every time and be explainable to an auditor. Those steps stay in deterministic code or with a named person.

Why a language model must not do the arithmetic

A language model does not calculate the way a formula does. It generates text piece by piece, predicting what should come next, and a number is just more text to it. On long columns or multi-step sums it can return a figure that looks right and is wrong, with no warning.

Repeatability is the second problem. A model's output can vary between runs even with the same input, and a hosted model may be updated by its provider. A figure of record must be reproducible months later, line by line, and a formula or function in code does that by design and can be tested against known answers.

Some AI systems let a model call a calculator or run code to get a number. That works, and it proves the point: the calculation of record is the code, not the model, so design for that openly.

Let the model read and write words, and let code do the sums that go on the record.

Approvals and decisions with consequences

Approving a payment, releasing stock or accepting a credit application needs someone accountable. Where the rule is clear, such as sign-off for anything over a set amount, write it as a rule. Where judgement is needed, a named person decides, and AI can prepare the pack that person reads, with the relevant rows, flags and a short summary.

What should you replace first?

Replace the ingestion first, then validation, then the AI-assisted steps with human review, then distribution, and move the calculation logic last, if at all. Each stage ships on its own, and the process keeps working throughout.

Ingestion first

Pull source data directly through an API (the interface a system offers so other software can request its data) or a scheduled export, so nobody downloads and pastes it. Normalise dates, currencies and codes on the way in. In many processes this alone removes much of the daily copying without touching the logic, and it is data integration work that needs no AI.

Validation next

Encode the checks the experienced person does by eye: totals that should reconcile, rows that should not be blank, values outside a plausible range, references that should exist elsewhere. As code, they run every time, whether or not anyone is paying attention. Validation comes before AI because it is what catches a model's mistakes.

AI-assisted steps with human review

Now add the language work: extraction, classification, flagging and drafting. Start in shadow mode, where the model produces its output while people carry on doing the job by hand, so the two can be compared on real inputs. When a step goes live, its output passes through validation and a review queue before it reaches the record.

Distribution after that

Results go automatically into the downstream system through its interface, so nobody retypes figures from an email. Where people still need a notification, send a link to the source figures so there is only ever one version.

The calculation logic last, if at all

By now the process is instrumented, the rules are written down and tests run every cycle, so moving the calculation out of the sheet is a contained change. Sometimes the right answer is to leave it, because formulas that are correct, understood and tested may not be worth moving.

How do you keep AI steps under human review?

Route every AI output through automatic checks, send anything that fails or looks uncertain to a person, and record what that person decided. Plan the review step from the first day, before the first error forces it.

What confidence signals can you trust?

The signals worth trusting are checks you control, because a model's own statement of its confidence is not reliable by itself. The extracted total should equal the sum of the lines, the supplier should exist in the master list, and the date should fall in a plausible range. An item that passes every check can go through, and one that fails goes to the review queue with the failing check attached.

Start with a person reviewing every AI output. As measured accuracy for a type of input holds steady, reduce review for that type, but keep a sample under review permanently so a change in the inputs gets noticed. Our guide to escalation paths for AI agents covers when work should pass to a person in more depth.

What a good review queue looks like

The reviewer should see the source beside the proposed row: the email, or the region of the page the value came from. Accepting should take one action and correcting very few. Store every correction, because corrections are the best test data a project will get.

Keep a set of real past inputs with known correct answers, and rerun it whenever a prompt, model or rule changes. Because model output varies, this needs different habits from testing ordinary code, explained in testing systems whose output varies.

Keeping the sheet as an interface

The spreadsheet often deserves to stay, as an interface over the service. The people who run these processes are fast in a spreadsheet: they sort, filter, spot the odd row and annotate it faster than in most tools a project could build on a sensible budget. Replacing the sheet with a web form is frequently a downgrade dressed up as modernisation.

service:  ingest -> extract -> validate -> calculate -> publish
sheet:    a live view of the results, still sortable
ai:       suggestions in their own columns, accepted by a person
edits:    written back through the service, validated and logged

The service owns the data, the rules and the audit trail, and the sheet becomes a view onto it that nobody has to be retrained to use. The knowledge that lived in one person's head now lives in code that can be read, tested and handed over.

How do edits in the sheet get back into the service?

Edits reach the service through a defined write-back path: people change only the columns marked as editable, and the service picks up those changes, validates them like any other input and logs them. Computed columns are locked so nobody can type over a total. The online versions of Excel and Google Sheets both offer programming interfaces for reading and writing cells, and both can protect cells from editing.

An edit that fails validation is never silently dropped. It is marked in the sheet with the reason so its author can fix it. AI suggestions sit in their own labelled columns, and accepting one is itself a logged edit, so nothing in the sheet bypasses the rules.

Permissions and the audit trail

Moving a process out of a shared file is a chance to fix who can change what. In the sheet, anyone with edit access can change any cell. In the service, the system enforces permissions: the team edits notes and categories, a named owner changes rules, and only the approval step marks an item approved.

The audit trail should answer one question for any figure: how did this value get here? Each change records who or what made it, when, the old and new values, and the source, whether an import, a person, a rule or an accepted AI suggestion. AI steps need a little more.

• The input the model received, or a reference to it.
• Its output, before any correction.
• The version of the prompt and model settings used.
• The checks the output passed or failed.
• The reviewer's decision and any change made.

Give the AI component the least access it needs: it reads its inputs and writes suggestions, but cannot write to the record or approve anything. Before sending business data to any model provider, check where it is processed, how long it is kept and whether it is used for training, against your own data policy.

Why run the old and new process side by side?

Running both side by side is the most reliable way to find the rules nobody wrote down, and it removes the need for a risky cutover weekend. For a period, the sheet does the job as it always has while the new service processes the same inputs and produces its own results.

Compare the two every cycle. Each difference is a bug in the service, an undocumented rule in the sheet, or an error the sheet has been making all along, and the last kind goes to the process owner before anyone decides which result is right.

Cover the cycles where exceptions cluster, such as a month end or a seasonal peak. AI steps get the same treatment: the model extracts and classifies while people carry on typing, so you learn its real accuracy on your own inputs before anyone depends on it.

Switch over one stage at a time, keeping the old route available until the owner trusts the new one. There is no cutover weekend, and no month where the business runs on something nobody trusts yet.

Common mistakes when adding AI to a spreadsheet process

The same mistakes come up repeatedly, and most are easy to avoid once named. Several overlap with the reasons AI pilots stall before production: the demo ran on tidy data, and nobody planned for real inputs or for the people who own the process.

A practical rollout plan

This is the sequence we follow for a single process. Each step is useful on its own, so the work can pause between steps without leaving anything half-built.

1. Choose one process and name its owner. Pick one with visible manual effort and a willing owner; the most complex sheet in the business can wait.
2. Map the sheet. List formulas, hardcoded values, overrides and hidden logic, and write the rules down with their source cells.
3. Time the manual steps. Cover a normal cycle and a period end, recording effort, frequency and errors.
4. Assign each step. Label it rules, AI with review, or a person, using the task table above.
5. Automate ingestion and validation. Run them alongside the existing process and compare results every cycle.
6. Add AI steps in shadow mode. Build a test set from real past inputs and measure accuracy before going live.
7. Go live with review. Route AI output through checks and a review queue, reducing review only where measured results support it.
8. Automate distribution. Deliver results straight into downstream systems.
9. Connect the sheet as an interface. Lock computed columns, enable write-back for editable ones and log every change.
10. Decide on the logic. Move the calculation into code only if it earns its place, with a parallel run through full cycles.

Key takeaways

• The spreadsheet is the specification, so read its formulas before interviewing anyone.
• The real cost is the manual work around the sheet, so time every step before designing anything.
• Use AI to read unstructured inputs, classify rows, flag oddities, draft updates and answer questions.
• Keep calculations of record, approvals and anything auditable in deterministic code or with a named person.
• Replace ingestion first, then validation, AI-assisted steps with review and distribution, and the logic last if at all.
• Judge AI output with checks you control, and log every review decision.
• Keep the sheet as a live interface, with edits written back through the service and logged.
• Run the old and new process side by side and switch over one stage at a time.

Where to start

Start with the sheet itself. Pick the process that costs your team the most manual effort, ask its owner to walk you through the formulas, and time one full cycle of the work around it. You will then know which steps are transport, which involve reading or writing language, and which are calculations that must stay exact.

That picture is usually enough to choose the first stage, and in most cases it points to ingestion. The real goal is to stop the process depending on the one person who understands the sheet, and to free that person to work on the exceptions.

If you would like a second view on your own process, schedule a call. Reading the sheet, automating the transport around it and adding AI only where it holds up under review is the core of our workflow automation work.

Frequently asked questions

Is AI accurate enough to do spreadsheet calculations?

Not for figures of record. A language model can produce a number that looks right and is wrong, and its output can vary between runs, so it cannot promise the same result twice. Keep calculations in formulas or ordinary code, which give identical results every time and can be tested. AI is better used to read inputs, tag rows and draft the wording around figures that code has already calculated.

Should we replace our spreadsheet with a custom web app?

Often not straight away, and sometimes not at all. The people who run the process are usually fast in a spreadsheet, and a web form can slow them down. A common approach is to move the data, rules and audit trail into a service and keep the sheet as a live view over it, with edits written back and logged. A custom interface makes sense when the sheet genuinely cannot show what people need.

How long does it take to automate a spreadsheet process with AI?

It depends on the process, the systems involved and the state of the inputs, so an honest estimate starts with reading the sheet and timing the manual steps. The staged approach helps: ingestion and validation can go live and start reducing manual work before the AI steps are built, and each later stage ships on its own, so value arrives in stages over the life of the project.

What happens when the AI gets a row wrong?

A well-designed service is built so that mistakes are caught before they reach the record. AI output goes through automatic checks, such as totals that must reconcile and references that must exist, and anything that fails or looks uncertain goes to a person. The model writes suggestions, never the record itself, and every correction is logged. Corrections then become test cases, so a repeat of the same mistake is spotted.

Is it safe to send spreadsheet data to an AI model?

It can be, if you check the terms and limit what you send. Before using any model provider, confirm where data is processed, how long it is kept and whether it is used for training, and compare that with your own data policy and contracts. Send only the columns a task needs, remove personal details the task does not require, and keep a log of what was sent and why.

Do we need clean data before adding AI to the process?

No, but you do need validation in place first. Messy inputs such as emails, scans and free-text notes are exactly where a language model helps most. What matters is that every extracted or classified row passes through the same checks as any other input, so errors are caught and routed to a person. Build ingestion and validation first, then add the AI steps on top of them.

What happens to the person who maintains the spreadsheet?

They are central to the project, because their knowledge is the specification. They help turn the formulas into written rules and tests, and they are the natural owner for approving rule changes later. Once the copying and retyping are automated, their time can go on reviewing exceptions and improving the process. The aim is to stop the process depending on one person's memory, while keeping that person's judgement where it matters.

Schedule a call