Same Label, Different Bet: The Data Problem Underneath Odds Comparison
Every odds comparison, expected-value model and arbitrage engine assumes it knows when two bookmaker prices describe the same bet. Drawing on the working rules of an Australian odds data business, Gaming Eminence examines where that assumption fails, why false matches are more dangerous than missed ones, and why flat market taxonomies may not survive the growth of player and micro-markets.
Rhyan Morice founded WagerWise, an Australian betting-software business whose tools help users compare bookmaker prices and work through positive expected-value (EV), arbitrage and matched-betting calculations. He also runs Odds API, a developer service for structured pre-match bookmaker odds delivered over REST, Server-Sent Events and WebSocket. At the time of writing, its website lists 152 Australian bookmakers in its coverage, alongside bookmakers in the US, UK, Canada, Europe and Latin America.
That is the layer this article is about. A best price, an EV figure or an arbitrage is only as reliable as the decision that two bookmakers' markets describe the same contract. Bookmakers do not name or format their markets the same way, and settlement rules differ from market to market. Morice has also written for Nordic APIs on the failure states streaming APIs should document.
His vantage point is worth stating. WagerWise offers price-comparison, EV and arbitrage tools, and Odds API sells odds data with EV and arbitrage feeds on its paid plans, so both businesses depend commercially on matching being right. The mapping counts, regression fixtures and pipeline design described below are Morice's own account of his systems.
The examples use Australian bookmakers, mostly on AFL and NRL markets. They draw on Sportsbet and Ladbrokes screenshots captured on 11 September 2026, Morice's own regression fixtures and Sportsbet's published rules.
On a recent AFL fixture between Fremantle and Geelong, Sportsbet listed its main winner market as "Head to Head". Ladbrokes listed the same market as "Match Betting". Different labels, identical bet. On the same pages, a Sportsbet player market read "20+ Disposals" and the Ladbrokes equivalent read "To Have 20+ Disposals". Also identical, but neither is the same bet as "over 20 disposals", because a player who finishes on exactly 20 wins the first and loses the second.
Those two examples contain most of the problem. Comparing prices is arithmetic. Establishing that two prices describe the same contract is a data engineering problem, and it is the part of the stack where errors are least visible and most expensive.
"Two prices are comparable only when they describe the same event, outcome and settlement conditions," says Morice. "We match the structure of the wager, not the bookmaker's label."
What has to be true before two markets match
In practice, structural equivalence means agreement on a long list of attributes at once. The fixture, competition, participants and scheduled start must agree. So must the market family (moneyline, handicap, total, team total or player prop), the period (full match, half, quarter or another segment), the subject (home team, away team or a specific player), the metric (points, tries, disposals, tackles), the direction and exact line, and the treatment of extra time and settlement.
The disposals example shows why the line has to be canonicalised rather than copied. Morice's system converts both bookmakers' "20+" wording into a full-time player-disposals proposition on the named player with a line of over 19.5. The half-point subtraction is not cosmetic. It encodes the fact that 20 is a winning outcome.
The same screenshots also show the opposite case. Sportsbet displayed Fremantle at -10.5 with a match total of 174.5; Ladbrokes displayed Fremantle at -9.5 with a total of 173.5. The market families match. The bets do not. A comparison engine that groups on family and team alone would treat them as the same product at different prices, when they are different products.
The wrong match costs more than the missed one
There are two ways to get normalisation wrong. A system can fail to recognise two equivalent markets, or it can decide that two different markets are the same. Morice is clear about which is worse.
"A missed match reduces coverage," he says. "An incorrect match can manufacture a best price, expected-value opportunity or arbitrage that does not exist."
That asymmetry should shape design. A missed match is a gap a user may never notice. A false match produces a signal that looks like an edge, which is precisely the output downstream users are paying to find and most likely to act on.
Handicaps illustrate the discipline required. One AFL regression fixture in Morice's test suite contains Collingwood -37.5, Richmond +37.5 and Collingwood -45.5 under a "Pick Your Own Line" market. The first two form a valid opposing pair. The -45.5 selection stays separate, because no matching +45.5 outcome exists. Same team, similar wording, different contract.
The same logic applies at the point of display. If two rendered sections of a bookmaker page appear to contain the same selection at different prices, the system stops rather than taking the first result. Refusing to match is treated as a valid outcome, not a failure.
Where normalisation breaks: the long tail
Player props are where the mapping burden concentrates. Morice's current Sportsbet source configuration holds 428 labels or patterns, of which 168 are active player-prop mappings. Its Ladbrokes configuration holds 330 mappings, 100 of them player props. Those are one data business's figures for two bookmakers in one market, but they indicate the scale of maintenance involved.
Three failure patterns recur.
Period. A Sportsbet regression fixture contains Evan Mobley to make one or more threes in the full match at 1.65, and the same proposition for the first quarter at 3.60. Both normalise to over 0.5 player threes. Only the period separates them. Without it, a first-quarter price can overwrite a full-match price, and the comparison shows a value that is not available on the bet the user thinks they are looking at.
Bands that resemble lines. Sportsbet's "Big Win Little Win" market offers outcomes such as "Wests Tigers 1 to 12". Morice's parser maps this to a winning-margin band, deliberately not to a handicap. A 1 to 12 margin band and a -12.5 line look related, but their winning, losing and draw states differ.
Totals without scope. A game total, a team total, a first-half total and a player total can all display "Over 20.5". The owner, metric and period all have to sit in the key, or four different markets collapse into one.
Settlement rules: the attribute that rarely makes the key
Two markets can agree on every visible attribute and still be economically different, because they settle differently. Sportsbet's published AFL rules provide several examples. Regular-season home-and-away matches settle at normal time, while finals settle after extra time unless a draw is offered in the market. Fourth-quarter markets exclude extra time. Player markets such as "20 or more disposals" are void if the player is not in the starting 23. Under its Fair Go rule, unsettled bets on a player who suffers a game-ending injury in the first half are void, while bets already determined stand.
Rugby league adds its own exceptions. Morice notes that Sportsbet's NRL rules include extra time in most markets but exclude it from "Will There Be Extra Time?", "Highest Scoring Half" and "Half With Most Tries", and that tryscorer bets are refunded if the player never takes the field.
None of this can be inferred from a label such as "full time" or "anytime tryscorer". Morice's model currently carries period and extra-time scope in its market identity, which prevents the most obvious collisions. Participation, injury, dead-heat and resettlement rules are handled as a separate eligibility decision rather than as part of every canonical key.
Morice sees that as a known limitation. "A stronger future model would attach a versioned settlement profile to each outcome," he says. The word "versioned" matters: bookmakers change their rules, and a historical comparison is only valid against the rules in force when the price was offered.
Identity is not price
The architecture Morice describes separates the question "is this the same bet?" from the question "what does it cost?" at every layer.
It runs in four stages, split across his two businesses: Odds API collects and sorts the prices, and WagerWise displays and uses them.
Bookmaker-specific payloads are first converted into typed outcomes: moneyline, three-way moneyline, handicap, total, team total, player prop and margin band.
A streaming normaliser then builds stable records carrying the event, bookmaker, market type, period, metric, line, side or player, availability, source time and quality flags.
A calculation layer groups only exact semantic buckets: totals on the same metric, subject, period and threshold; handicaps on opposite teams with inverse signed lines; three-way markets only when all three outcomes, including the draw, are present.
Finally, before any action, the application checks the live bookmaker page again, matching event, market, selection, signed line and the price on the button itself.
The rule that ties it together is simple. A move from 1.90 to 1.95 updates an existing outcome. A move from -9.5 to -10.5 creates a new one. Price is a property of a contract; the line is part of its identity.
Validation at every boundary
No single control catches every error, so validation is layered.
At parsing, structurally invalid records are rejected: a handicap without a team side and signed line, a total without a direction and threshold, a player prop without a player and a valid line.
After parsing, market-level invariants are checked. No-vig prices are calculated only from complete outcome groups; incomplete groups stay unpaired rather than being forced into a pair.
In the data contract, accepted, quarantined and rejected outcomes are recorded with parser, mapping, taxonomy and build versions, so any output can be traced to the rules that produced it.
Before a new source goes live, it runs alongside the existing output and is reconciled for missing, extra, mismatched, duplicate and stale rows.
At the point of use, the live page check catches the case where the feed was right but the bookmaker has since moved, suspended or repriced the market.
The quarantine state is worth noting. A record that cannot be confidently classified is neither published nor discarded. It is held, counted and visible.
Two clocks, not one
Correctly matched prices can still be wrong if they are not equally current. Morice's pipeline separates the time the bookmaker published a price from the time the platform received it, so a delayed message cannot overwrite a newer observation simply because it arrived later. Stable outcome identifiers mean repeated updates replace state rather than creating duplicates.
Morice lists what goes wrong without those controls: a best price that is no longer available, a false expected-value calculation, an arbitrage with one leg suspended or moved, and stakes calculated on a price the bookmaker will not accept. Each is a normalisation failure that presents as a pricing opportunity.
From taxonomy to composition
Asked what limits scale, Morice does not point to compute. "The main constraint is maintaining semantic exceptions," he says. Adding a bookmaker is not one new adapter. It brings new labels, periods, statistical terms, threshold formats, outcome ordering and settlement rules.
A fixed taxonomy still works for stable market families. It struggles when every combination becomes another flat market name. His alternative is compositional, with each market defined as a combination of family, scope, subject, metric, period, direction, line and settlement profile.
Parts of the industry already work this way. Sportradar's Unified Odds Feed identifies a market by a market ID plus specifiers, key and value pairs such as an over number and a total, which together define a unique market. The difference is that a feed supplier controls its own definitions. A platform reconciling many bookmakers' front-end labels has to reconstruct that structure from text that was written for punters, not machines.
On automation, Morice draws a firm line. Machine learning can propose new aliases for human review, he says, but should not make the final equivalence decision, because a single missing token such as "first half", "team", "including overtime" or "20+" can change the payout.
Why this matters beyond comparison sites
Gaming Eminence analysis
The examples here come from one Australian business, but the problem is general. Any business that consumes prices from more than one source inherits it: aggregators, trading teams benchmarking against the market, affiliates publishing best-price tables, and operators reconciling multiple B2B feeds.
Three implications follow.
First, the cost of error is asymmetric and hidden. Coverage gaps are visible in a dashboard. False matches surface as apparent edges, which means they are most likely to be acted on and least likely to be questioned.
Second, settlement is part of the product definition, not small print. As player and micro-markets grow, the share of markets where settlement rules decide equivalence grows with them. The same issue applies to adjacent models such as prediction markets, where the resolution criteria define the contract.
Third, the hard part of scaling betting data is identity, not volume. The discipline Morice describes, refusing a match when the evidence is incomplete, holding uncertain records in quarantine, and versioning the rules alongside the data, is the same discipline any industry dataset needs before it can be trusted. More rows built on weak identity only multiply the errors.
Rhyan Morice is the founder of Odds API (odds-api.net) and WagerWise. Screenshots were captured on 11 September 2026; bookmaker rules are quoted as published at the time of writing.
