Hebrew OCR: what works on real business documents

Since 1 June 2026, an Israeli tax invoice above NIS 5,000 is worthless to the buyer without an allocation number issued by the Tax Authority. No number, no input VAT deduction.¹ That number sits on a right to left page, beside Hebrew text, and it can be checked against a government service. It is exactly the kind of field a document pipeline should capture on its own.

Now look at what the large OCR vendors actually commit to. Amazon Textract supports no Hebrew at all.² Google Cloud Vision reads printed Hebrew but its handwriting support covers nine scripts, and Hebrew is not one of them.³ Azure reads printed Hebrew and stops there.⁴ This article goes through what works, what does not, and what the published numbers really say.

What the published numbers actually say

Hebrew OCR results look excellent or catastrophic depending on which metric you read, and the gap between the two is the whole story.

On printed Rashi script, an AutoML network reached better than 99.8% letter accuracy, with the letter error rate down to 0.164% after book specific refinement.⁸ On handwritten documents, two public Transkribus models report 4.4% and 4.36% character error rate, trained respectively on 159,000 words of nineteenth century community records and just under 5,000 words of Sephardic burial records.¹⁰ Those are good numbers.

Then look at historical Hebrew newspapers from the JPress collection, digitised at scale. The raw OCR reaches 91.44% character accuracy. On the same material, word accuracy is 48.98%.¹¹

That is the number to keep. A page can be 91% correct at character level and still return a field you cannot use, because a field is a word or a number, and one wrong character destroys it. On an invoice, 91% character accuracy on a nine digit identity number means you will get roughly one number in two right. The whole discipline of measuring extraction at field level rather than character level, the same distinction covered in our piece on why OCR errors compound across a document pipeline, exists for this reason.

Frontier vision models do not close the gap either. CHURRO, a 2025 benchmark built on 155 historical corpora across 46 language clusters, names Hebrew among the languages where every model struggles: on its handwritten subset, Hebrew scores 42.3% for the purpose built model and 30.4% for Gemini 2.5 Pro, and the paper notes that even an oracle ensemble reaches only 59.1% on that group of languages.¹² The metric there is a normalised similarity, not a character error rate, so it is not comparable with the Transkribus figures, but the direction is unambiguous.

Why Hebrew breaks OCR built for Latin

Four properties of the script cause most of the trouble, and none of them is exotic.

1. Direction: Hebrew runs right to left, and the Unicode standard requires conformant implementations to apply the Bidirectional Algorithm.⁵ That matters because real documents are mixed: an invoice line holds Hebrew words, Latin product codes and digits, each with its own direction. Get the reordering wrong and the characters are right while the string is wrong. An amount reversed is not a typo, it is a different number.

2. Final forms: Five letters take a different shape at the end of a word, and Unicode encodes those variants as separate characters rather than deriving them by context.⁵ A recognizer therefore has 27 classes, not 22, and five of them are near twins of letters it already has to tell apart.

3. Missing vowels: Vowel points, the niqqud, are combining marks that are usually omitted.⁵ A word is read from consonants plus context. Two spelling conventions coexist, ktiv male which adds vowel letters and ktiv haser which does not, so the same word legitimately appears with different letter counts. Any dictionary or language model tuned on one convention misfires on the other. Liturgical texts add cantillation marks on top, roughly twenty nine of them, placed above, below or between letters.⁶

4. Letters that look alike: This is not a theoretical problem. When Eliyahu Koren designed his Bible typeface in the 1950s he set out to separate the pairs readers confuse, and the three he named are bet and kaf, gimel and nun, dalet and resh.⁷ A measured study of Rashi script OCR found its own worst confusions: nun with kaf, tet with ayin, samekh with mem, tav with het.⁸ In handwriting it gets worse: the dalet stroke was set obliquely precisely to separate it from resh, and in rapid writing it drifts back toward resh anyway.⁹

Add the typefaces. Rashi script, a semi cursive Sephardic hand cast into type in the fifteenth century, carries most rabbinic commentary and has been printed across more than five hundred years of varying foundries.⁸ Modern handwriting is Ashkenazi cursive, a different alphabet again for a model trained on square print.

Which tools support Hebrew, and which support Hebrew handwriting

Vendors answer the question "do you support Hebrew?" with a yes far more often than they answer "do you support Hebrew handwriting?". Here is what their own documentation says.

Hebrew support by vendor, from official documentation

Printed and handwritten Hebrew, as stated on each vendor's own pages in September 2026.

Three things follow:

1. If your documents are handwritten Hebrew, the general purpose clouds are not candidates and a model trained for the job is.

2. If your documents are printed Hebrew with diacritics, check the diacritics specifically rather than assuming they come with the language.

3. And if you run Tesseract from a Linux package, you are almost certainly running the fast variant, which trades accuracy for size.¹³

The Hebrew documents that actually carry business

Archives and manuscripts get the research attention. The volume sits elsewhere, and it is more tractable, because business documents carry fields that check themselves.

a) The tax invoice: The allocation number reform, branded Invoice Israel, conditions input VAT deduction on the invoice carrying a number issued by the Tax Authority. The threshold fell from NIS 20,000 in 2025 to NIS 10,000 in January 2026 and NIS 5,000 in June 2026, skipping a planned intermediate step and arriving years before the 2028 date originally announced.¹⁴ At NIS 5,000 it covers most business to business trade. The Tax Authority also runs a verification service on the number,¹ which means an extraction pipeline can read the field and then confirm it, instead of trusting its own reading.

b) The identity card: The teudat zehut is printed in Hebrew and Arabic, carries a nine digit number whose last digit is a Luhn check digit, and shows dates in both Gregorian and Hebrew calendars.¹⁵ The check digit is the point: a misread digit fails arithmetic, so the pipeline knows it was wrong without a human looking. Our identity document extraction applies exactly this kind of control.

c) The payslip: Amendment 24 to the Wage Protection Law has required a detailed payslip for every employee since February 2009, and omitting mandatory details is a criminal offense carrying a fine.¹⁶ That makes Hebrew payslips a legally standardized, high volume, structured document class, which is the easiest kind to automate well.

The same logic runs through bank statements and receipts. None of these needs perfect character recognition. They need a reading that can be checked.

How to make Hebrew extraction reliable

The approach that works is not a better Hebrew OCR engine. It is a pipeline that assumes the reading is sometimes wrong and is built to notice.

Koncile is an AI document extraction platform rather than an OCR engine. Fields are described in plain language, so a Hebrew invoice model is written by the people who read those invoices, with no template to train and no separate product to buy for a new document type. Documents are classified before extraction, so an invoice and a payslip are not handed to the same reader. Every extracted value carries a confidence score, which is what turns an uncertain Hebrew field into a review item rather than a silent error, and handwritten text is typed as its own field rather than mixed into the printed output.

On top of that sit business rules: recompute the VAT against the line items, run the Luhn check on an identity number, verify an allocation number against the Tax Authority service, confront the name on one document with the name on another. That layer is where a 91% character accuracy becomes a process you can actually run, and it is the same layer behind our document fraud detection, which checks whether a document has been altered rather than only what it says.

The honest limit: no vendor, ours included, should promise you Hebrew handwriting at the level it promises printed Latin. Test on your own documents, measure at field level, and look at the review rate rather than the accuracy headline.

Frequently asked questions

1. Israel Tax Authority, gov.il, application for an allocation number for a tax invoice, consulted September 2026.
2. Amazon Web Services, Amazon Textract quotas and limits, supported languages.
3. Google Cloud, Cloud Vision OCR language support, printed and handwriting tables.
4. Microsoft Learn, Azure AI Document Intelligence, OCR language support.
5. Unicode Consortium, Unicode 17.0 Core Specification, chapter 9, Middle East modern and liturgical scripts.
6. Hebrew cantillation, marks encoded at U+0591 to U+05AF.
7. Koren Type, the pairs Eliyahu Koren set out to separate.
8. Mahpod and Keller, Auto-ML deep learning for Rashi scripts OCR, arXiv 1811.01290, Bar Ilan University, 2018.
9. Cursive Hebrew, the dalet and resh problem in rapid writing.
10. Transkribus, models for handwritten Hebrew and Yiddish, 5 November 2025.
11. Suissa, Zhitomirsky-Geffet and Elmalech, OCR error correction of historical Hebrew texts, arXiv 2307.16213, 2023.
12. CHURRO, a vision language model for historical text recognition, arXiv 2509.19768, 2025.
13. Tesseract, tessdata repository, the three model variants.
14. Herzog Fox & Neeman, overview of VAT updates effective in 2026, 11 January 2026; Sovos, accelerated timeline for the invoice allocation number, 9 December 2025.
15. Israeli identity card, nine digit number with a Luhn check digit.
16. Afik & Co., entry into force of amendment 24 to the Wage Protection Law, February 2009.

Vendor documentation consulted in September 2026. Language support and pricing change often and should be rechecked before relying on them.