Concept demo for Aspire, by Dvar

The AI steps in your expense flow, measured before they ship

Dvar hosts small open models for the high-volume steps of a finance app: reading receipts, coding them, matching them to card lines, answering spend questions. Code applies the policy, and every model is scored on the same work before it ships.

Shown on one invented company, Kestrel & Finch Pte. Ltd., and one month of its spend.

Start the tour (7 stops)Open the claims phones

316 synthetic receipts, card transactions and supplier bills across 5 markets and three languages, plus 40 spend questions. Model results are an internal benchmark on synthetic data.

For every employee and approver

Claims that fill themselves

The problem today: Typing in merchant, amount, category and guests for every receipt, then approvers wading through every claim to find the few that matter.
What it does: No more typing receipts: snap one and the claim fills itself in and matches the card line. The approver sees only the claims that need a decision.
What you see in the demo: A receipt in Chinese, a Hong Kong dinner over the limit, a duplicate: each filled in on the phone, with the reason it went to review.
On this run: Receipts right on every field: Dvar small model 149 of 159, Low-cost frontier 149 of 159, Mid-tier frontier 150 of 159. Fastest median fill: Mid-tier frontier.

Open →

For a finance admin or a CEO

Ask your spend

The problem today: Simple questions (“what did we spend on software this quarter?”) mean an export, a spreadsheet and a wait.
What it does: Answers about spend in seconds, in one line and a chart. The model only writes a small query; code runs it on the ledger, so every figure is computed from the books.
What you see in the demo: The question, the query the model wrote, and the answer computed from the ledger, side by side.
On this run: Answers right to the cent: Dvar small model 27 of 30, Low-cost frontier 27 of 30, Mid-tier frontier 28 of 30.

Open →

For the AI lead

Month-end close, measured

The problem today: No proof, before shipping, that a cheaper or faster model is safe, or what it costs per month.
What it does: Proof on one scorer: one company-month through each model, every field checked against an answer key, with no judge model.
What you see in the demo: Share of items closed with no review, critical failures that block a model outright, latency, and cost for the volumes you enter.
On this run: No model has a critical failure on this run, so none is blocked. Median time Dvar small model 2.60 s, Low-cost frontier 730 ms, Mid-tier frontier 544 ms; per 1,000 items Dvar small model $0.46, Low-cost frontier $0.23, Mid-tier frontier $5.51.

Open →

Why this flow

It is the highest-volume flow.

Every claim from every employee, every month. At that volume, time on the phone and cost per claim both matter, and both are measured here for every model, whichever comes out ahead.

The model reads; code decides.

Policy limits, duplicates, card mismatches and changed bank details are checked in code on what the model read. A misreading shows up as a wrong decision, and the scorer catches it.

It can be scored without a judge.

Every field is right or wrong against an answer key, so a model or prompt change can be re-scored in minutes, with critical failures that no average can buy back.

Open weights can run where you need.

The small model can be hosted by Dvar or run in your own cloud, and tuned on its own misses: the GL codes and receipts it got wrong.

What this is not: Aspire's product, data or models, or a claim about how Aspire builds these features today. It is a concept by Dvar, styled after the Aspire app and run on synthetic data, to show how the same steps can be run and measured.