AI for address quality in geocoding: clean the input, verify the output

Julien Crétin — Mon, 22 Jun 2026 09:00:00 GMT

The hidden cost of addresses that look resolved but are not, and two ways AI closes it. Measured on 500 real French logistics addresses.

A bad address rarely announces itself. The geocoder returns coordinates, the order looks clean, and the problem only surfaces when a driver is standing in front of the wrong building. In this benchmark, about one in seven of the addresses Google returned as resolved were not the right street and city, and none of them were flagged. By the time a wrong one surfaces it is a failed delivery, a redelivery, a support call, and a customer who remembers it. The expensive part of address quality is not the addresses you already know are wrong. It is the ones that pass silently, all the way to the van.

Two things help, and both can be measured rather than assumed: cleaning the address before it is geocoded, and checking each result before you trust it. We tested both on 500 real French logistics addresses.

There is also a strategic shift behind this. In our European benchmark, a cascade of free OpenStreetMap, HERE, and Google beat Google alone at roughly a fifth of the cost. In France, fully open-source geocoding already rivals a paid Google setup, a result we detail in a companion piece. When the provider you pick stops being the differentiator, what you feed the geocoder and how you verify what it returns becomes the differentiator instead. That is the layer this article is about.

Table of contents:

Why this matters

A national address registry is clean. Real logistics data is not. The addresses that flow through an order management system arrive in capital letters, with accents dropped, house numbers missing, street types abbreviated, and trailing noise from whatever field the data passed through on its way in. On the sample in this benchmark, roughly four addresses in five were fully uppercase, about one in four carried no house number, and a meaningful share had lost accents or been truncated mid word.

Two instincts follow from that mess, and both are worth testing rather than assuming. The first is to clean the input before geocoding. The second is to trust that a provider which returns an answer has actually found the address. Our European benchmark showed the second instinct is dangerous, because the hard part of geocoding is not getting an answer, it is knowing whether the answer is right. This benchmark puts numbers on both instincts, using a language model in each role: once to clean, once to verify.

The test

We took 500 addresses from a real French logistics dataset, deliberately weighted toward the difficult cases that production data actually contains. We geocoded each one through five geocoders reached from a single API: the French national BAN, OpenStreetMap through Photon, OpenStreetMap through Nominatim, HERE, and Google. To isolate the effect of input quality, we ran every address in three versions: raw, cleaned with deterministic regex rules, and cleaned with a language model. That is about 7,500 geocoding calls in total.

Scoring is the hard part, and it is where the language model earns its place a second time. Rather than measure distance to a reference coordinate, we built an LLM-based evaluator that qualifies each returned address against the one that was requested. Throughout this piece, a pass means the result resolves to the right street and the right city, the level of correctness that matters for routing and sectoring. House number precision is a separate question, and we treat it separately. We calibrated the evaluator against 25 hand checked cases before running it at scale, and it agreed with the human verdict on all 25.

One aside worth keeping, because it is a common trap. We reached Nominatim through its public API, which is heavily throttled and capped, and on these messy inputs it resolved about 5%. A self-hosted Nominatim, given enough hardware, does considerably better, but at a real infrastructure cost. The same OpenStreetMap data through Photon resolved the large majority out of the box. The result you get from OpenStreetMap depends far more on the engine and how it is deployed than on the underlying data.

Cleaning the input

Start with the cleaning instinct, because the result is blunt. Deterministic regex rules, uppercasing fixes, abbreviation expansion, separator normalization, did essentially nothing. Across every provider and every difficulty bucket, the rule cleaned input scored within noise of the raw input. Regex tidies the surface. It does not solve lost accents, truncations, or inline noise, which are the failures that actually break a geocode.

The language model is a different story, but a more interesting one than a single headline number suggests. Pooled across providers, LLM cleaning lifted the pass rate from 83.9% to 86.8%, a gain of 2.9 points. That average hides almost everything that matters. The gain is concentrated on the hardest addresses and is close to zero everywhere else.

Pass rate by address type, pooled across all four providers

Address type	Raw	Rule cleaned	LLM cleaned	Gain from LLM
Lost accents	77.2%	76.8%	91.5%	+14.3
Truncated	62.9%	62.9%	71.6%	+8.6
Hard cases overall	68.7%	68.8%	74.8%	+6.0
Clean cases	94.6%	94.8%	95.3%	+0.7
All addresses	83.9%	84.0%	86.8%	+2.9

The ratio is the point. LLM cleaning buys about 6 points on the hard addresses and 0.7 of a point on the clean ones, roughly eight times more where the input is broken. On a clean address, cleaning it again is wasted compute. The single largest effect was on lost accents, the addresses where a character had been replaced by a placeholder, and it held across all four providers, as the next table shows.

Lost-accent addresses only: pass rate by provider, raw versus LLM cleaned

Provider	Raw	LLM cleaned	Gain
BAN	80.4%	91.1%	+10.7
Photon	75.0%	89.3%	+14.3
HERE	78.6%	92.9%	+14.3
Google	75.0%	92.9%	+17.9

Two honest caveats keep this from being overstated. First, our model cleans conservatively: it repairs what is there and never invents what is missing. So on the quarter of addresses that arrive with no house number at all, cleaning lifts almost nothing, because there is nothing to recover. Cleaning repairs, it does not complete. Second, the size of the accent effect depends on how you measure it. A naive text comparison, sensitive to the mangled characters in the raw string, would report a swing closer to thirty points. The geocoders themselves already tolerate some of that damage, so the true lift, measured by whether the address actually resolved, is the +14 above, not +30.

There is a larger point hiding in the regional detail. France is, for this purpose, an easy market: Latin script, a strong national registry, fairly regular conventions. We have run the same preprocessing in markets that are none of those things, and the effect is substantially larger. The messier the local conventions and the further from clean Latin script, the more input cleaning pays. Read the French numbers here as a conservative floor, not a ceiling.

Verifying the output

The cleaning question has a modest, targeted answer. The verification question has a bigger one, and it is the one our European benchmark flagged as the real unsolved problem: deciding whether a result is correct when you have no reference coordinate to check it against.

The usual approaches fail in opposite directions, and a language model corrects both. A simple textual rule, does the input street and number appear in the returned address, is the standard mechanical check. It agrees with our evaluator on the large majority of cases. The disagreements fall into two revealing buckets.

The first is false positives, where the mechanical rule says match but the result is wrong. The classic case is a returned address that shares the input's house number and city but sits on a different street: the tokens line up, the street does not, and a token rule waves it through. A language model compares street against street and rejects it. A token counter cannot.

The second is false negatives, where the rule says no match but the result is fine. These are surface differences that a person reads straight through: minor spelling variants, trailing noise the rule cannot tell apart from the address, postal-format variants, or alternate but equivalent names for the same road. A language model reads through them too. A text rule scores them as failures and quietly discards good results.

The cleanest illustration of why this matters is Google. Google returns a formatted address for every single input in our test, a 100% response rate. Our evaluator confirms the right street and city for 86% of them. The gap is not addresses Google failed to find, it is addresses Google answered without resolving: roughly one in seven Google responses looks resolved and is not. A hit rate, the most common metric teams track, scores all of these as successes. The silent miss is invisible until something downstream goes to the wrong place. This is exactly the layer a language model verifier replaces: it reads the input and the output together and flags the answer that arrived dressed as a success.

Honest limitations

A few caveats matter and we want to name them.

One dataset, one country, one snapshot. These are 500 French addresses from a single logistics source, geocoded once. The directional findings are robust. The second decimal place is not, and another dataset would shift the exact percentages.

The evaluator is itself a model. We use a language model to grade language model cleaning, which is a circularity worth stating plainly. We mitigated it by calibrating the evaluator against hand checked cases and by holding its scoring format fixed, but a model graded benchmark is not a ground truth measured against surveyed coordinates. It measures whether a result reads as correct, which is the same judgment a dispatcher makes, not whether the pin is within a fixed distance of a registry point.

Pass means street and city, not the doorstep. We score correctness at the level that matters for routing. House number precision is a separate axis with a different answer, and we keep it for the open-source piece. Read these numbers as resolution quality, not rooftop accuracy.

Conservative cleaning by design. Our model never fabricates missing data. That is the right choice for trust, but it caps the cleaning lift: an address with no house number cannot be completed, only tidied.

What this means for your stack

If you are running geocoding on real, messy address data, four things follow.

First, drop deterministic cleaning as a quality lever. Regex normalization is fine for storage hygiene, but on these results it moves geocoding quality by nothing. Do not expect a rules pass to recover failed addresses.

Second, treat LLM cleaning as a targeted instrument, not a blanket step. The gain is real but it lives almost entirely on the hard fraction of your data. Clean the addresses your pipeline already struggles with, the ones with dropped accents, truncations, and inline noise, and leave the clean majority alone. Cleaning every address spends compute to buy a fraction of a point on the ones that did not need it.

Third, expect the payoff to scale with how hard your market is. France is a conservative case. If your addresses come from markets with non Latin scripts, weaker registries, or looser conventions, the cleaning lift is larger, sometimes much larger. The harder the market, the higher the return on a local cleaning model.

Fourth, stop trusting your hit rate, and verify the output. A returned address is not a resolved address. The most useful thing a language model does in a geocoding pipeline is not cleaning the input, it is reading each result against its input and catching the silent failures that confidence scores and token rules let through. That verification layer is what lets a cascade run unattended without quietly sending packages down the wrong street.

What comes next

We have kept one half of the story for its own piece. This benchmark measured correctness at the street and city level, where fully open-source geocoding in France is already strong. The rooftop question, how precisely each provider places the house number, and how far the national BAN plus OpenStreetMap can carry a stack with no paid API at all, is a different and equally surprising result. That is the next post.

Methodology recap

For readers who want to audit the analysis:

Dataset: 500 addresses from a single real French logistics source, weighted toward difficult cases (uppercase, lost accents, missing house numbers, truncations, lieu-dit and point-of-interest forms).
Geocoders: BAN, OpenStreetMap via Photon, OpenStreetMap via the public Nominatim API, HERE, Google, all reached through one orchestration API.
Input versions: raw, deterministic rule cleaning, and language model cleaning. The cleaning model is conservative and never invents missing data.
Scoring: an LLM-based evaluator scores each result on house number, street name, postal code, and city. A pass requires the correct street and the correct city. It was calibrated against 25 hand checked cases, with 25 of 25 agreement, before running at scale.
Volume: about 7,500 geocoding calls across the five providers and three input versions.
We report verdicts and aggregate rates only. No individual customer address appears in this article.

Where to go from here

If you are improving a geocoding stack, these go deeper on the pieces this benchmark touches:

The parent benchmark: how we cut geocoding costs by 79% across Europe.
Country deep dive: best geocoding providers in France.
Provider guides: Google Maps Geocoding API, HERE Geocoding API.

Coordable builds multi-provider geocoding cascades with a cleaning and verification layer at every step. If you already run a geocoding stack, we help you improve what you have in place, adding local cleaning and verification models tuned to the markets where generic providers struggle most. Talk to us about your stack.

Coordable (Posts about llm)