Excel vs code for business calculations: when to move, and how
Spreadsheets are a great place to build a model and a risky place to run one. A practical comparison of keeping logic in Excel, rewriting it by hand, and generating code from the workbook.
Excel is the most widely used programming environment in the world, even if nobody calls it that. Pricing, reserving, credit risk, commissions and planning logic all get built in spreadsheets, because the people who understand the business can build and check it themselves.
The trouble starts when that model has to run something: a quote engine, a nightly batch, a customer-facing calculator, an API another system depends on.
Three ways to run spreadsheet logic in production
| Keep running Excel | Rewrite by hand | Generate code from the workbook | |
|---|---|---|---|
| Who owns the logic | Business | IT, after handover | Business owns the model, IT owns the build |
| Time to production | Immediate, but fragile | Weeks to months | Hours to days |
| Matches the signed-off model | Yes | Drifts over time | Regenerated on every change |
| Scales and integrates | Poorly | Yes | Yes: libraries, REST APIs, web UIs |
| Version control and review | Hard | Yes | Yes: workbook and code are both committed |
| Proof of equivalence | Not needed | Manual reconciliation | Generated tests against the workbook's values |
Signs it's time to move a model out of Excel
- Other systems need the result, and someone copies numbers between them by hand.
- The workbook has a "do not touch" sheet, or one person who understands it.
- It's slow, or near Excel's 1,048,576-row limit.
- Audit or regulators ask how a number was produced, and the answer is "open the file".
- Two or more versions of the "same" model exist in different departments.
Why hand-rewrites go wrong
Rewriting a model by hand means re-implementing every formula, lookup, rounding rule and edge case, and then reconciling the result with the spreadsheet. Even when it's done well:
- the business can no longer change the model without a development cycle
- the code and the next version of the spreadsheet start to differ
- subtle behaviour such as approximate lookups, date arithmetic and implicit type conversions is easy to get slightly wrong
What generating code changes
Codcel reads the workbook's formulas and generates readable source code in Rust, Python, Java, Kotlin, C#, Visual Basic, Go or Swift, plus REST servers, web clients, full web UIs and MCP servers for AI agents. Tests compare the code's results with the values in the workbook.
The business keeps improving the model in Excel. IT gets code it can review, version, test and deploy like everything else. When the model changes, you regenerate and review the diff.
Where Excel should stay
Excel is still the best tool for exploration, ad-hoc analysis and building a model in the first place. The goal isn't to take spreadsheets away from analysts. It's to stop running production on them.
See it on your own workbook: download Codcel (free for personal use), or start with Excel to code in your language.
Keep reading
Turn an Excel spreadsheet into a REST API
Expose the calculations in an Excel workbook as a documented REST API, with one POST endpoint per calculation, in Rust, Java, Kotlin, C# or Go, plus typed clients and an OpenAPI spec.
Turn an Excel model into tools an AI assistant can call (MCP)
Generate a Model Context Protocol server from an Excel workbook, so Claude and other AI assistants call your real calculation instead of guessing at the maths.