OCR Non English Bank Statement Pages: Accents, Scripts

OCR on a non English bank statement works when the engine is told the statement's language before it reads. That setting lets it recognize accented letters and other alphabets correctly. After OCR, the local formats need care: many countries print dates day first and use a comma as the decimal mark, so 1.234,56 means 1,234.56 in US notation.

Why does OCR need a bank statement's language setting?

An OCR engine reads each character by comparing its shape with the characters of a chosen language, and it uses that language's word lists to settle close calls. Left on English, it has no "ü" or "ç" to match, so it picks the nearest English letter instead. The result is plausible-looking text with the wrong letters.

Language also guides word-level guesses. When a smudged character could be "e" or "c", an engine leans toward whichever choice makes a real word in its dictionary. On a German statement, "Überweisung" is a common word. An English dictionary does not know it, so the engine has nothing to lean on and the error rate climbs.

Some engines assume English unless told otherwise. The Tesseract command-line usage notes state that English is assumed by default when no language is given, and that a three-letter code such as deu for German selects another. Many desktop and online tools expose the same choice as a language dropdown, sometimes hidden under advanced options. Find it before the first run.

Language is only one input. A crooked page or a speckled background hurts any language, and straightening a scanned PDF with deskew and cleaning speckles and shadows off a scan both come before the language matters.

Accented payee names on a non-English statement

Accented payee names are where a wrong language setting shows first. With English selected, "Café Müller" can come back as "Cafe Muller", "Caf6 M0ller" or "Cafè Mûller". The first is merely stripped, while the others are actual misreads where the engine guessed a different mark.

Why this matters depends on what you do with the names:

• Reading. Stripped accents barely matter. A person still recognizes the payee.
• Searching and filtering. A filter for "Müller" will miss rows that came back as "Muller", and the reverse.
• Category rules. A budgeting app or bookkeeping rule that matches on the exact payee text will treat the two spellings as different merchants.
• Totals by payee. A pivot table splits one payee into two lines if half the rows kept the accent and half lost it.

The fix after OCR is consistency, not perfection. Pick one spelling for each recurring payee and replace the variants with Find and Replace. If the statement is a long one, sort the description column and look for near-duplicates side by side, which makes the variants easy to see.

Small marks are also the first casualties of a coarse scan. A cedilla or an umlaut is only a few pixels at 300 DPI, so for statements with many accented names, scanning a little higher helps.

Cyrillic, Greek and other alphabets on bank statements

Statements in a non-Latin script, such as Cyrillic, Greek, Arabic, Hebrew, Chinese or Japanese, need a language pack for that script. Without it, the engine has no matching shapes at all and returns symbols or Latin look-alikes. With it, the descriptions come back in the right alphabet, and the digits, which are usually Western Arabic numerals, read normally.

Look-alike letters are the hidden trap. Cyrillic "А", "В", "Е", "К", "М", "О", "Р", "С" and "Т" look identical to Latin letters but are different characters. A payee name can come back with a mix of both, which looks right on screen and still fails a search or a match. If a filter for a name that is clearly on screen returns nothing, mixed alphabets are the likely cause.

Right-to-left scripts, such as Arabic and Hebrew, add a layout question. The description reads right to left while amounts read left to right, and the column order on the page may be mirrored from what you expect. Check that the date, description and amount columns in Excel map to the right columns on the page before trusting any row.

Chinese and Japanese statements often print dates with characters, as in 2026年3月31日, and use full-width digits on some layouts. Full-width digits look like normal numbers but are text to Excel. Converting them with a helper formula, or with Excel's ASC function in versions that support it, turns them into ordinary numbers.

Local date and number formats on foreign statements

Local formats are the biggest source of silent errors after OCR on foreign statements. Day-first dates read as month-first swap days and months, and a comma decimal read as a thousands separator inflates an amount a hundredfold. The OCR can be letter-perfect and the spreadsheet still wrong.

The table below gives example formats for five statement languages. The values are illustrative. Banks vary, so check against your own statement.

Read the labels column before you set signs. "Soll" on a German statement is money out, even though its position may match where an English statement puts deposits. Getting this wrong flips every sign on the sheet.

To import such a file correctly, use Excel's text import or Power Query and set the column's locale to the statement's country. That tells Excel to read 31.03.2026 as 31 March and 1.234,56 as 1234.56, without changing your own system settings. Opening the file directly and fixing dates afterwards is much harder, because a US-set Excel may already have turned a French 04/03/2026 into 3 April, a valid date that is simply wrong.

A quick test for day-first dates

Before you trust a converted date column, look for any day above 12. A date printed as 25.03.2026 can only be day first, so it tells you how the whole statement is written. Then sort the column. Transactions on a statement run in date order, so a sorted column that jumps from January to March and back again is a sign that some rows were read month first and others day first. That mix happens when Excel converts the ambiguous dates, such as 04/03, and leaves the impossible ones, such as 25/03, as text. A column with both right-aligned and left-aligned cells is the visible clue.

Do statement accents survive the CSV and Excel step?

Accents survive the CSV and Excel step only when the file's text encoding is read correctly. CSV files from most modern tools use UTF-8. If Excel opens a UTF-8 file as an older encoding, "é" turns into "é" and "ü" into "ü". The OCR was right and the file is right; the reading is wrong.

That garbled pattern, a capital A with a tilde followed by another symbol, is the signature of UTF-8 read as something else. It is not a scan problem, so rescanning will not help. Import the CSV through Data, From Text/CSV and choose UTF-8 as the file origin, and the accents return.

Excel's own XLSX format stores text in a way that avoids this, so if your converter offers XLSX, choose it for accented statements. When a CSV is needed for another app, test one file with a known accented payee before importing a year of them.

The same rule applies to images converted directly. A phone photo of a foreign statement goes through the same language and encoding steps, and turning a photo or screenshot into Excel rows covers the photo side of the job.

Two-language statements and setting two OCR languages

Many statements mix two languages: a local-language layout with English merchant names, or an English layout with local payees. Most engines let you select more than one language at once, so both sets of letters and words are available. Tesseract, for instance, takes two codes joined with a plus sign, such as eng+deu.

Do not add languages "just in case". Each extra language gives the engine more look-alike characters to choose from, and a statement in German and English gains nothing from Polish and Czech being selected too.

After the run, spot-check the words that carry meaning rather than the merchant names. The labels for balance, money in and money out, and the statement period, are the ones you will build formulas on. If "Kontostand" came back as "Kontostaud", any formula that looks for the label fails even though a person reads it easily. Fix those few labels by hand and the rest of the sheet can follow.

Statements from foreign banks sometimes arrive packed together, for example as a year of monthly PDFs in one archive from an online banking export. Unpack them and check each one before conversion, as handling bank statements that arrive in a zip file explains.

If the statement is a digital PDF rather than a scan, none of the OCR language issues apply: the text, accents included, is already inside the file. The date and number formats still need care. FastBankConvert is built to read the statement layout and put dates, descriptions and amounts in their own columns, and it is getting ready to open; you can join through Get started.