Why does Hebrew text come out reversed in my Excel export?

Because directionality is handled by whatever renders the text, not by whatever wrote it. A browser runs the bidirectional algorithm; Excel and PDF libraries behave differently. The reliable test: if the text looks right in the conversation and broken in the file, the problem is in the file. Mixed Hebrew-and-number lines are where this shows up most.

Should I write my prompts in Hebrew or English?

In Hebrew when the output is Hebrew that a customer will read. Asking in English for Hebrew output tends to produce text that is grammatically fine but sounds translated. For operational content - summaries, documentation, internal drafts - the difference does not really matter. For marketing copy it matters a great deal, and a person writing with AI helping around it beats the reverse.

Can Claude read scanned Hebrew invoices?

A typed PDF, where the text exists in the file, works well. A scanned PDF is essentially an image and depends on scan quality - and many Israeli invoices arrive as phone photographs with a stamp over the figures. Test with the actual documents that reach you including the poor ones, and where money is involved, have a human verify exceptions: a wrongly extracted number is worse than a missing one because it looks correct.

Can I upload customer documents containing personal data?

That is a policy and legal question rather than a technical one, and in a regulated business it belongs with a lawyer rather than with whoever operates the tool. It is not a formality either: in Israel many of the documents people most want analysed - invoices, contracts, forms - are precisely the ones holding names, ID numbers and payment details.

Claude in Hebrew - Yehonatan Saadia

Q: Is Claude good at Hebrew?

Comprehension and generation are rarely the bottleneck - reading, summarising, extracting, rewriting and translating Hebrew all work well. What breaks is downstream: the exported file, the email, the PDF, where directionality is handled by other software entirely. Separating those two questions is what makes the problem diagnosable.

Hebrew comprehension is rarely the problem. What breaks is everything downstream - the exported file, the mixed Hebrew-and-number line, the PDF - and knowing where the failure sits saves you from blaming the wrong thing.

The question people ask is "is Claude good at Hebrew", and it conflates two things. Hebrew comprehension is rarely the bottleneck. What breaks is everything downstream - the file that comes out, the line mixing Hebrew with numbers, the PDF sent to a customer. Knowing where the failure actually sits saves hours of blaming the wrong thing.

Two different questions

Worth separating, because they are solved differently:

The question	Where it breaks
Does it understand and produce Hebrew?	Usually not the problem
Does the Hebrew survive the way out?	Almost everything, here

"The way out" is anything that is not the chat screen: an Excel file, a PDF, an email, a paste into another system. There, directionality is handled by different software - and that software has nothing to do with Claude.

The recurring failure: Hebrew mixed with numbers

If there is one thing to take from this article, it is this.

Pure Hebrew works. Hebrew with numbers, identifiers or Latin terms is where it breaks: a tax invoice number inside a Hebrew sentence, a phone number, an alphanumeric SKU.

Why it happens: numbers and punctuation are directionally "neutral" - their direction is decided by what surrounds them. So a hyphen between digits, a bracket, or a full stop can jump to the wrong place.

And what matters: this is a problem of whatever displays the text, not of whatever wrote it. The exact same text can look correct in a browser and broken in Excel, because the browser runs the bidirectional algorithm and Excel behaves differently. Full detail in Hebrew and RTL in business software.

The test that separates them: if the text looks right in the conversation and broken in the file - the problem is in the file. If it is already broken in the conversation, that is a different issue.

What does work well

Reading and summarising Hebrew documents.
Extracting data from a Hebrew document into a table.
Rewriting - shortening, simplifying, changing tone.
Translating in both directions, including professional terminology.
Comparing two documents and finding the differences.

These share something: the output is text you read, not a file sent onward. The moment the output goes to a customer, the rendering layer enters - and that is a different place.

Phrasing: write in Hebrew when you want Hebrew

A practical point easily missed.

If the output should be Hebrew going to a customer, write the instruction in Hebrew. Asking in English for Hebrew output tends to produce text that sounds translated - grammatically fine, and not sounding like someone who wrote in Hebrew.

And this is worth being straight about: Hebrew marketing copy is where that gap is most visible and matters most. A customer message that sounds translated costs more than it saves. For sales copy, a tagline or brand text - better that a person writes it and AI helps around it: generating variations, shortening, checking consistency.

For operational content, by contrast - a summary, documentation, an internal email draft, a spec - that gap does not really matter.

Scanned documents - a difference worth knowing up front

There is a large difference between two things that look identical:

A typed PDF	A scanned PDF
The text exists in the file	The file is essentially an image
Works well	Depends on scan quality

With Israeli invoices this is very relevant: many arrive scanned, sometimes as a phone photo, with a stamp or signature over the figures.

What to do: do not conclude from a clean sample. Test with the real documents that reach you - including the bad ones. If 30% of your invoices are crooked photographs, that is the real input, and that is what determines whether the process works.

And in any flow extracting numbers from documents: a wrongly extracted number is worse than one not extracted, because it looks correct. Where money is involved, exceptions need human verification rather than trusting extraction alone.

A checklist for testing this properly

Before deciding it works for your business:

Test with a real document, including a poor one.
Check the output where it is going - the file, the email, the system - not only on screen.
Test a mixed line - a Hebrew name, a document number and an amount together. That is the case that breaks.
Test an Excel export if that is where the result lands.
Write the instruction in Hebrew if the output is Hebrew.

What remains your decision

If the documents contain customer data - names, ID numbers, payment details - what may be passed to an external service is a policy and legal question, not a technical one. In a regulated business that is a question for a lawyer rather than for whoever runs the tool.

And this is not a formality: in Hebrew and in Israel, many of the documents people want analysed are precisely the ones holding personal information.

Using Claude in Hebrew: What Works and Where It Breaks

Key takeaways