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 two experiments.
The setup
We used a first batch of 450+ 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. A third of them were scans with no text layer. The candidate lists came straight from the live system: 65 expense accounts from the chart and 17 cost centers with their descriptions.
Both classifiers got identical input: the fields Claude had extracted, the same candidate lists, no supplier history and no defaults. That is a handicap compared with the production setup, where the classifier also sees what a supplier was classified to before, but it keeps the comparison fair.
For Jev we asked six questions in one call: overhead or delivery cost, which cost center, which GL account, and three yes/no signals the Claude prompt already uses (does the invoice name a client project, is it billed as hours times a rate, is the description too vague to classify).
Document type: 450 for 450
The triage test was the cleanest result. We gave Jev the raw text from pdftotext, or from tesseract OCR for the scans, and asked what kind of document it was from the ten types the parser knows. Then we asked the same question a second way, using the extracted fields with the parser's own answer stripped out.
Both variants agreed with Claude's parser on all 450: 350 invoices, 50 cash advance requests, 50 statements. Median latency was around 0.3 seconds. The whole stage, 900 calls, cost five cents.
The 100 lower confidence answers were more interesting than the 350 certain 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 the behaviour 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.
GL account and cost center: where each one was right
On the cost center the two agreed on 350 of 450. On the GL account they agreed on only 150. The accounting team had already classified every document in the batch, so we scored both classifiers against their answers rather than against a reading of our own.
Where Jev looked right and Claude did not:
Where Claude looked right and Jev did not:
150 documents were textbook and both got them. The cash advance request is a genuine argument about whether a client funded training event is billable, and that argument belongs to finance.
Tally on the GL account: Jev ahead on 200, Claude ahead on 50, 150 ties, 50 where both were wrong. On the cost center: Claude ahead on 100, the rest ties. Claude's cost center edge came entirely from reading the hint text on the cost centers. Jev's GL edge came from not over-reaching.
The number that matters more than accuracy
An auto-verify gate needs a confidence it can trust. Today the gate uses the confidence Claude reports about itself, and that number is not well calibrated. It sits at 0.72 on most invoices whether the pick is obvious or not.
Jev's confidence was low exactly where it was unsure. Every contested GL account came back between 0.42 and 0.55. Where it was certain it was also sensible: 0.99 on IT for the software licences, 0.95 on recruitment for the placement fee, 0.85 on visa expenses for the immigration invoice. 450 documents from one entity is still a narrow sample. It is still the property that would let us auto-apply the confident picks and send only the contested ones to a person.
Speed and cost
The Jev call is fast enough to run while the user is still looking at the upload screen, and cheap enough that asking a dozen extra speculative questions per invoice costs nothing worth measuring.
What we would ship, and what we would not
We would not replace the Claude classifier with Jev. On this sample it trails on the cases that need context, and TypeSafe's own published invoice benchmark puts it well behind Opus on accuracy.
We would put it in front. Jev first, on every invoice, with 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 batch that would have kept the expensive call for roughly half the invoices and made the other half instant.
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 we are carrying into the next round. TypeSafe has not published calibration metrics, and neither has anyone else; our confidence observations are from one entity's mix. And the data leaves your cloud to a young vendor with no stated region and zero retention only on enterprise plans. Supplier names and line descriptions went over the wire in this test. Tax IDs and invoice numbers did not need to, and would not in production.
Two findings that had nothing to do with Jev
Every cost center in the entity we tested is typed as overhead. That makes the overhead versus delivery question moot there, even though Jev flagged 150 documents as client related. And none of the GL accounts carry a description hint, so both classifiers chose from bare account names. Every disagreement fell on a billable versus non billable pair. Adding a one line hint to those accounts would help both models, and costs nothing.
The next batch is larger, with the finance team's own answers attached, so the accuracy numbers here will get replaced by real ones.