When Müller becomes Müller: the encoding bug nobody plans for
Accented characters that turn to gibberish in your automation look cosmetic and quietly corrupt your customer data anyway. Where the bug comes from and how to shut it down.
I once spent an afternoon talking a client out of calling a lawyer. He was convinced his customer database had been hacked. Names had turned to garbage overnight: "Müller" where "Müller" used to sit, "Schäfer" instead of "Schäfer." Nobody had touched the database. What he had was an encoding bug, and it had been quietly rotting his data for weeks before anyone looked closely enough to notice.
The garbled output has a name: mojibake. It shows up when one system writes text in one character encoding and the next system reads it in another. The bytes are perfectly intact. Only the interpretation is wrong. That one distinction is the whole story, and it is why the problem looks cosmetic while doing real harm.
Two systems, two assumptions
A computer never stores a letter. It stores numbers, and a character encoding is the lookup table that maps letters to those numbers. The sane default today is UTF-8, which covers essentially every character you will ever need. The trouble is the older Windows encodings, Windows-1252 and Latin-1, which map an accented character to a different number than UTF-8 does.
As long as one system writes and reads its own data, nothing breaks. The damage starts at the border between two systems. A legacy tool exports a file as Windows-1252, the next tool reads it as UTF-8, and every accented character turns into a little cluster of wrong ones. Nothing crashed. Nothing threw an error. The data just quietly went wrong, which is the worst way for it to go wrong.
Where it sneaks into automation
Three spots account for almost every case I run into.
The first is the CSV export from a legacy system. Plenty of ERP and accounting tools still export in Windows-1252 by default. Feed that file into Make, n8n, or an import script that assumes UTF-8, and every accented character breaks.
The second is Excel. Let someone open a clean UTF-8 file in Excel and save it back as CSV, and Excel on Windows will often re-encode it or stamp an invisible marker called a BOM onto the front of the file. The BOM shows up as  glued to your first column header and breaks whatever tries to read that column.
The third is webhooks and APIs where the sender forgets to declare the encoding in the header. The receiver has to guess, and it does not always guess right.
Why nobody catches it early
The real reason this slips through is how we test. You build an automation, you test it with "Test Test" or some fake name, and there is not a single accented character in the whole run. The happy path passes, everything ships, and the first real "Schäfer" only turns up in production. By the time someone notices, three hundred emails may already have gone out with a mangled greeting, or three hundred broken records are sitting in the CRM feeding everything downstream.
Names are only the visible part. Street names, cities, product descriptions, free-text notes from support, all of it carries accented characters. A broken address becomes an undeliverable shipment, and that costs a lot more than an awkward salutation.
The repair that makes it worse
Once the garbage is there, a second mistake tends to compound it. Someone sees Müller, shrugs, and runs the file through another guessed encoding hoping it will sort itself out. It does the opposite. A character that was misread once becomes an even longer mess on the second wrong pass, and at that point reconstructing the original is close to impossible. I have opened databases where the same ü had taken on three different broken forms over the years, depending on how many times a given record had passed through which tool. Fix it at the source, never at the symptom. And take a copy before any repair attempt, because otherwise you risk destroying the last readable version you had.
Fixing it for good
The good news is that these bugs are completely preventable once you know where to look.
Make UTF-8 the mandatory standard for every export, every import, every interface. It is the only encoding you need, and every exception to it is a future bug waiting for a customer with an umlaut.
Check what your legacy system actually writes. If it can only produce Windows-1252, put a conversion step directly behind the export, not three stops later once the corruption has already traveled halfway down the chain.
Keep Excel out of the pipeline wherever you can. The moment a human opens a file in Excel and saves it, you have lost control of the encoding. Machine-to-machine handoffs are far more reliable here.
And test with real data. Put a "Müller," a "Schäfer," and a euro sign into your test set before anything goes live. One test record with an accented name and a currency symbol catches the large majority of these bugs before a customer ever sees one.
Encoding looks like a technical footnote you can hand to the developers and forget. In practice it decides whether your customer data stays clean or quietly decays. And "quietly" is the dangerous word here. A crash gets noticed within minutes. A "Müller" slips in and stays until a customer complains.