Workbook structure
Use separate sheets or structured tables rather than one increasingly wide log:
| Table | Required key | Purpose |
|---|---|---|
| Decisions | decision_id | One immutable pre-bet record per accumulator |
| Legs | decision_id + leg_no | One market contract and forecast per leg |
| Settlements | decision_id + adjustment_id | Results, voids, corrections and cash changes |
| Cash | transaction_id | Deposits, withdrawals, stakes, returns and credits |
| Lookups | versioned key | Market, provider, competition and rule definitions |
| Reports | derived only | Pivots, calibration, exposure and reconciliation |
The reports sheet should contain no manually typed result or profit values. Every metric should trace to the source tables.
Core formulas
For a straight accumulator using accepted decimal prices:
Combined price = product of live leg prices
Potential gross return = total cash stake * combined price
Potential net profit = potential gross return - total cash stake
Raw break-even probability = 1 / combined price
Use full stored precision and round only presentation cells. Recalculate a void leg under the accepted product rule rather than deleting it without an adjustment record.
Data validation rules
OpenStax defines probabilities on the zero-to-one scale, and current Sportsbook rules illustrate why accepted price and settlement evidence must remain attached to the product. Apply these validation rules:
- Require a unique decision ID.
- Restrict decimal prices to values of at least 1.00.
- Require probabilities between zero and one.
- Require event, market, line, period and accepted timestamp.
- Prevent settlement dates earlier than decision dates.
- Flag a leg with no result source or model cutoff.
- Reconcile leg count with the accepted receipt.
- Lock immutable decision columns after acceptance.
For chronological analysis, retain the model training cutoff and decision timestamp. scikit-learn's TimeSeriesSplit documentation explains why future observations cannot be used in earlier model evaluation.
Weekly QA sequence
| Check | Pass condition |
|---|---|
| Price | Product of accepted live-leg prices matches receipt precision |
| Stake | Cash outflow matches accepted total stake |
| Settlement | Every leg has one final state plus preserved corrections |
| Return | Sum of cash adjustments matches account statement |
| Completeness | No deleted or selectively omitted decision IDs |
| Forecast | Original probabilities remain unchanged |
| Reporting | Metrics refresh from source tables only |
Probability accuracy should be reviewed with calibration and proper scoring, not only win rate. The Brier paper supplies one reproducible probability score. Expected monetary results require net payoffs for all states under OpenStax's expected-value framework.
Next step
Use Accumulator Tracking for the next part of this topic.
Add fixture-based formula tests
Keep a small QA table whose expected outputs are typed once and protected:
| Fixture | Input | Expected output |
|---|---|---|
| Single live leg | Price 2.00, stake GBP 5 | Gross GBP 10 |
| Three live legs | 1.80, 1.65, 2.10 | Combined 6.237 |
| Middle leg void | 1.80, 1.00, 2.10 | Combined 3.78 |
| All legs void | All prices 1.00 | Gross equals returned cash stake |
| Losing straight acca | One live leg loses | Gross return GBP 0 |
| Duplicate decision ID | Existing identifier | Validation failure |
Microsoft's formula-auditing guidance explains error checks, watched cells, and step-by-step evaluation. Run the protected fixtures after a formula, lookup, import or column change, and add a fixture when a real record exposes a new error class.
Protect source columns from report formulas and sort operations. A spreadsheet that silently shifts one leg onto another decision ID can still produce plausible totals, so validate relational keys and leg counts before reviewing performance.
Continue learning
- Next guide: Acca Insurance and Odds Boosts
- Related guide: Accumulator Staking Plans
Assumptions and limitations
Spreadsheet function names and separators vary by software and locale. This page specifies a data contract and checks rather than distributing a proprietary workbook. Complex products may require additional split-stake and promotion tables.

