Levenshtein vs Jaro-Winkler for PO Number Matching Permalink to this section#

↑ Part of Exact vs Fuzzy Matching Strategies.

Once a reconciliation pipeline has decided to score PO numbers instead of hash-joining them, the next decision is which string metric drives the score. This is not a stylistic choice: normalized Levenshtein similarity and Jaro-Winkler answer structurally different questions about two identifiers, and picking the wrong one either buries valid revisions in the dead-letter queue or auto-accepts pairs that only look alike because they share a prefix. This page is scoped to that single decision — which scorer to pin for short, structured PO identifiers — not the broader question of when to leave exact matching at all, which is covered in When to Use Fuzzy Matching Over Exact PO Matching.

Operational Trigger Signals Permalink to this section#

Choose the scorer based on the shape of the drift your PO numbers actually exhibit, not on which library is already imported. Each signal below is something you can pull directly from a sample of unmatched pairs:

1. Revision or suffix appends (PO-88421 vs PO-88421A, -R1, -V2): the two strings share a long common prefix and differ only near the end. Jaro-Winkler’s prefix boost was built for exactly this shape and separates true revisions from noise far better than raw edit distance.
2. Digit transpositions from keying or EDI translation (PO-88421 vs PO-88412): two adjacent characters swap. Levenshtein counts a transposition as two substitutions and depresses the score more than the error deserves; Jaro’s matching-window logic tolerates transpositions natively.
3. Insertions or deletions distributed across the string (a leading PO- stripped by an upstream system, or a zone code spliced into the middle): here the common-prefix assumption breaks down, and normalized Levenshtein similarity — which counts every edit uniformly regardless of position — tracks the true amount of drift more faithfully than a prefix-weighted score.
4. Short-prefix collisions across a high-volume feed (PO-10001 vs PO-19999): when two genuinely different POs happen to share only the first few characters, Jaro-Winkler’s boost can inflate a mediocre Jaro score into a false near-match. Below the boost threshold, most Jaro-Winkler implementations withhold the boost entirely, so the two metrics converge — worth knowing before you assume Jaro-Winkler always scores higher.

The pattern across all four: Jaro-Winkler rewards shared beginnings, Levenshtein penalizes total edit volume. A blanket “always use Jaro-Winkler for short strings” rule fails on signal 3, and a blanket “always use Levenshtein” rule fails on signals 1 and 2.

Because Jaro-Winkler systematically scores higher than Levenshtein on the same pair, the two metrics are not interchangeable at a shared threshold — a 0.90 floor is lenient for Levenshtein and comparatively strict for Jaro-Winkler. Calibrate each scorer’s floor independently against a labeled sample rather than reusing one number across both.

Normalized Levenshtein similarity converts raw edit distance $d(a, b)$ — the minimum number of insertions, deletions, and substitutions to turn $a$ into $b$ — into a bounded score:

Every edit costs the same regardless of where it falls in the string, which is exactly why it is the more honest metric for insertions and deletions scattered across a PO number. Jaro similarity instead counts matching characters within a proximity window and half-weights transpositions:

where $m$ is the number of matching characters (within a window of $\lfloor \max(|a|,|b|)/2 \rfloor - 1$) and $t$ is half the number of transpositions among them. Jaro-Winkler then adds the prefix boost that gives the metric its name:

$\ell$ is the length of the common prefix, capped at 4 characters, and $p$ is a scaling factor — rapidfuzz and most implementations default to $p = 0.1$, so at most 40% of the remaining gap to a perfect score is closed by the prefix alone. Most implementations, including rapidfuzz, also gate the boost behind a minimum Jaro score (commonly 0.7); below that floor the prefix contributes nothing, which is why scenario 4 above converges to the plain Jaro value instead of an inflated one.

Step-by-Step Implementation Permalink to this section#

Pin the scorer per field rather than deciding at call time, and log both metrics during calibration so you can see where they disagree before committing to one in production:

1. Sample the residual — pull a labeled batch of unmatched PO pairs from the exact-join residual, including known true positives (real revisions) and known true negatives (unrelated POs).
2. Score every pair with both metrics — run Levenshtein.normalized_similarity and JaroWinkler.similarity over the same sample so the comparison is apples-to-apples.
3. Plot the disagreement — pairs where the two scores diverge by more than roughly 0.15 are the ones that will flip status depending on which scorer you pick; inspect these manually.
4. Pick the scorer per field shape — if the sample is dominated by suffix/revision drift, pin Jaro-Winkler; if it is dominated by distributed insert/delete drift, pin normalized Levenshtein.
5. Calibrate the floor independently — do not reuse a Levenshtein threshold for Jaro-Winkler; recompute the floor against labeled true/false positives for the chosen metric.
6. Log the decision — persist which scorer and threshold produced each auto-match so the choice is auditable, not just fast.

import logging
from dataclasses import dataclass

from rapidfuzz.distance import JaroWinkler, Levenshtein

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)


@dataclass(frozen=True)
class ScorePair:
    """Both metric scores for one candidate PO pair, kept together for auditing."""

    invoice_po: str
    ledger_po: str
    levenshtein_sim: float
    jaro_winkler_sim: float

    @property
    def divergence(self) -> float:
        """Absolute gap between the two scores; large gaps need manual review."""
        return abs(self.jaro_winkler_sim - self.levenshtein_sim)


def score_po_pair(invoice_po: str, ledger_po: str) -> ScorePair:
    """Score one PO pair with both metrics so the choice of scorer is inspectable."""
    lev_sim = Levenshtein.normalized_similarity(invoice_po, ledger_po)
    jw_sim = JaroWinkler.similarity(invoice_po, ledger_po)
    return ScorePair(invoice_po, ledger_po, lev_sim, jw_sim)


def benchmark_po_samples(
    samples: list[tuple[str, str]],
    divergence_flag: float = 0.15,
) -> list[ScorePair]:
    """Run both scorers across a labeled sample and flag pairs where they disagree.

    samples: (invoice_po, ledger_po) tuples drawn from the exact-join residual.
    divergence_flag: gap above which the two metrics would route the pair
        differently, and manual review is required before pinning a scorer.
    """
    results: list[ScorePair] = []
    flagged = 0
    for invoice_po, ledger_po in samples:
        pair = score_po_pair(invoice_po, ledger_po)
        results.append(pair)
        if pair.divergence >= divergence_flag:
            flagged += 1
            logger.warning(
                "scorer divergence %.3f on %r vs %r (lev=%.3f, jw=%.3f)",
                pair.divergence, invoice_po, ledger_po,
                pair.levenshtein_sim, pair.jaro_winkler_sim,
            )
        else:
            logger.info(
                "%r vs %r: lev=%.3f jw=%.3f", invoice_po, ledger_po,
                pair.levenshtein_sim, pair.jaro_winkler_sim,
            )
    logger.info("benchmarked %d pairs, %d flagged for divergence review", len(results), flagged)
    return results


if __name__ == "__main__":
    po_samples = [
        ("PO-88421", "PO-88421A"),   # revision suffix append
        ("PO-88421", "PO-88412"),    # adjacent digit transposition
        ("PO-88421", "PO-94821"),    # distributed leading-digit drift
        ("PO-88421", "88421"),       # stripped PO- prefix
        ("PO-10001", "PO-19999"),    # short-prefix collision, unrelated POs
    ]
    benchmark_po_samples(po_samples)

Run this against a few thousand labeled residual pairs before committing a scorer to production; the divergence field is the signal that tells you whether your PO population actually needs the distinction this page is making, or whether either metric would land on the same decision.

Configuration Reference Permalink to this section#

Debugging & Recovery Permalink to this section#

• Threshold reuse across scorers — the most common calibration bug is copying a Levenshtein floor onto Jaro-Winkler (or vice versa) after a scorer swap. Because Jaro-Winkler systematically scores higher, a reused floor silently loosens the auto-accept gate; re-run the divergence benchmark any time the scorer changes.
• False confidence from short-prefix collisions — if the DLQ shows Jaro-Winkler auto-accepting unrelated PO ranges that merely share a leading digit or two, the floor is too low relative to $\ell_{max}=4$; either raise the floor or fall back to normalized Levenshtein for that PO range, which does not carry the prefix bias.
• Silent scorer mismatch at scale — when a feed has millions of candidate pairs, blindly pairwise-scoring every invoice against every open PO is the performance bottleneck long before the metric choice matters; pre-filter the candidate set with the technique in Blocking Strategy Selection for High-Volume Supplier Feeds before either scorer runs.
• Divergent-pair backlog — pairs flagged by the divergence check above should route to manual review, not to whichever scorer’s answer you prefer that day; a growing backlog of divergent pairs is itself a signal that the PO population’s drift pattern has shifted and the pinned scorer needs re-evaluation.
• Audit trail — log the scorer name, its version-pinned threshold, and both raw scores (not just the winning one) with every auto-match, the same discipline the Matching & Reconciliation Algorithms engine applies to every other fuzzy decision it commits.

FAQ Permalink to this section#

Can I just run both metrics and take the higher score? Permalink to this section#

No — that silently defeats the calibration you just did. Taking the max of two differently-scaled metrics biases every decision toward whichever one runs hotter on average, which is Jaro-Winkler. Pin one scorer per field based on its dominant drift pattern, and use the divergence check only to flag pairs for manual review, never to pick a winner automatically.

Is Jaro-Winkler always a safe default for short identifiers like PO numbers? Permalink to this section#

Not when the drift includes stripped prefixes or spliced mid-string codes. Jaro-Winkler’s advantage comes entirely from the prefix boost; once that assumption breaks, as in a leading PO- stripped by an upstream system, it degrades to a plain Jaro score with no benefit over normalized Levenshtein, and normalized Levenshtein tends to track the true edit volume more faithfully in that case.

Do I need Damerau-Levenshtein instead, since it handles transpositions directly? Permalink to this section#

If transposed digits are the dominant error mode and you still want a Levenshtein-family metric, Damerau-Levenshtein is worth benchmarking alongside Jaro-Winkler — it counts one transposition as a single edit instead of two. In practice Jaro-Winkler already handles that case well for short PO strings, so add the extra scorer only if your divergence benchmark shows a real gap it would close.

Related Permalink to this section#

• Exact vs Fuzzy Matching Strategies — the parent decision between deterministic and probabilistic linkage
• When to Use Fuzzy Matching Over Exact PO Matching — the trigger conditions for adding a similarity layer at all
• Blocking Strategy Selection for High-Volume Supplier Feeds — pre-filtering candidates before either scorer runs at scale
• Matching & Reconciliation Algorithms — the engine that routes exact, tolerance, and fuzzy decisions
• ↑ Parent: Exact vs Fuzzy Matching Strategies