Jev vs invoice OCR
Invoice OCR turns pixels into strings and boxes. Jev accepts text only. Official models page: no image, audio, or video input. People confuse “understand this invoice” with extraction.
Unofficial. TypeSafe cookbooks: regex/LLM extract candidates, then Jev picks a span or checks a claim. docs.typesafe.ai.
Comparison scope
Line items, tax IDs, and totals should be parsed. Jev can ask “does this look like a duplicate of invoice 1044?” or “is the vendor name the same entity as the PO vendor?” on text you extracted.
Criteria that decide the architecture
| Axis | Jev (System One) | Invoice OCR |
|---|---|---|
| Pixels | Not accepted | Wins |
| Pick among candidate amounts | Choice over regex hits | OCR confidence |
| Date arithmetic | Code after extraction | Your AP system |
| Totals check | Code | Code |
Decision quality and control
Jaggedness: counting line items and comparing dates in the model is the wrong split. Official date cookbook: extract parts as Choice, assemble in code.
Integration trade-offs
OCR/vendor extract → candidates in state → Jev Choice/Noul → AP rules. Never POST a PDF.
TypeSafe’s public models page lists jev-1.13 at $0.042 per million input tokens with output tokens free — a vendor claim, not a jev.pro measurement. Confirm on the models page before you bid.
When each approach fits
Prefer Jev when
- You already have text and need a judgment
Prefer Invoice OCR when
- You still need characters from an image
OCR extract; Jev judge; ERP posts. Humans on low confidence.
Candidates in state, never a PDF
Pixels never go to System One. Official models page: no image, audio, or video input. Sketch: OCR / AP vendor extracts strings and boxes → regex or cookbook extractors produce candidate amounts, dates, and vendor names in state → Jev Choice picks among those spans or Noul “looks like a duplicate of invoice 1044” → AP rules post. Pin jev-1.13.0. Never POST the PDF bytes.
TypeSafe cookbooks (pre-parsed value extraction, date extraction) are the intended split: extract parts as Choice, assemble in code. $0.042 / M input is a vendor claim; sending the full OCR dump of a 40-page statement is how you pay for unused tokens and, per jev-1.13 jaggedness, get worse answers.
How AP “AI” invents a total
- Date arithmetic in the model. Official date cookbook: extract parts, compare in
datetime. Do not ask “is this due before the PO?” - Counting line items. Jaggedness: math. Count in code; ask a language question about a named remainder (“does the memo mention a rush fee?”).
- OCR confidence as Jev confidence. Different objects. Low OCR should not reach the model; high OCR can still be the wrong vendor entity.
- Schema-safe pick as the true amount. A valid Choice among regex hits is not “the invoice totals correctly.” Totals stay in the ERP.
- Generation of a dispute letter. Jev does not write AP email. Your template + a human does.
When not to use Jev here
Do not use Jev while you still need characters from an image. Do not use it to invent a unit price or to replace three-way match. Prefer OCR + ERP when the remainder is empty. Use Jev only when you already have text and need a judgment on that remainder.
What this page does not claim
-
Not an OCR vendor compare.
-
No claimed extraction F1.
-
Schema-safe output is not the same as factual correctness.
-
No independent bake-off numbers live here.
FAQ
Will Jev read a PDF? Not as bytes. Extract text first.
Handwritten invoices? That’s an OCR problem, then the same text pipeline.
Can Score become the invoice total? No. Do not interpolate a dollar amount from Score levels (official numeric warning).
Disclaimer
This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.
Hub: Comparisons. Siblings: vs kyc vendors, vs finance approvals, data handling. Canonical: https://docs.typesafe.ai.