Garbled accents in bank CSV descriptions: check the encoding

If a name becomes Café after import, re-read the original file with the correct encoding before editing cells. The bytes may be intact while the decoding is wrong. Keep the raw file; saving the garbled table can make later recovery harder.

Establish source encoding without overwriting the file

1. Check the bank’s export documentation or file metadata for encoding. In the import preview, compare known accented text under the plausible settings.

2. Confirm delimiter and quotation handling separately. Encoding fixes characters, not shifted columns or wrongly parsed amounts.

3. Import a fresh copy and compare descriptions, references and row count. Save a working version without overwriting the raw source.

Fictional example

The fictional source description Café René appears as Café René under an incorrect interpretation. Re-importing the unchanged UTF-8 file with UTF-8 restores it. If the raw source already contains replacement characters �, choosing UTF-8 may not recover the lost text; obtain a better export.

Consider a complete fictional transaction: booking date 2026-09-18, debit 19.80 EUR, reference CB1842, description Café René. An exact lookup against a reconciliation list containing Café René fails when the imported description becomes Café René, although the date, amount and reference still agree. After re-import, check that the original description matches again and that there is still one transaction with a signed amount of −19.80 under the chosen debit convention. Do not create a second payment or force a match by removing accents. The description alone never proves that two transactions are identical.

Find the stage where the description changes

For CB1842, compare three views of the same source: the untouched CSV opened in a text editor with the confirmed encoding, the import preview and the saved working file reopened. Keep date, reference and 19.80 EUR beside the description so you track the same transaction. If the editor is correct but the preview is wrong, revise the import setting. If both are correct and only the reopened output is wrong, investigate that output’s encoding and its next import settings. Do not apply another character replacement to every row.

Import through a text/CSV preview and select the confirmed encoding before loading the data. Start from the untouched export and inspect the description before loading it. This provides an alternative to opening the file by double-clicking; the correct choice still depends on the source encoding.

Record the source, chosen encoding and where the first mismatch appeared. As a proposed acceptance check for this fictional row, require the full original description, CB1842, the same date, one row and the unchanged debit. A readable merchant name with a truncated reference is not a successful repair. If a fresh bank export is already correct, prefer it to trying to reconstruct damaged names from memory.

Diagnose bytes, damaged text and import settings separately

Do not convert the file each time you try a different encoding. Change the reader’s setting against the same untouched bytes and compare the complete description. A correct-looking single word is weak evidence: include several known accents and a reference in the preview. The following table decides which step to investigate.

Observation on a fresh copy	Likely issue to investigate	Next action
Editor shows Café; import preview shows Café	Different decoding between the two readers	Set the importer to the confirmed source encoding
Confirmed source itself contains � where a letter should be	Earlier replacement or lost source text	Obtain the earlier intact export or check the PDF
Accents are readable but columns shift	Delimiter or quote handling	Fix field parsing separately
Preview is correct; reopened delivery is not	Encoding changed during output or next import	Inspect that exact saved file and its reader settings

For a fictional transfer, keep CB1842, date 2026-09-18 and debit EUR 19.80 fixed while testing the description. A second fictional receipt of EUR 50.00 gives a net +30.20. Both a good import and one containing Café can have that same net: money checks do not validate text decoding. Require two transactions, unchanged references and exact descriptions as well as +30.20.

Once the preview is correct, save a separate working file and reopen it through the intended recipient’s method. Record source encoding, output encoding where relevant, delimiter and application/version. If only the delivery fails, repeat from the raw file; avoid saving the already garbled workbook into another encoding and calling that a repair.

Check whether a BOM is present, and verify the reader’s encoding choice against the unchanged source bytes. A BOM helps an application recognize an encoding; it does not restore letters already replaced upstream. An encoding choice also does not normalize names, remove accents or establish that two merchants are the same entity. If different settings each produce plausible text, retain the ambiguity until export documentation or an intact source resolves it.

Checks and limits

Test more than one accented character and inspect the saved file after reopening. Do not remove accents to make an import look clean: that changes the source description. Power Query’s Csv.Document provides an encoding option; use the encoding established for this file, not a universal guess.

Keep the original file unchanged and record any unresolved item before using the table.

Related checks

Preserve descriptions and references together when decoding CSV changes characters. Bank statement descriptions split across rows: join them safely · Bank references in Excel: protect long IDs and leading zeros · Check a bank CSV before opening it in Excel.

BankStatementScan is in preparation. The site offers an access request and a fictional example; it does not currently convert your bank files. See the planned service.

Sources consulted on 16 October 2026

• Unicode — UTF and BOM FAQ.