Typhoon OCR v2 on 189 real bills: the right value found on 3 to 6 more bills per 100

Say you already run something that reads receipts and tax invoices. Every month a hundred or so phone photos of bills come in. Then a launch post shows up in your feed: Typhoon OCR v2, an open Thai OCR model (OCR means reading text out of an image). Its score on Thai document pages went from 64.3 to 81.3, 17 points ahead of the previous version.

The next question comes almost at once: should you switch? A jump that size sounds like most of the misread bills should go away.

Productize tested Typhoon OCR v2 on 189 real Thai bills, the same set we used for every earlier model. We counted bill by bill, against v1.5, whether the model read the total, the vendor tax ID and the document number correctly.

Part 1The criterion: the right number in the right field

When accounting software reads a bill, only a few fields really matter: the total, the vendor's tax ID, the document number, the date. A model can read every Thai word on the bill, but if it puts the VAT amount in the total field, the bill is still unusable.

The main benchmarks Typhoon reports, such as MDPBench and olmOCR-bench, score transcription: how closely the text of the whole page matches the answer key. It is like judging a typist on how completely they copied the page, when the shop needs someone who can point at the number that has to be paid.

So there are two ways to score a bill reader:

• Field scoring. Each value must be correct and in the right field. This is closest to the real job, but it needs a step that assigns values to fields before anything can be checked.
• A screen. Only ask whether the right value appears anywhere in the model's text. No field assignment, no checking. Fast and cheap.

This round we used the screen, because we first wanted to know whether v2 "sees" the numbers that matter more often. A model that cannot find the number at this stage will never pass field scoring. Finding a number does not mean it lands in the right field, though, so this round's results say how many bills the model saw the number on, not how many it filled in correctly. In real use, accuracy will be the same or lower, never higher.

Part 2The models and how we tested them

We compare three models.

• Typhoon OCR 1.5, the previous version, 2B in size (2 billion parameters, small enough to run on a small GPU, the processing card AI models run on).
• Typhoon OCR v2, also 2B. Three things matter if you plan to use it. First, its output tells you where each piece of text sits on the page (a bounding box), and tables come out as HTML you can open as a table. Second, the license is Apache-2.0, but the OpenTyphoon terms apply too. Third, a smaller 0.8B model and builds for ordinary computers (GGUF and MLX) were released alongside it.
• Qwen3-VL 4B, a general vision model we fine-tuned (trained further on data from one specific job) on our own bills. It was not built for Thai in particular. Its results come from our earlier test.

Here are the scores for v1.5 and v2 from the model card (the page the developers publish alongside a model, with its scores, how to run it and its known limits). Higher is better. MDPBench and olmOCR-bench are page transcription tests. ThaiOCRBench is a Thai test with several tasks, including pulling key information out of documents.

We used the same method as for every model we have tried: the same 189 real bills, both photos and scans, each resized so its longest side is 1800 pixels, run on an L4, a small NVIDIA GPU, rented through Modal (a GPU rental service that bills for the time you actually use). For v2 we ran vLLM 0.33.0 (open-source software for running models on a GPU) with the model card's settings verbatim: temperature 0 (so the model answers the same way every time instead of sampling) and the card's own layout prompt (the instruction that tells the model to transcribe the whole page).

Part 3How much better is Typhoon OCR v2 than v1.5 on bills?

Better on all three fields we checked, but by 3 to 6 bills per 100, nowhere near the 17 points the benchmark shows.

The table counts the bills where the right value appears somewhere in the model's text (the screen). For example, v2 found the total on 166 of 189 bills, 7 more than v1.5, or 3.7 points (on 100 bills, 1 point is about 1 more bill found).

The biggest gain is the tax ID, 12 more bills out of 189. The document number (counted over 188 bills) is found on only about 6 in 10 bills by either version. And remember this is the loose screen: once the number has to land in the right field, these figures can only stay the same or drop.

Repetition loops: 11 of 189 bills

11 bills, or 5.8%, made v2 repeat the same characters without stopping. We counted a loop when the same 1 to 6 characters repeated more than 30 times in a row, like "1111…". The worst bill took 278 seconds, about 10 times a typical bill.

We ran the same detector over v1.5's transcripts of the same bills, and v1.5 looped on only 3. So v2's 11 loops are new risk, not something carried over from the old version. As for scoring, a looping bill got no extra penalty: we checked the whole text each model produced, so if the right value appeared before the loop started, the bill still counted as found.

The model card itself says the developers ran a final training stage aimed at repetition loops on photographed pages, and it advises enlarging any image whose long side is under 1600 pixels, because small images make loops more likely. Our images were already above that size, so the roughly 6% of loops we saw are unlikely to come from small images. Some real bills still knock the model off course.

Speed and cost

Half the bills finished within 27 seconds (the median), but the mean was 48 seconds per bill, because the looping bills pull the average up. If you are estimating how many bills you can read per day, plan with the mean, not the median.

The whole test cost about US$2. At US$0.80 per hour for an L4 and 48 seconds per bill on average, that is roughly 1 cent per bill, cheap enough to try on your own bills without asking anyone for a budget.

One small story from the run. The first pass lost 54 bills when the laptop sending the jobs dropped its network connection. The script resumes where it stopped, so a rerun filled in just those 54 bills, without paying for the GPU on the whole set again.

Part 4Why does a 17-point jump become such a small gain?

Because the benchmark scores transcription of document pages, while reading a bill is scored on whether the right number ends up in the right field. The two are related, but they are not the same thing.

Transcription gives credit for every character on the page: paragraphs, headings, tables. On a bill, the part that really has to be right is a handful of numbers and the short labels next to them. A model that got much better at transcribing Thai paragraphs can jump on the benchmark without finding many more bill totals.

The model card says as much. On ThaiOCRBench, the task closest to pulling values off a bill is key-information extraction, where v2 scores 21.0, its weakest task in that benchmark. The developers also warn that extraction output should be checked before it is used downstream.

We had already run into the same thing. In July 2026 we did full field scoring on this same set of bills: Typhoon OCR 1.5 scored 51.9%, while the general vision model we fine-tuned on bills scored 71.8%, and Typhoon was slower too (43.1 against 38.7 seconds per bill). What we concluded then was that a Thai-native model had no edge on this job, because the real work is reading digits.

So the question to ask changes from "which model reads Thai best" to "which model puts the right number in the right field on bills like ours".

Can v2 close that gap of about 20 points? We cannot say yet, because we have not run full field scoring on v2. All we know is that on the loose screen, v2 moved 3 to 6 points past v1.5.

Part 5Which model for which job, and what to watch for

If you asked us based on what we saw this round, the answer depends on the job you have in mind.

Whichever you choose, the system reading your bills should also notice when it has misread one, for example by checking that the pre-tax amount plus VAT equals the total, and sending the bill to a person when it does not. We wrote about that separately.

Part 6Run a small test on your own bills

A benchmark score tells you how much better a model got at reading other people's pages. The most direct way to know how well it reads your bills is to try it on your bills, and it does not need to be big. Our whole round cost about US$2.

1. Collect a hundred or more real bills. Mix photos, scans, faded and crumpled ones, the way they really arrive each month.
2. Write down the correct values for the fields that matter to you. 3 to 5 fields is enough: total, tax ID, document number. Put them in Excel or Google Sheets, one bill per row and one field per column. This is the answer key every model is tested against.
3. Run every model under the same conditions. Same image size, same GPU, each model on the settings from its own model card. Otherwise the results cannot be compared.
4. Screen first. Drop any model that cannot even find the numbers.
5. Field-score the rest. The easiest way is to ask the model to return the value of each field directly, then compare each one with your answer key. If a model only gives you full-page text, you need a step that sorts values into fields first, either another model or rules you write yourself. Count loops, mean time and cost per bill along the way.
6. Save results bill by bill so the script can resume. When the network drops, you will not have to start the whole set over.

If you want to read vendor benchmark claims more critically, we wrote about how to read an LLM benchmark. For running an OCR model on a rented GPU without the budget running away, see our post on Modal.

Next we will try v2 as a second reader next to the main model, to see whether its bounding boxes really help find the document number, and run full field scoring on v2. When the results are in, we will add them here.

In the meantime, if you have a hundred bills sitting in a drawer, that pile is already a better test for you than any benchmark.

Read next: OCR accuracy is not about the model. It is about knowing when it read wrong
Modal GPU on a budget: running a real OCR pipeline
How to read an LLM benchmark without being fooled