Vert: AI Infrastructure That Understands Financial Context

Most AI tools start to fall apart once the work gets complex and the numbers get bigger. We built Vert so that doesn't happen. Here's how we cut out 99% of hallucinations, and why accuracy keeps improving the longer a team uses it.

Why finance is hard for AI

Finance has run on spreadsheets and manual work for decades. LLMs are changing that fast. Agents can write code, analyse data and work through problems that used to take an analyst a day. And yet most month-end closes still happen in static spreadsheets.

The spreadsheets aren't harmless either. When Raymond Panko at the University of Hawaii audited 54 real spreadsheets, he found errors in 49 of them, and Fannie Mae once traced a $1.2 billion accounting mistake back to one (Computerworld). Closes are still slow too: in a 2026 LiveFlow survey, only 16% of teams closed in under three days, and 16% took more than ten (CFO Dive).

We think the reason is pretty simple. Finance needs things most AI products weren't designed for: controls, reliability, an audit trail, and a real understanding of the business. Give a general-purpose agent access to your systems and it'll go hunting for data it can't verify, guess what a column means, and do the maths in its head. Most of the time it's close. In finance, close isn't good enough.

The research backs this up. On FinanceBench, a set of questions about public company filings, GPT-4 Turbo paired with a standard retrieval setup got 81% of questions wrong or refused to answer them (Islam et al., 2023). On Vals AI's Finance Agent Benchmark, 537 questions written by finance experts, the best model tested, OpenAI's o3, reached 46.8% accuracy at about $3.79 per question (Bigeard et al., 2025). These are very capable models. They just weren't given the data, context and controls the work needs.

So rather than trying to make the model smarter, we built the infrastructure around it. Vert has five layers, and each one takes a job away from the model that the model shouldn't be doing.

Layer 1: Data

Everything starts with one source of truth. All of your financial data sits in one place, stored natively inside Vert, and that's the main reason our agents stay in control and don't hallucinate.

The usual approach is to give an agent a search tool and let it find what it needs. That's where things go wrong. When the results are thin, the agent fills the gap with something plausible. And when it's free to search, it tends to wander: more queries, more systems, further from the original question.

It's the same problem people have. In the LiveFlow survey, nearly eight in ten finance professionals said close delays come from waiting on data from other systems or teams, and over half said reconciling information across platforms holds them up (CFO Dive). Handing that scavenger hunt to an AI agent doesn't fix it. It just makes the mistakes faster.

We took that job away from the agent entirely. Data from your accounting system, bank, payment processor and documents is pulled in and parsed by Vert itself, through fixed pipelines. It's stored in-house with a link back to where it came from. Search works on exact matches too, so an invoice number returns that invoice and not five similar ones. By the time an agent sees a number, it's already been captured and checked. The agent works with the data. It never goes looking for it.

Layer 2: Context

Clean data on its own still isn't enough. An agent can see that an account moved by $40k and have no idea whether that matters. Context is the missing piece that lets it reason properly, and it's what lets AI scale across a business without breaking.

We build that context in a few ways. There's a financial ontology, a shared vocabulary of accounting concepts and how they relate, which every agent learns from. On top of that sits a semantic layer with the company's own definitions, metrics and KPI drivers, so "gross margin" means the same thing every time. We map how customers, vendors, accounts, transactions and entities connect, so an agent can follow a payment from the vendor through to the GL and the budget. Each client's own rules and policies are built in. And agents keep memory of how a company works and how each person likes things done, which is a big part of why accuracy improves over time.

Layer 3: Deterministic engine

Models are probabilistic. Accounting isn't. The deterministic engine handles the numbers, and it's what stops agents from crossing the line.

Anything that has to be exactly right is written in code. Double-entry rules and core accounting logic are hardcoded. Calculations like variances, aging and amortization are run by a calculation engine instead of being written out by the model. Our matching engine pairs transactions across Stripe, the bank and invoices, matches vendors across systems, and scores how confident it is in each match, so reconciliation can run continuously instead of in a rush at month end. Reading documents in and posting entries out to your ERP both follow fixed rules. And any output the AI produces has to fit the exact database schema before we accept it.

When we looked at the workflows finance teams run, almost all of them came down to the same eight or so operations: mapping columns, aging, matching two files, comparing periods, building schedules, drafting journal entries, spotting anomalies and rolling things up. The agents decide which of these to use. The engine does the actual work.

Layer 4: Agent infrastructure

Once the data, context and engine are in place, the agents can actually get work done. A frontier model on its own is a very smart generalist. What turns it into something a finance team can rely on is the harness around it: how work gets split up, which skills it has, which tools it can use, and how it gets better over time.

How the agents are organised

We don't use one giant agent for everything. A quick question, like "what did we spend on software last quarter?", goes to a single agent that answers it and stops. Bigger jobs, like a month-end close, go to a supervisor agent that plans the work and hands pieces to specialists.

Those specialists are domain agents, each with its own slice of the financial ontology. There's a reconciliation agent, a journal entry agent, a transaction processing agent and an analysis agent, with technical accounting coming later. Keeping them narrow means each one knows its area deeply and isn't distracted by everything else.

We also route each step to the right model. The hard reasoning goes to frontier models. Routine steps don't need them, so they don't get them.

Skills

A skill is a written procedure for a specific piece of finance work. It isn't a loose prompt. It's closer to an internal playbook, the kind a good controller would hand a new hire.

Take our data analysis skill. It spells out when it should run and when the work belongs to another skill. It lists the checks to do before touching a single number: schema, nulls, duplicates, date formats, mixed currencies, whether the trial balance actually balances. It then follows a fixed sequence, from profiling and cleaning the data through to the analysis itself, and then a verification step that throws out any insight it can't trace back to a specific row. It even controls language: the agent can't say something "caused" a result unless the evidence supports it, so it says "associated with" instead. If the data is too poor to answer the question, it stops and asks for better data.

We have skills like this for bank and card reconciliations, journal entries, accruals, revenue recognition, depreciation and prepaid schedules, flux and variance analysis, budget vs actual, and the month-end close as a whole.

Skills that keep improving

A procedure written once goes stale. Our skills don't stay frozen. As teams use Vert, we watch how the work actually gets done: where a reviewer corrects a match, rewrites a journal entry or rejects an explanation. That feedback goes back into the skills and procedures, so the next run is closer to how your team does things. Matching, recommendations and queries all learn from those corrections. It's a big reason accuracy goes up the longer a team uses the platform, and workflows can be reused across entities and engagements instead of rebuilt each time.

Tools

Skills say what to do. Tools are how it gets done, and the heavy lifting is always done by code.

• Matching engine. The reconciliation agent profiles both datasets, picks a strategy, sets tolerances and calls the engine. The engine handles exact, one-to-many, many-to-one and many-to-many matches, with date and FX tolerances and fuzzy reference matching. If confidence is low, the agent tries a different strategy. Whatever is still unmatched goes to a person.
• Spreadsheet sandbox. Before changing a workbook, the agent reads its structure, finds the tables, works out what each column means and maps which cells depend on which. It makes its changes in a sandbox, then checks the formulas, makes sure totals still reconcile and that nothing is broken. If something fails, it repairs it before you ever see it.
• Calculation engine. Every number is computed in code, never typed out by the model.
• Documents. Agents read PDFs, OCR scanned documents, pull tables out of files, read and build Excel workbooks, and generate workpapers and reports.
• Posting and sync. Approved journal entries post to the GL, and approved transactions sync back to your accounting system, such as QuickBooks, through fixed rules.

Layer 5: Governance

None of this matters if a controller can't sign off on it. Finance teams don't just need the right answer. They need to show how they got there, to their CFO, their board and their auditors. So every step in Vert is auditable, and every generated figure has a person in control of it.

Every number has a source

Any figure an agent gives you links back to the record it came from: the bank line, the invoice, the GL entry. You can click through and check it yourself. Before an answer goes out, a validator strips any metric that doesn't exist in the underlying data, so a number can't show up in a report unless it's actually in your books.

You can see the reasoning, not just the result

Agents don't jump from a fact to a conclusion. They work through a set order: the facts in the data, what those facts show, the patterns across periods or segments, a possible explanation, the evidence for it, and only then a conclusion and a recommendation. Each step is recorded. When an agent says your OPEX is over budget because of a cloud invoice, you can see the exact rows, the comparison it made and why it ruled other explanations out.

Agents also keep fact and inference separate. Something read straight from the ledger is labelled as fact. Something the agent thinks is likely is labelled as a hypothesis, with a confidence score.

Confidence decides what happens next

Confidence isn't a gut feeling. It's calculated from data quality, sample size and how noisy the numbers are, and it decides what the system is allowed to do. High-confidence work can flow on automatically. Medium-confidence work goes to a person before anything touches your books. Low-confidence results are shown for information only. The same goes for matching: anything below the threshold lands in an exceptions queue for a reviewer.

People stay in the loop

Anything material gets human approval before it posts. Journal entries are drafted and validated, then approved. Transactions are reviewed before they sync to your accounting system. If a request is ambiguous, the agent asks a clarifying question instead of guessing. If the data is broken, it says so and stops, rather than handing back something that looks right and isn't. Unusual variances get flagged to a person straight away.

A full audit trail

Every transformation is logged: rows that were cleaned, values that were filled in, records that were excluded and why. Nothing is dropped silently. Combined with deterministic rules for capture and posting, that means the same input gives the same output every time, and you can show exactly what happened, step by step. Sensitive personal data, like card numbers, is masked before an agent ever sees it.

What this adds up to

We don't think finance needs AI that's clever with messy data. It needs AI that never has to touch messy data at all.

That's what the five layers are for. Teams can hand agents the close, the recs and the ad hoc questions from the CFO, and trust what comes back, because every answer is grounded in their own books and every step can be checked.

You can see how it works at vertfinance.tech.