Teaching a Spreadsheet Engine to Teach Itself

Every venture fund on AngelList lives or dies by its spreadsheets. Capital calls, fee waterfalls, investable capital reconciliations: the financial models our fund managers rely on are built in Excel, and they have to be exactly right. A rounding error in a carry calculation can mean millions of dollars misallocated.

For years, we depended on Microsoft's Excel Online API to run those calculations server-side. Eventually, we outgrew it. API latency was unpredictable. Rate limits throttled us during peak quarter-end reporting. And every recalculation required a round-trip to Microsoft's cloud, meaning we couldn't run computations offline, in tests, or at the speeds our platform demanded.

We needed our own Excel engine. So we built one.

Werkbook: An Excel Engine in Pure Go

Werkbook is a Go library that reads, writes, and calculates .xlsx files with zero external dependencies. No Excel installation. No cloud API. Just a binary that understands spreadsheets.

The project started as an open-source effort by James Pozdena, Sr Software Engineer on the team. The goal was deceptively simple: take an Excel file, recalculate every formula, and get the same answer Excel would.

That "same answer" part turns out to be extraordinarily hard.

Excel has over 500 functions, each with intricate edge cases honed over four decades. VLOOKUP with wildcards behaves differently than exact match. IRR uses Newton's method with a specific convergence threshold. Date serial numbers have a famous 1900 leap year bug that every compatible engine must deliberately reproduce. Today, Werkbook supports 450 formula functions backed by over 15,000 individual test cases, and that number grows every week.

But the most interesting part isn't how many functions we've implemented. It's how we've built a feedback loop that keeps making the engine more accurate with every cycle.

The Self-Improving Loop

Here's the insight that changed everything: the internet is full of Excel files.

Government agencies publish budget spreadsheets. Universities share statistical models. Financial institutions distribute reporting templates. Nonprofits post grant tracking workbooks. These are real files, built by real people, using real formulas in ways no test suite author would think to write.

We built a pipeline we call the community loop. It works like this:

1. Harvest: We find publicly available .xlsx files on the web: from open data portals, government repositories, academic institutions, and anywhere else spreadsheets live in the wild.
2. Check: Each file is run through wb check, a parity tool built into Werkbook's CLI. It opens the file, reads the cached formula values (as originally computed by Excel), recalculates every formula using Werkbook's engine, and compares. Any discrepancy, even a fraction of a cent, is flagged.
3. Triage: Mismatches are automatically categorized by formula function, error pattern, and frequency. The pipeline syncs issues directly to our tracker, so we know exactly which functions need attention and how common the gap is.
4. Fix: Engineers implement the fix, add regression tests derived from the real-world file, and re-run the full corpus to confirm the improvement propagates.
5. Repeat: The corpus grows continuously. Every new batch of public files is another round of testing. The engine gets better every cycle, not because someone wrote a clever unit test, but because it was confronted with a spreadsheet from an Oklahoma municipal budget or a Brazilian university's enrollment model.

This is what we mean by self-improving. The engine doesn't improve through AI or machine learning. It improves through a disciplined, automated feedback loop that pits our implementation against the messy, diverse, real-world corpus of how people actually use Excel.

Correctness isn't something you prove once and move on. It's something you continuously discover by testing against reality. The wild spreadsheets always find edge cases we didn't imagine.

ACE: Putting the Engine to Work

Werkbook is the engine. ACE (AngelList Calculation Engine) is the platform built on top of it.

ACE lets our fund administration team build financial models in the tool they already know: Excel. They design a Recipe (a versioned Excel template with named data connections) and ACE takes it from there:

1. A fund manager or accountant uploads a Recipe with formulas that compute carry allocations, investable capital, or fee schedules.
2. ACE creates a Workbook for each fund entity, injects live data from our platform through Connections (investments, distributions, capital calls, expenses).
3. Werkbook recalculates every formula locally, with no round-trip to Microsoft.
4. Results are extracted from Excel named ranges and cached as Outputs, served via REST API with sub-100ms response times.

The shift from Excel Online to Werkbook didn't just make us faster. It made us architectural owners of the calculation layer. When a formula function had an edge case, we could fix it in Werkbook and redeploy in hours. No support ticket to Microsoft, no waiting for a service update.

Today, ACE powers reconciliation across thousands of investment vehicles, automatically recalculating when upstream data changes via CDC events and NATS streams. What used to require manual spreadsheet work by accountants now happens automatically, continuously, and at scale.

From Zaxcel to ACE: The Full Arc

This isn't the first time we've rebuilt how AngelList handles spreadsheets. In 2023, Chamod Gamage built Zaxcel, a Ruby DSL that transformed how we generate Excel files, replacing brittle string-based cell manipulation with a graph-based reference system. Zaxcel now powers the generation of quarterly financial statements across thousands of funds.

ACE and Werkbook tackle the complementary problem: computing Excel files. Where Zaxcel writes spreadsheets, Werkbook reads and calculates them. Together, they form a complete stack: domain experts author financial models in Excel's familiar interface, Zaxcel generates the reporting output, and ACE + Werkbook execute the computation server-side.

We used to be at the mercy of external APIs for something as fundamental as 2 + 2 in a spreadsheet cell. Now we own the entire pipeline, from formula evaluation to financial statement generation.

What We've Learned

Building a spreadsheet engine from scratch sounds like a yak-shave. It isn't. For a platform that supports hundreds of billions of dollars in venture & private assets, formula correctness is a first-class product requirement, not a nice-to-have.

A few lessons from the journey:

Own your critical path. When your business depends on a calculation being correct, you can't afford to treat the calculation engine as someone else's problem. External APIs are fine for non-critical workloads. For financial reconciliation, you need to be able to read the source code.

Let the real world write your tests. Hand-authored test suites are necessary but insufficient. Public Excel files exercise formula combinations no engineer would think to test. A municipal budget spreadsheet taught us more about SUMPRODUCT edge cases than a month of manual test writing.

Small teams, high leverage. Werkbook and ACE were built primarily by a single engineer, with contributions from a small team. The key was choosing the right abstraction (a general-purpose engine that could serve many use cases) rather than building one-off solutions for each financial model.

Join Us

If building infrastructure for a $200B+ venture capital platform sounds like your kind of problem, we're hiring. Our Finance Engineering team works at the intersection of financial modeling, distributed systems, and developer tooling, and we're always looking for engineers who care about correctness as much as velocity.