Casino Game-Round Reconciliation: Finding GGR Gaps Across Aggregators

GGR gaps start where systems disagree

A casino GGR discrepancy is disagreement between records of one event: operator wallet movement, aggregator request/status, provider outcome, and settlement-statement commercial total. Without round-level joins, finance cannot defend a balance and engineering lacks a bounded incident search.

Reconciliation establishes each round’s canonical economic state, quarantines in-flight records, and explains known exceptions. Feeds need not match at midnight: a provider-settled wager still open in the wallet may become a support case, rollback, or duplicate debit.

This covers game rounds and derived statements, not deposits, PSP routing, chargebacks, or catalogue performance. Connectivity determines available evidence; see the operator trade-off between game aggregators and direct integrations.

A game round is a state machine, not a row

A one-bet, one-win model fails with timeouts, retries, free rounds, interrupted sessions, cancellations, and delayed callbacks. Retain every message without counting liability twice.

Keep immutable events with operator, aggregator, and provider transaction IDs; round/game IDs; player, currency, amount, event type; received and source timestamps; idempotency key; raw-payload reference; and processing result. Never overwrite status: a correction must reference the event it changes.

Ordinarily, a player bets 10; the wallet accepts the debit; the aggregator sends the wager to the provider; the provider returns a win of 16; the aggregator requests a wallet credit; the wallet accepts it and updates balance.

A timeout changes later meaning. If the wallet debits 10, gives the aggregator no response, then receives a retry with the same idempotency key, it must return the first result. A second debit is wrong even if the supplier statement nets to expected GGR. An unfinished round is neither loss nor win, but unresolved liability until expiry, recovery, or rollback policy applies.

Model economic legs rather than vendor labels: debit = stake, credit = win, rollback = reversal of an accepted leg, and retry = no leg unless processed as one. This stabilises treatment across cancel, refund, void, reversal, and rollback terminology.

Daily totals conceal the round-level fault

Daily GGR can match while balances are wrong: equal duplicated and missing stakes offset. Totals can also differ only because provider completion and wallet posting use different cut-offs. Normalise status, currency, and time boundary first; ask which rounds create variance, not which total is correct.

Do not send every variance to a generic adjustment account. It may balance a monthly report while hiding supplier exposure, wallet defects, timing variance, accounting policy, and repeat incidents.

Build the proof pack before debating totals

Each daily run needs a proof pack, not a red spreadsheet cell. Freeze the window and specify wallet acceptance, provider completion, or agreed operational cut-off. Reconcile in transaction currency first; convert to reporting currency after round matching, or exchange-rate rounding can resemble a missing round.

Settled GGR = accepted stake legs - accepted win legs - valid rollback impact

Rollback impact depends on the reversed original leg: a stake reversal reduces stakes; a win reversal reduces wins. Subtracting every rollback from GGR misstates rounds rolled back after payout.

In an illustrative five-round, single-currency extract, A has stake 10 and win 16, GGR -6; B stake 10 and no win, GGR 10; C stake 5 and valid stake rollback 5, GGR zero; D stake 8 and win 8, GGR zero; E has wallet stake 12 while the aggregator reports the same provider transaction twice after a retry. Raw wallet stakes are 45 and wins 24, GGR 21. Removing E’s duplicated 12 leaves canonical stakes 33 and GGR 9. If the aggregator statement is 9, this is a wallet processing defect, not a commercial supplier discrepancy: finance corrects the ledger and should not dispute settlement.

Each exception needs source-payload and processed-event links, reason code, decision time, reviewer, and resolution reference. Finance can bridge daily GGR to general-ledger policy and engineers can replay messages. Before automation, a qualified finance owner must approve definitions of stake, winnings, valid reversal, open-round reserve, tax treatment, and statement cut-off; data modelling cannot decide unagreed accounting judgments.

SQL should expose exceptions, not hide them

Create a canonical round view and separate exceptions from settled activity. Raw round-ID joins are unsafe: references may be reused across games, bonus features may emit linked transactions, and wallet and supplier order may differ. Use strongest shared keys, then validate player, currency, game, amount, and time window.

This pseudocode keeps accepted legs, conservatively marks retries, and identifies missing or non-terminal provider states:

WITH wallet AS (
  SELECT round_id, provider_txn_id, player_id, currency, event_type, amount,
         idempotency_key, accepted_at
  FROM wallet_events
  WHERE accepted_at >= :start_at AND accepted_at < :end_at
    AND processing_status = 'ACCEPTED'
), deduped AS (
  SELECT * FROM (
    SELECT w.*, ROW_NUMBER() OVER (
      PARTITION BY provider_txn_id, event_type, amount, currency
      ORDER BY accepted_at) AS retry_rank
    FROM wallet w
  ) x WHERE retry_rank = 1
), matched AS (
  SELECT w.*, p.round_state, p.settled_at
  FROM deduped w LEFT JOIN aggregator_round_feed p
    ON p.provider_txn_id = w.provider_txn_id
   AND p.player_id = w.player_id AND p.currency = w.currency
)
SELECT round_id, provider_txn_id,
  SUM(CASE WHEN event_type='BET' THEN amount ELSE 0 END) AS stakes,
  SUM(CASE WHEN event_type='WIN' THEN amount ELSE 0 END) AS wins,
  MAX(round_state) AS provider_state
FROM matched GROUP BY round_id, provider_txn_id
HAVING MAX(round_state) IS NULL
    OR MAX(round_state) NOT IN ('SETTLED','ROLLED_BACK')
    OR COUNT(DISTINCT idempotency_key) <> COUNT(*);

This finds exceptions, not final accounting. Amount-and-type deduplication is deliberately conservative: legitimate transactions can share both, so production logic needs transaction identity and replay semantics, flagging ambiguity rather than erasing it. Also produce supplier records absent from the wallet and wallet legs lacking provider matches after tolerance. Keep outputs separate: netting can let an unmatched win cancel an unmatched bet and destroy repair evidence.

The exception path changes by round state

A missing settled round needs supplier payload retrieval, correlation-ID checks, and an idempotent replay decision. A late round needs a timing bridge and next-day clearance check. An unfinished round needs documented provider recovery or expiry. Treating all as missing causes bad escalations and potentially wrong balance action.

Scrutinise rollbacks: they may recover a failed wager request, reflect supplier cancellation, or correct operator processing. Identify the original leg; confirm amount, currency, player, and transaction lineage. A rollback without an original match is an exception, not a negative stake to net.

Transport and business retries are often given the same label. A transport retry returns the original accepted result without another ledger movement; a business retry may be valid only after explicit failure. Retain request hashes, idempotency keys, and response codes long enough to distinguish them. Finance needs canonical counts, not a technical log dump.

For bonus-funded or free rounds, separate funding source from game result. Stake and outcome logic remain, but the accounting destination may differ from cash wagering; mixing them into cash GGR without policy confuses bonus cost, game margin, and statement variance.

Scale turns a matching job into a control system

At scale, use queues, ageing rules, supplier mappings, and thresholds that distinguish late callbacks from incidents. Do not measure only unmatched value: many low-value exceptions can reveal a broken retry release, while one high-value unresolved round can require immediate review.

Maintain views for unmatched wallet legs, unmatched supplier events, open rounds past tolerance, and duplicate-or-collision candidates. Slice by provider, aggregator, game, currency, integration version, and hour. A post-release spike differs from a persistent provider-specific tail; useful reconciliation points the incident manager to the likely fault.

Match supplier statement lines to the canonical round ledger only after classifying exceptions. Statements evidence settlement and commercial accounting, not player balances: they are aggregated and may use another cut-off. The wallet remains the record of accepted player-facing movements, subject to platform controls and policy.

Define closure: ageing bands, accountable owner, escalation criteria, and treatment of old unresolved items as accrued, reversed, or moved to a separately approved adjustment process. Local licence conditions and accounting rules can alter treatment, requiring legal and finance review for each operating entity.

A short daily control beats a late monthly surprise

Before releasing or changing an integration, confirm:

• Finance approved state mappings, cut-off, currency treatment, and rollback accounting.
• Engineering retains immutable raw events and correlation keys for wallet, aggregator, and provider messages.
• Daily processing separates settled matches, timing items, open rounds, duplicates, and unmatched records.
• Exceptions have owner, ageing status, evidence links, and recorded resolution.
• Monitoring alerts on exception count and value by provider and integration version, with player-safety and support escalation for balance-affecting faults.

This has commercial weight: repairing GGR after month-end while balances remain unresolved is not a completed control. High-intensity sessions amplify duplicated debits or missing wins, so balance-affecting exceptions should be suppressed from promotions and routed through support and responsible-gambling procedures where appropriate.

Evidence makes GGR defensible

The result is more than matching totals: each settled round has proven lineage, each late item a timing explanation, and each unresolved record an owner and ageing rule. Finance gets a supportable GGR bridge, engineers a bounded defect queue, and supplier managers a factual settlement basis.

Start with one aggregator, one currency, and narrow event types. Make the state model and proof pack reliable before automating every edge case. Once discrepancies are explained at transaction level, scale is volume and supplier mapping rather than blind trust in daily totals.