Accumulator Tracking: A Reproducible Review Ledger

Use three linked tables

One row per accumulator is not enough for leg-level analysis. Use stable IDs across three tables:

Never overwrite a forecast with the closing price, final lineup or corrected result. Add new fields or adjustment rows so the original information set remains visible.

Minimum accumulator record

Record the accepted product name, operator, jurisdiction, complete leg order, combined price at full precision, total stake, maximum loss, potential gross return and receipt ID. For each leg, preserve the market period, data provider, probability estimate and the other legs on which it depends.

Betfair's current Sportsbook rules illustrate why voids, related contingencies, cash out and promotions need product-specific settlement fields rather than a single result label.

Reconcile cash before performance

1. Start from opening account cash.
2. Add deposits and withdrawals separately.
3. Add settled cash returns and refunds.
4. Include open stakes and liabilities in an exposure table.
5. Reconcile the calculated closing cash with statements.
6. Investigate every difference before computing yield.

Promotional credits, free-bet stakes and cash should use separate columns. A token's face value is not a deposit or realised return.

Evaluate forecasts chronologically

scikit-learn's TimeSeriesSplit documentation explains why time-ordered evaluation must not train on future observations. Store a model and data cutoff for every decision so later information cannot leak into an earlier forecast.

For marginal or joint probability forecasts, use calibration tables and proper scoring rules. The original Brier-score paper defines a probability-forecast verification method, and scikit-learn's calibration documentation explains reliability curves. Do not grade a 20% event as simply right or wrong after one observation.

Monthly review questions

• Do accepted prices match archived receipts?
• Which market definitions create settlement corrections?
• Are joint probabilities calibrated by range?
• Which dependence labels are missing or unstable?
• Does performance change after excluding promotions?
• Are results concentrated in one league, operator, market or model version?

Next step

Use Weekly Acca Spreadsheet for the next part of this topic.

Derived metrics and denominators

OpenStax's expected-value framework and scikit-learn's calibration guidance require distinct payoff and probability-quality calculations. Calculate each metric from named fields and preserve its denominator:

• Yield = settled net betting result / settled cash stakes.
• Closing-price movement = accepted price compared with a timestamped closing reference under one convention.
• Calibration bucket = mean forecast probability compared with observed frequency for the same target definition.
• Maximum open exposure = largest simultaneous cash loss under the recorded settlement states.
• Promotion contribution = realised promotional cash return separated from ordinary product return.

Do not mix account return, yield on stakes and forecast accuracy. A deposit changes account cash but is not betting profit; a void changes turnover but is not a forecast win; a winning accumulator does not prove its probability was accurate.

Version every derived report. If a market mapping or settlement is corrected, append the adjustment and regenerate the report from source tables. The prior report should remain reproducible from its data snapshot.

Continue learning

• Next guide: Hedging an Accumulator
• Related guide: Request a Bet

Assumptions and limitations

A complete ledger makes analysis reproducible but does not make a forecasting method accurate. Small or selected samples can mislead, and outcome-based metrics should be interpreted with uncertainty and complete inclusion rules.