Turn Excel workbooks into reusable engines

[written by a human, by hand]

xplo is an Excel spreadsheet "compiler" - it translates an Excel workbook into performant code that can run anywhere. We built xplo for the folks and teams that use Excel as part of how they think, analyze, and collaborate. With xplo, these teams can keep thinking in Excel, but can embed the logic of their workbooks into data pipelines, websites, and anywhere code can run.

How you use it

Using xplo is simple:

1. Upload your .xlsx file (through the web or an API)
2. Wait for it to process (this can take several minutes for large spreadsheets)
3. Call it like a function or an API in your language and mode of choice

"Calling" the spreadsheet just means feeding it one or more scenarios you want to have it compute: each scenario describes the inputs (i.e. cells you want to change) and requests outputs (i.e. cells you want to re-read after the recomputation of the sheet has completed).

How you call an xplo spreadsheet is up to you - you can download a binary and run it on your hardware as a library in any language, you can grab the javascript client harness and run it in the browser, or you can call it as an API, and have xplo do the computation for you.

How it works

Xplo's compilation process is straightforward:

• It parses the spreadsheet and extracts all of its cells and relevant metadata, including the formula 'trees'.
• It computes the graph of how different cells rely on one another, including ranges.
• It then converts each cell into a function - this function calls the functions for other cells and ranges and combines them in rust-specific implementations of the excel functions.
• It then uses all of these generated function definitions within a harness in rust that describes things like iterative calculation, and how to handle some harder pieces of engine logic.
• The rust code, once generated, can either be compiled, or lowered to a native VM built for xplo specific tasks. You don't need to think too much about this, but essentially the compiled version is very fast to run, but takes several minutes to create, but the VM-based system is much faster to create, and slower to run.
• This code is then wrapped in a variety of utilities like an API, a CLI, a Monte-Carlo simulator, and client libraries so that it's trivial to use xplo however it works best for you.

Accuracy

What is xplo aiming to emulate?

Xplo is trying to emulate the computational behavior of 2024 Microsoft Excel Long-Term-Support version 2408, specifically the Build 17932.20638. We additionally support some functions from Microsoft 365 and Mac versions of Excel, so that users of either of those platforms don't need to worry about whether their functions are supported.

How good is xplo's emulation

It is very good, but it is not bit-for-bit exact. This is for a variety of reasons:

• Excel

How have you resolved issues where it is not exactly the same?

Our approach to validation

Excel is a complicated engine, so when we set out to build a computation engine that was bit-for-bit equivalent to it, we knew the biggest challenge was going to be finding all of the edge cases - particularly because excel has so many functions that have undocumented behavior.

We spent months building out complex infrastructure that explored the state space of excel programmatically, and evaluated it for bit-for-bit parity against our engine. We used nuanced systems of code coverage to identify what changes would impact what cases. We built semi-automated agents that would try to fix deviations, while keeping human review in the loop to look for the (many) cases where agents would try to cheat to fix the tests.

While we don't share all of the details of this validation publicly, since it is the core piece of valuable work we've built, we have published a high-level summary of our core test suite, which we call our corpus so that you can see the same metrics that we track for how our engine is performing as we make tweaks to it.

If you're a prospective client that wants to learn more about this, please reach out!

Your Workbook

Xplo has an automatic check to ensure that when our engine recomputes your spreadsheet for the first time (with no overrides) the results match the saved/cached values in your excel spreadsheet. If your spreadsheet doesn't have those values (which can happen if your spreadsheet was minimized for size, or if it was built through a library), we'll execute it on production Microsoft Excel

This doesn't guarantee perfect bit-for-bit parity on all scenario computations, but it's a very good bet that

How It Works - Web

1. Upload your Excel file (.xlsx) — xplo uploads it to our servers, which parse your formulas, resolve dependencies, generate native code, and apply a wide range of optimization steps to produce an optimized binary
2. Select the input cells you want to vary
3. Assign probability distributions (normal, uniform, triangular, etc.) to those cells
4. Run the simulation entirely in your browser (for free) — the workbook engine runs locally on your hardware, no network calls needed
5. Explore the output distributions and understand your risks and opportunities

How It Works - API

Through the xplo API you can get access to the same high-quality, high-speed execution, on any computer (laptop, desktop, or server). Read more about this on the API page.

Why xplo?

Spreadsheets are widely used for complex analysis across finance, risk, investment, climate, and other fields. However Excel is slow, and often requires large workarounds, macros, and powerful machines to run simulations over these workbooks quickly.

xplo allows people the best of both worlds - build and collaborate in excel, then execute, test, and evaluate in xplo.

How fast? A real example

Consider a real example: a 5MB actuarial workbook used in a major insurance firm, with ~300,000 cells across 98 sheets.

When running locally via python automation of real excel, this spreadsheet takes 9 minutes to execute and then grab all of its cell values. On the xplo VM, it achieves 8 executions per second per thread, so on a multicore machine (a Mac Studio) it can execute at 130 executions/second, once parallelism around inserts is considered. Once compiled (a one-time cost of 6 minutes for this spreadsheet), it achieves 260 executions per second per thread, so onthe same high powered mac, it can execute at 5,000 executions/second, once parallelism around inserts is considered.

The reason it's fast is not just that we compile to native code. When you sample a handful of input assumptions and watch a handful of outputs, xplo's compiled engine computes the full workbook once, then for every trial recomputes only the cells that actually change — we recognize that only some fields need to change in response to others, between the inputs you're varying and the outputs you're watching. Even on very large workbooks that is usually a few thousand cells, so a trial costs less than a millisecond instead of recomputing the whole sheet. (An interpreter that recomputes every cell every trial does ~100× more work — which is why the compiled engine is the one behind the high-throughput simulation workflow.)

This performance varies per sheet, but it demonstrates that even very large .xlsx workbooks can run efficiently.