> For the complete documentation index, see [llms.txt](https://docs.sportradar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sportradar.com/uof/data-and-features/messages/event/bet-settlement.md).

# Bet Settlement

If something happens in a match that defines the outcome of a specific odds type, you will receive a ‘**bet\_settlement**’ message that contains information about the outcome of bets. 

And, in some cases, whether the bet was voided or not. If the bet is (partly) voided, the voided part should be refunded to the customer.

**Possible Outcomes and Void Factors**

The following list includes all possible combinations of *outcome (result)* and *void\_factor*:

* result="0" and no void\_factor: Lose entire bet
* result="1" and no void\_factor: Win entire bet
* result="0" and void\_factor="1": Refund entire bet
* result="1" and void\_factor="0.5": Refund half bet and win other half
* result="0" and void\_factor="0.5": Refund half bet and lose other half

{% hint style="info" %}
The evaluation of bet outcomes is the responsibility of the Client system.
{% endhint %}

**Void Reasons**

```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<void_reasons_descriptions response_code="OK">
    <void_reason id="0" description="OTHER"/>
    <void_reason id="1" description="NO_GOALSCORER"/>
    <void_reason id="2" description="CORRECT_SCORE_MISSING"/>
    <void_reason id="3" description="RESULT_UNVERIFIABLE"/>
    <void_reason id="4" description="FORMAT_CHANGE"/>
    <void_reason id="5" description="CANCELLED_EVENT"/>
    <void_reason id="6" description="MISSING_GOALSCORER"/>
    <void_reason id="7" description="MATCH_ENDED_IN_WALKOVER"/>
    <void_reason id="8" description="DEAD_HEAT"/>
    <void_reason id="9" description="RETIRED_OR_DEFAULTED"/>
    <void_reason id="10" description="EVENT_ABANDONED"/>
    <void_reason id="11" description="EVENT_POSTPONED"/>
    <void_reason id="12" description="INCORRECT_ODDS"/>
    <void_reason id="13" description="INCORRECT_STATISTICS"/>
    <void_reason id="14" description="NO_RESULT_ASSIGNABLE"/>
    <void_reason id="15" description="CLIENT_SIDE_SETTLEMENT_NEEDED"/>
    <void_reason id="16" description="STARTING_PITCHER_CHANGED"/>
</void_reasons_descriptions>
```

The client system will often receive two bet\_settements for the same outcome – one immediately after the match ends caused by the live scout, and a second confirming one when the results have been officially confirmed.&#x20;

The two messages have different certainty-levels to indicate the difference. In almost all cases the outcome results will be the same. In extra-ordinary cases the results may differ and the Client system will have to decide how to handle this.&#x20;

(One type of client system may always wait for the official confirmed results; another type may primarily use the live results).

#### Message Elements and Attributes <a href="#uofbetsettlement-messageelementsandattributes" id="uofbetsettlement-messageelementsandattributes"></a>

<table><thead><tr><th width="216.4000244140625">Attribute</th><th>Description</th></tr></thead><tbody><tr><td>bet_settlement</td><td>Root element</td></tr><tr><td>event_id</td><td>The ID of the event this bet settlement refers to.</td></tr><tr><td>product</td><td>The producer that generated this bet settlement information (1=LiveOdds, 2=MTS, 3=BetradarCtrl, 4=BetPal, 5=PremiumCricket).</td></tr><tr><td>timestamp</td><td>When this message was generated.</td></tr><tr><td>certainty</td><td>Is this bet-settlement sent as a consequence of scouts reporting the results live (1) or is this bet-settlement sent post-match when the official results have been confirmed (2)</td></tr><tr><td>market</td><td>Information about a specific market.</td></tr><tr><td>void_reason</td><td><p>Describes the reason for voiding certain outcomes for a particular market. Only set if at least one of the outcomes have a void_factor.</p><p><em>A list of void reasons can be found above this table or by using the API at</em> <a href="https://iodocs.betradar.com/unifiedfeed#Betting-descriptions-GET-Void-reasons"><em>https://iodocs.betradar.com/unifiedfeed#Betting-descriptions-GET-Void-reasons</em></a>.</p></td></tr><tr><td>outcome</td><td>Information about a specific market.</td></tr><tr><td>result</td><td><p>Possible values:</p><ul><li>0 = LOST</li><li>1 = WON</li><li>-1 = UNDECIDED_YET</li></ul><p>In the case of a -1 it means that the settlement is still undecided and another update will follow once it has been settled.</p></td></tr><tr><td>void_factor</td><td>If the bet on an outcome should be refunded completely void-factor is set to 1.0. If half of the bet on an outcome should be refunded void_factor is set to 0.5.</td></tr><tr><td>dead_heat_factor</td><td>A dead-heat factor may be returned for markets where a bet has be placed on a particular team/player to place and this particular player has placed but the place is shared with multiple players, reducing the payout.</td></tr><tr><td>dead_heat_factor_place</td><td><p>This is used when multiple golfers tie for the final paying place under the each-way terms.<br>In accordance with standard dead heat settlement rules, the available place positions are shared equally between the tied golfers. The dead_heat_factor_place represents the proportion of the normal place payout that each golfer should receive.<br>For example:<br></p><ul><li>Two golfers tie for the final paying place → dead_heat_factor_place = 0.5 (each receives 50% of the normal place payout).</li><li>Three golfers tie for two remaining paying places → dead_heat_factor_place = 2/3 (0.6667).</li></ul><p>This value is separate from the standard dead_heat_factor because it applies specifically to the place portion of each-way settlement. For outright tournament winner markets, a playoff determines a single winner, so dead heats cannot occur for the win portion and only apply to the place payout. However, for end-of-round leader and other tournament-derived markets - Winner of Groups and Top Region markets, multiple golfers can finish tied in first place, meaning the standard dead_heat_factor may also be required to settle the win portion of the market.</p></td></tr><tr><td>each_way_result</td><td><p>This indicates how the each-way bet should be settled.<br></p><ul><li>winner|place – The golfer won the tournament. As the winner also finishes within the place terms, both the win and place portions of the each-way bet are settled as winners.</li><li>place – The golfer did not win the tournament but finished within the advertised each-way places (e.g. Top 5 places). Only the place portion of the each-way bet is settled as a winner, while the win portion loses.</li></ul></td></tr><tr><td>each_way_factor</td><td><p>This defines the fraction of the win odds used to calculate the place payout for an each-way bet, in line with the market’s advertised each-way terms.<br>Common examples include:</p><ul><li>0.25 = 1/4 odds</li><li>0.20 = 1/5 odds</li></ul><p>For example, if the market is 1/4 odds for the first 5 places, the place return is calculated using 25% of the golfer’s win odds.</p></td></tr></tbody></table>

#### Message Example <a href="#uofbetsettlement-messageexample" id="uofbetsettlement-messageexample"></a>

```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bet_settlement certainty="1" product="1" event_id="sr:match:935448" timestamp="1771591062081">
  <outcomes>
    <market id="193">
      <outcome id="74" result="-1"/> <!-- Example of partial settlement -->
      <outcome id="76" result="1"/>
    </market>
    <market id="204" specifiers="xup=1"> <!-- Updated specifiers example -->
      <outcome id="12" result="0"/>
      <outcome id="13" result="-1"/> <!-- Example of partial settlement -->
    </market>
    <market id="201">
      <outcome id="863" result="0"/>
      <outcome id="864" result="-1"/> <!-- Example of partial settlement -->
      <outcome id="861" result="1"/>
      <outcome id="862" result="0"/>
    </market>
  </outcomes>
</bet_settlement>
```

#### **bet\_settlement and Results** <a href="#uofbetsettlement-bet_settlementandresults" id="uofbetsettlement-bet_settlementandresults"></a>

You should not use bet\_settlement messages as a signal that all results for a match are available. If the certainty is confirmed, you are guaranteed that the bet\_settlements are confirmed as stated.&#x20;

However, you are **not** guaranteed that all results are available just because you receive a bet\_settlement with certainty=2 (confirmed). For example: there might be additional result information that may come in later, but we may have enough results to send out bet\_settlement messages for the markets we have offered.&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sportradar.com/uof/data-and-features/messages/event/bet-settlement.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.