Finance as Code

Over the past few years, AI has become genuinely good at software engineering. Agents now write, review, refactor, and debug production code at a level that surprises even the people building them. It's worth asking why code, of all domains, is where AI works best — because the answer isn't luck.

Software has a set of properties that almost nothing else has:

• Structure. Code has formal syntax, named symbols, and an explicit dependency graph. A compiler rejects nonsense before a human ever sees it.
• Training data with feedback attached. Decades of public code exist alongside its commits, diffs, reviews, bug reports, and fixes — millions of worked examples of the difference between broken and correct.
• Evaluation machinery. Tests, type checkers, linters, and CI give instant, objective, machine-checkable feedback on every change.
• Verifiability. For any intended behavior, you can write a test that proves it. An agent doesn't have to be right on the first try — it can generate, check, fix, and repeat until the checks pass.

Now look at financial models. They are among the most consequential artifacts in business — billions of dollars move on their outputs — and they live in spreadsheets: logic smeared across anonymous coordinates like =B47-SUM(C12:C19), no types, no units, no version control, no tests, no record of where a number came from. When AI operates directly on a spreadsheet, it inherits every bit of that ambiguity. Worse, so does everyone reviewing its work — errors don't fail loudly, they just sit there looking like numbers.

Our proposal is simple: represent financial models the way software represents programs. Introduce the same structure. Write validation that enforces consistency and quality mechanically. Build evaluation loops with defined criteria for what a good model looks like. Do that, and everything that makes AI exceptional at coding — the rigor, the tooling, the feedback loops — carries over to finance. We call this finance as code.

Operating models, as code

At Convexent, an operating model isn't a grid of cells. It's a declarative specification written in a domain-specific language built for financial modeling. A slice of one looks something like this:

metrics:
  gross_profit:
    expr: revenue + cost_of_sales     # costs carry their sign — no hidden double-negation
  revenue:
    expr: sum_over(segment_revenue, dim=segment)

assumptions:
  unit_price:
    kind: tensor
    dims: [time]
    source:
      document: "FY24 CIM"
      page: 31
      table: "Unit Economics"

That representation buys you the same things source code buys a software team:

• Traceability. Every metric is a named definition with an explicit formula over named operands. The spec compiles to a dependency graph, so any number in the model — EBITDA in 2028, say — traces back through named drivers to the assumptions underneath it. No archaeology through cell references.
• Checkable plumbing. A formula can only be built from qualified operands: references that resolve, periods that line up, sign conventions that are enforced rather than remembered. The mathematics of the model can be verified mechanically, the way a compiler verifies a program.
• Separation of concerns. Assumptions (what you believe), metrics (what you compute), and presentation (what you show) are split cleanly apart. Change one assumption and every downstream dependent is knowable, not discoverable.
• Version control. The model is text, so it diffs. Every edit — human or AI — is a structured, auditable patch. Model changes get reviewed the way engineers review pull requests, and any two versions compare cleanly.
• Provenance. Historical values link to their exact source location — the document, page, and table they were extracted from, with metadata carried through the build. You can walk from a cell in the finished workbook back to the filing or CIM page that justifies it.

You still get Excel at the end. The spec renders to a real workbook with native formulas — but the spreadsheet becomes the compiled artifact, and the spec is the source code.

And here's the payoff: once the model is code, AI can operate on it with the same rigour, power, and flexibility it brings to software. An agent can read the dependency graph, propose a structured edit, run the validators, see precisely what broke, and iterate — instead of guessing at cell coordinates and hoping.

Training loops and refinement

Structure is the foundation, but it's only half of what makes AI good at code. The other half is measurement — and software engineering hands us the playbook for that too.

Deterministic checks are our compiler and linter. Every generated model passes through tiers of validation: schema and syntax first, then reference resolution, then financial-logic invariants — the balance sheet balances, asset rollforwards reconcile, statements sum from their components, sign conventions hold. Failures come back as structured, actionable errors, and a whole class of mechanical issues is fixed automatically without an LLM in the loop:

✗ balance_sheet_balance   total_assets ≠ total_liabilities + total_equity in 2027 (Δ $4.2M)
✗ sign_convention         cost_of_sales stored positive; costs are stored negative
✗ dangling_reference      report line "Net Debt" references undefined metric net_debt
✓ 41 checks passed        2 issues autofixed

Judged evaluation is our code review. Above the deterministic layer, model judges score each build against defined criteria — faithfulness to the source documents, financial logic, semantic validity, readability. The judges are independent frontier models from a different provider than the ones doing the generating, for the same reason you don't let an engineer approve their own pull request.

Evaluation loops close the cycle. We keep a corpus of fixtures built from real company documents and score every change to our prompts and harness architecture against committed baselines — so quality drift shows up as a reviewed diff, not a customer complaint. Each production run also contributes labeled defect signatures back to that corpus. Because we can judge models concretely, improving the system stops being guesswork: the evaluations tell us exactly where it fails and what to refine next.

The harness: agent loops for financial engineering

With structure and measurement in place, model-building can run the way modern AI coding tools run — as a harness of specialized agents working in loops, not a single prompt hoping for the best:

• Exploration agents read the source documents and probe the model graph.
• Refinement loops iterate the model against the validators and an explicit definition of done.
• Analyst agents perform a cold read of the finished model and flag findings with evidence: severity, location, observation, hypothesis.
• Remediation agents apply accepted findings as structured, validated edits.
• Verification agents re-read the delivered model independently — they are never shown the fixes they're checking, so they can't rubber-stamp.

We build on the same open agentic coding harness pattern that powers today's best AI coding assistants: agents get read and write tools over the model spec, the validation suite as their test suite, and a concrete definition of done. Two rules from software practice matter most. The author is never the reviewer — finding, fixing, and verifying run in separate lanes. And defer, don't fabricate: when fixing a finding would require inventing data the source documents don't contain, the agent defers it with a documented reason for a human to resolve, rather than papering over the gap.

Does it work? Benchmarking the three regimes

It's a fair question: does the structure actually make the models better? We benchmarked it. Three companies — a luxury fashion house, a global healthcare company, an EV-charging network — each modeled three ways from the same source documents:

1. LLM alone. One call to the same frontier model our pipeline uses, given the same extracted source data and asked for the best working spreadsheet model it can produce — cells and Excel formulas, which we compile into a real workbook and execute in a calculation engine. No DSL, no validation, no agents.
2. Finance as code, single pass. The same model generating into our DSL, with deterministic validation — but no agent loops.
3. Finance as code, full harness. The same build after the refinement, analyst, remediation, and verification loops have run.

Every model was rendered the same way — computed values plus formulas — and scored against the same fixed rubric of 21 concrete criteria: historical fidelity to the source, statement and line-item completeness, internal consistency, driver logic, and usability and traceability. Twenty criteria are scored blind by an independent judge model from a different provider than any model in our pipeline; one is deterministic — does the model actually execute. Criteria are weighted by how load-bearing they are for a decision-grade model — a missing balance sheet counts for more than a rounding nit on a ratio — with the same weights applied to all three regimes. Tiers two and three are the same build before and after the agent loops, so that comparison is exactly paired.

First, credit where it's due: the gap is not about whether a frontier model can emit a spreadsheet that computes. It can — all three of its workbooks loaded and recalculated cleanly. The gap is what an audit finds once every model shows its computed values. The freeform spreadsheets are small summaries that evaporate under inspection: none decomposed its forecast into the operational drivers the source provides, none kept a source citation on a single historical value, none attempted a balance sheet, and in only one of three did the spot-checked formulas actually reproduce the values the model displays. A model like that looks clean — until you ask it a question.

The paired comparison shows what the agent loops are for: on the same builds, the harness lifted the luxury-retail model by 41 points and the healthcare model by 34, reaching 82% overall — the best score on every company — while fixing the defects the single pass shipped:

One detail is the whole thesis in miniature: one of the three single-pass builds wouldn't calculate at all — a malformed period label crashed the engine. Because the model is code, that defect was loud: the build failed, the harness caught it, and the delivered model computes. Note the middle column above — structure without the agent loops carries real defects, and we publish that number anyway, because the loops are the product: finding, fixing, and verifying is what turns a generated draft into a model you can stake a decision on.

Two more things our trial campaigns taught us that a chart can't show:

• Independent verification earns its seat. Across the wider trial campaign, the verification agent repeatedly caught critical defects the earlier stages had missed — including a liabilities subtotal that added lease liabilities it should have netted, a finding the independent judge model corroborated.
• The safety net catches the agents, too. In one run, an agent's fix introduced a break in an asset rollforward. The deterministic reconciliation checks flagged it immediately and the run was marked as failed rather than delivered as fine. In a spreadsheet, that error survives until someone audits it by hand. As code, it's a failing test.

The honest conclusion is not that AI agents are flawless — our own data says they aren't. The conclusion is that when the model is represented as code, defects become visible, checkable, and fixable: findable by validators, catchable by independent reviewers, measurable by judges, and steadily rarer as the evaluation loop tightens. On a grid of anonymous cells, those same defects are just numbers.

Structure first

Software engineering spent decades building the structure that makes AI effective today: languages, compilers, tests, version control, review culture. Finance doesn't need to spend decades — it needs its models represented in a form where all of that tooling applies. That's what we're building at Convexent: financial models with the structure of code, validated like code, improved like code — and still delivered as the Excel workbook your team already knows how to read.