The spreadsheet is not the problem. It is the evidence.
Your team runs Dynamics 365 from Excel because the ERP records decisions it never computed. The shadow file is the most accurate map you have of where your system of record runs out.
The useful question is not how to stop it. It is which of them are worth replacing.
What the file is actually doing
Dynamics holds
The number, and the movements behind it.
The spreadsheet adds
The judgement that produced the number.
Which is why it survives
It is the fastest tool for the missing part.
Safety stock, rebuilt every cycle
Demand variability the ERP never derives.
Discounts decided by rule of thumb
Trade agreements hold the list, not the call.
Quote lines re-typed from email
Matching is the part nobody solved.
The spreadsheet is not the problem. It is the evidence.
“Eliminate the spreadsheet” is the standard advice, and it does not survive contact with the person reading it, who already knows the spreadsheet is faster. Being told to stop does not explain why it exists.
It exists because somewhere in the process a decision has to be made that the ERP will happily record and was never built to derive. The reorder point. The discount. Which quote line refers to which item. The system stores the answer; somebody still has to produce it, and they produce it in the fastest tool they have.
Which makes the shadow file the most useful diagnostic an operations team owns. It marks the gap in the users' own handwriting, and it is usually more honest than the process documentation.
Read it this way
Every recurring spreadsheet is a decision your ERP does not compute, annotated by the person who has to make it anyway.
That is worth auditing before it is worth eliminating. The file tells you what to build, in what order, and for whom.
What the ERP holds, and what the file adds
In every one of these the ERP is not wrong and not missing data. It is holding the record faithfully while the judgement happens somewhere else.
| The decision | What Dynamics holds | What the spreadsheet adds |
|---|---|---|
| Safety stock and reorder point | The number, and the movements behind it | The judgement that produced the number — demand variability, supplier reliability, what happened last winter |
| Price and discount | Trade agreements and price lists | Whether this customer, on this order, should get this discount at all |
| A quote from a customer request | The catalogue, and the finished quote | The matching — which line refers to which item, and which lines a human should look at |
| Pick sequence and slotting | Bins, zones and the pick list | Where stock should live so the walk is shorter next week |
| Month-end reporting | Every transaction, correctly | The shape somebody actually needs to read it in |
The right-hand column is the decision layer. It exists already — it is just running on a laptop, owned by one person, with no version history and no way for the ERP to see it.
Which spreadsheets are worth replacing?
Most are not, and two of the six verdicts below send you somewhere cheaper than us. That is not modesty — building on the wrong file is how a project fails slowly.
It computes a decision, and it recurs
Safety stock rebuilt every planning cycle. A discount worked out per quote. A forecast reconciled every month. The logic is stable enough to state, it runs often enough to pay, and the person doing it is not enjoying it.
The same file exists in four versions
When a spreadsheet has been copied per user, per region or per month, the disagreement between the copies is already costing more than the original problem.
It is a scratchpad for a one-off
A model built to answer a question nobody will ask again is a spreadsheet doing exactly what spreadsheets are good at. Replacing it spends money to make a fast thing slower.
It is faster and the stakes are low
Order-entry users pasting rows because the grid is quicker are not misbehaving. If the data lands correctly and nothing downstream depends on how it got there, the workaround is the right tool.
It exists to correct the ERP
A spreadsheet maintained because item masters are wrong or lead times are stale is a symptom of a data problem. Building an agent on top of that inherits the same bad inputs and hides them behind a confident answer.
It only reshapes what is already there
If the file is a pivot of data the ERP already holds correctly, the answer is a report, not a decision layer. Cheaper, faster, and it does not need us.
The calculation moves; the ERP does not
The logic that was in the file gets built where it can be versioned, tested and explained — outside the ERP, reading through documented integration points, writing back only what it created. No fields are added to your tables. Anything that moves money or stock is proposed and prepared, and a person approves it.
The planner's job does not disappear; it starts further along. The analysis arrives done with its reasoning attached, and the work becomes judging it. The people who were best at the spreadsheet get the most out of this, because they are the only ones who can tell when the recommendation is wrong.
The decisions, written up
- Safety stock and reorder points
- Price and discount decisions
- Pick path and slotting
- Turning a request into a quote
- How line-item matching works
- When a quote line matches nothing
What gets added to your estate, and what happens if you remove it: AI without lock-in.
What planners and controllers ask
Why do teams keep using Excel when they have an ERP?
Because the ERP records decisions rather than deriving them, and the spreadsheet is where the deriving happens. Master planning calculates from parameters somebody typed; the spreadsheet is where those parameters get argued about. It is not a discipline failure — it is people doing the part the software left to them, in the fastest tool available.
Should we get rid of spreadsheets entirely?
No. Some spreadsheets are scratchpads for questions nobody will ask twice, and some are simply faster for low-stakes entry. The ones worth replacing are the ones that compute a recurring decision — where the logic is stable enough to state and the person running it would rather be doing something else.
How do we tell which spreadsheets matter?
Three questions. Does it compute a decision, or only reshape data the ERP already holds correctly? Does it recur on a cycle? And does it exist because the ERP is missing a calculation, or because the ERP's data is wrong? The first is worth replacing, the second is a reporting job, and the third is a master-data job that should be done before anything else.
Does replacing a spreadsheet mean changing our ERP?
No. The calculation moves outside the ERP and the result is presented back through documented integration points — OData data entities, custom services and Business Events. No fields are added to your tables and no ERP behaviour changes. Anything that moves money or stock is proposed and prepared, and a person approves it.
What do our planners actually do afterwards?
The same job, starting further along. The analysis arrives done, with the reasoning attached, and their work becomes judging it rather than assembling it. The ones who were good at the spreadsheet are usually the ones who get most out of this, because they are the only people who can tell when the recommendation is wrong.
Is this something we buy or something you build?
Both exist, and the words are exact. The three that most often replace a shadow spreadsheet are the Pricing, Pick-Path and Demand & Inventory Optimizers: built, and demonstrated on request against your own demand history. Contract Review Copilot is shipped, running for a customer today as Paralegent AI. Several domains are built to order, which means we have the engineering and build it for you, with no packaged app yet. The MCP server and Copilot extension are in development.
Bring us your worst spreadsheet
Not a requirements document — the actual file, and the person who maintains it. A working session on one recurring decision, with one success metric agreed before we begin. If the honest answer is a report or better master data, that is a shorter engagement and we will say so.