What Jev is, in one paragraph
TypeSafe AI calls it a System One model, after Kahneman's fast, intuitive thinking. You send it a state, which is any JSON you like, and a set of questions. Each question is one of three types: a choice from options you define, a score against ordered levels, or a yes/no. It answers all of them in one parallel pass and returns a probability for every option plus a separate confidence number. It cannot generate text at all, so it cannot hallucinate a GL code that does not exist in your chart of accounts. The published price is $0.042 per million input tokens and nothing for output. Access is early and behind a waitlist.
That description maps almost exactly onto the middle of an invoice pipeline, which is why we tried it.
Where it fits
The accounts payable module takes a supplier document, extracts the fields with Claude, classifies the invoice to a GL account and a cost center, screens it for duplicates and anomalies, and then routes it to a human for verification unless the confidence is high enough to auto-verify.
Jev cannot read a PDF, so extraction stays with Claude. The classification step is a choice from a fixed list, though, and so is the question "is this document even an invoice". Those were the experiments.
Test one: nine PDFs, document type
We started with nine real documents from one operating entity, deliberately mixed: an itemised telecom bill, a corporate card statement, a cash advance request, a scanned invoice bundled with a debit memo, a recruitment placement fee, a software licensing invoice. Three were scans with no text layer.
For document type we gave Jev the raw text from pdftotext, or from tesseract OCR for the scans, and asked which of the ten document types our parser knows this was. Then we asked again using the extracted fields with the parser's own answer stripped out. Both variants agreed with the Claude parser on all nine: seven invoices, one cash advance request, one statement. Median latency was around 0.3 seconds and the whole stage, 18 calls, cost a tenth of a cent.
The two low-confidence answers were the interesting ones. One invoice yields only a couple of hundred characters of text, a bare billing table with no header, and Jev split between invoice and other at 0.37. The scanned invoice plus debit memo came back as invoice at 0.51 and debit memo at 0.44, while a separate "does this file contain more than one document" question fired at 0.98. That is what you want from a triage step: certainty on the easy ones, a clear signal to fall through to the full parser on the odd ones.
On GL and cost center, nine documents were too few to say much, and with no ground truth we were judging by eye. So we went looking for a bigger set with answers attached.
Test two: 2,069 bills the finance team had already coded
Every bill in Xero carries the GL account and the tracking team that finance chose when they posted it. That is a labelled dataset nobody had to build. We exported the paid and authorised supplier bills for one entity, 2,069 bills and 13,219 lines, and gave each classifier the same thing: supplier name, line descriptions, quantities and amounts, the entity's 244 expense accounts and its 85 tracking teams. No PDFs involved.
Two decisions shaped the set. We dropped every bill whose contact was an individual, which removed staff reimbursements and personal card statements, and we withheld invoice numbers and references, since none of that helps classification and none of it needed to leave the building. And because our module classifies one GL and one cost center per invoice, a bill whose lines all share one coding counts as one unit, while a bill with mixed codings is scored line by line. That left 2,856 units: 174 whole bills and 2,682 individual lines from mixed bills.
The result that decides everything: supplier history
Our production classifier sees what a supplier was coded to before. The first Jev run did not, and it was poor: 28% on GL, 15% on team. Its confidence knew it, sitting below 0.6 on almost everything, but that is cold comfort.
Then we added the same prior production uses, leave-one-out: for each bill, the supplier's three most frequent codings from their other bills. GL accuracy doubled to 58% and team went to 40%. On the 174 whole bills, the granularity our module actually works at, it reached 91% on GL, 89% on team and 86% on both.
The line-level number looks bad until you read the misses. 967 of those lines are HMO and health insurance bills where each line is one employee's premium, posted to whichever client team that employee works on. Nothing on the line says which team that is. Jev got 5% of those. On everything else, team accuracy was 58%. Another 531 of the GL misses picked the right account family but the wrong Billable or Non-Billable variant, which in this chart depends on whether the staff member involved is billable to a client. That is not on the invoice either. Counting those as correct, GL accuracy is 76%.
Jev against Claude on identical rows
We ran the Claude classifier we use in production, on Sonnet 5, over a random 150 of the same units with the same supplier history.
That is a tie within the noise of 150 rows. Claude's reasoning did not buy it anything on this task, because the information that would separate the hard cases is not in the text either model sees.
The number that matters more than accuracy
An auto-verify gate needs a confidence it can trust. On the 174 whole bills, gating on Jev's confidence at 0.8 would have auto-applied 123 of them, 71%, with zero errors. At 0.9 it was 111 bills, still zero errors. At 0.5, 141 bills at 96.5%. Across all 2,856 units the curve is smoother but has the same shape: 7% of units above 0.95 confidence and 91% of those correct on both, against 33% overall.
That is the property we could not get from the confidence Claude reports about itself, which sits at 0.72 on most invoices whether the pick is obvious or not.
What we would ship, and what we would not
We would not run Jev without the supplier prior. The 28% run settles that.
We would put it in front of Claude. Jev first on every invoice with the supplier history attached, its confidence driving the gate. Above the threshold, apply the pick and let the verifier confirm it in one click. Below it, run the Claude classifier as today. On this data that keeps the expensive call for the bills that need a human anyway.
We would also use it as the first thing that touches a file arriving from email or a shared drive. Is it an invoice, a statement, a cash advance request, a quote? Does it contain more than one document? That question answered in 300 ms for a fraction of a cent, before any extraction spend, is worth having on its own.
Two caveats. TypeSafe has not published calibration metrics and neither has anyone else; our confidence curve comes from one entity's data. And the data goes to a young vendor with no stated region and zero retention only on enterprise plans. We scrubbed individuals and identifiers out before sending; supplier names and line descriptions still went over the wire.
What the data taught us about our own chart of accounts
Every cost center in the entity we tested is typed as overhead, even though a third of the bills are posted to client teams in Xero. None of the GL accounts carry a description hint, so both classifiers chose from bare names, and the chart has triplets of the same account in plain, Billable and Non-Billable form. Adding a one-line hint to each and an employee-to-team lookup for the HMO bills would help both models more than any change to the models themselves. The finance team's own coding, sitting in Xero all along, turned out to be the most useful test set we have.