A game provider invoice should not be approved just because its total looks close to your casino dashboard. To verify game provider invoices against casino data, you need to establish that the billed activity occurred, that revenue was calculated on the agreed basis and that the correct commercial terms were applied.
These are separate checks. A provider can report accurate gameplay totals but apply the wrong revenue-share rate. Your own dashboard can also disagree with an otherwise correct invoice because it uses a different cutoff or includes bonus activity differently.
The workflow below gives finance, operations and data teams a repeatable way to investigate those differences before approving payment.
Verify game provider invoices at three levels
Treat each invoice as three reconciliations rather than one comparison of totals:
- Activity: Do the provider’s transactions and adjustments reconcile with the casino’s recorded gameplay and wallet movements?
- Revenue basis: Do those transactions produce the billable revenue defined in the contract?
- Commercial calculation: Were rates, minimums, fixed fees, credits and currency conversions applied correctly?
A matching grand total is not enough. An overcharge on one studio can cancel an undercharge on another, hiding both problems.
Reconcile at the lowest useful billing level, normally the contracting entity, brand, provider, product and currency. Keep slot games and live casino games separate where their pricing differs. The same game-level data also feeds tax returns; see the gambling tax reporting data your casino platform must capture.
Establish the contractual billing basis first
Before querying transactions, turn the signed agreement and applicable amendments into a versioned billing specification. Record the effective dates, not just the latest rate card.
Your specification should identify the payable counterparty, included brands and game catalogs, revenue definition, rates, minimum guarantees, fixed charges and permitted deductions. It should also explain how the contract treats negative revenue, promotional play, jackpots and corrections to earlier periods.
Do not assume that a fee described as a percentage of “GGR” uses your internal dashboard definition. Likewise, “net revenue” is not a universal formula. Bonus costs, gaming duties or other deductions belong in the calculation only when the agreement permits them.
The game provider contract checklist helps identify the fee definitions and data-access rights needed to make invoices independently verifiable.
Establish who bills each charge. If a game aggregator invoices studio revenue share on a pass-through basis, identify whether the studio also invoices anything directly. Reconcile each charge to its contractual scope rather than assuming every invoice from both parties is payable.
Collect evidence that supports a reproducible calculation
A dashboard screenshot cannot explain an individual rollback or prove which exchange rate was used. Request machine-readable reports wherever possible and preserve the original files.
| Evidence | Minimum useful detail | Verification purpose |
|---|---|---|
| Invoice and supporting schedule | Entity, period, provider, currency, fee basis, rates and adjustments | Identify exactly what was charged |
| Provider or aggregator activity export | Transaction IDs, round IDs, game IDs, event types, amounts, timestamps and statuses | Rebuild reported gameplay activity |
| Casino wallet ledger | Posted debits, credits, reversals, currencies and external references | Verify financial effects recorded by the casino |
| Contract and rate schedules | Effective dates, billing definitions, tiers, minimums and exclusions | Recalculate contractual charges |
| Adjustment register | Credit notes, prior-period corrections and approval references | Prevent missed or repeated adjustments |
| FX schedule, where applicable | Currency pairs, rate source, timestamp or averaging period and precision | Reproduce currency conversion |
Store the extraction time, report filters, file version and source alongside each dataset. For a disputed amount, both parties must be able to reproduce the same input population.
Use pseudonymous player identifiers where player-level matching is necessary. Restrict access to reconciliation files and avoid collecting personal data that the billing investigation does not require.
Normalize the period and transaction records
Agree on the cutoff and inclusion rule
Define the billing interval explicitly, including its time zone. A useful technical representation is a start-inclusive, end-exclusive interval, such as October 1 at 00:00 through November 1 at 00:00 in the agreed billing time zone.
Then establish which timestamp determines inclusion: bet placement, settlement, wallet posting or another contractually specified event. These can fall in different months.
A round started before midnight and settled afterward illustrates why this matters. The provider may recognize it on settlement while your dashboard groups it by start time. Neither total is comparable until both use the agreed rule.
Record when reports were generated and whether the period was considered final. Keep late settlements and corrections in a controlled adjustment register so the same item is not charged through both a refreshed report and a later adjustment.
Normalize identifiers, signs and statuses
Create a canonical transaction view without overwriting the raw records. Map provider and aggregator identifiers to stable casino references, preserving the originating system and transaction ID.
Do not deduplicate on round ID alone. A round can contain multiple legitimate bets, payouts or adjustments. Likewise, do not count a retried callback twice merely because it arrived through two delivery attempts.
Map event types to their actual financial effects. A rollback should offset the original transaction only to the extent that the rollback was posted, not simply because a rollback request exists.
The principles in casino ledger design and audit trails help distinguish attempted events from posted debits, credits and reversals. That distinction is essential when a provider report and wallet history disagree.
Rebuild billable revenue from the underlying activity
Reconcile stakes, winnings and reversals separately
For a simple settled-game model, gross gaming revenue is commonly expressed as:
GGR = effective stakes − effective player winnings
Here, “effective” means the amounts remaining after valid posted reversals or corrections. If the export already presents net amounts, do not subtract those reversals a second time.
Calculate by provider, billing currency and the other dimensions required by the contract. Never add amounts from different currencies before applying the agreed conversion method.
Compare stake totals, win totals and reversal totals separately before comparing GGR. Two datasets can produce identical GGR while disagreeing materially on the underlying activity.
Also compare transaction counts and matched references. Counts are useful diagnostics, but do not expect one provider round to equal one wallet row: legitimate relationships can be one-to-many.
Apply exclusions without double counting
Move from operational GGR to the contractual billing basis using an explicit adjustment bridge. Each adjustment needs a reason, amount and supporting reference.
Promotional play deserves particular care. Free spins may create payouts without corresponding cash stakes in your wallet ledger, while a provider report may include promotional stake values. Confirm the reporting model before comparing either dataset.
If the contract excludes a defined bonus segment, remove that segment’s net contribution according to the agreed rule. Do not automatically deduct the promotional budget or all bonus payouts.
For jackpots, identify how contributions and jackpot-funded winnings are represented. A jackpot contribution already excluded upstream must not be deducted again downstream.
Negative revenue also needs explicit treatment. A contract may permit carryforward, pool results across games or apply a floor within a defined scope. Applying a zero floor separately to every game can overstate the fee if the agreement requires provider-level netting.
Recalculate rates, minimums and other charges
Apply commercial rules in the agreed order
Once the revenue basis reconciles, calculate the charge independently of the invoice.
For tiered pricing, distinguish a marginal tier from a rate that applies to the entire billing base once a threshold is reached. Confirm whether thresholds are measured per brand, provider, currency or combined portfolio.
Minimum guarantees also need precise interpretation. A minimum might replace a lower revenue-share charge, apply to a particular product or operate across a group of brands. It is not automatically an additional fee.
Check fixed charges, promotional discounts and effective-date changes separately. A midmonth amendment may require activity to be split into two pricing periods.
Where currency conversion is involved, reproduce the contractual rate source, conversion stage and rounding precision. Converting daily totals can differ from converting a monthly total. Cryptocurrency settlement does not remove these questions or justify assuming that a stablecoin always equals one unit of the invoice currency.
Worked example: a bonus exclusion changes the invoice
The following figures are illustrative. Assume all amounts are in EUR and the contract explicitly excludes a defined bonus segment’s net GGR. It sets a 12% revenue-share fee, a €6,000 monthly minimum that replaces a lower revenue-share charge and a separate €500 platform fee.
| Calculation | Amount |
|---|---|
| Effective stakes | €1,000,000 |
| Effective player winnings | €940,000 |
| Operational GGR | €60,000 |
| Contractually excluded bonus-segment GGR | €5,000 |
| Billable revenue | €55,000 |
| Revenue-share fee at 12% | €6,600 |
| Charge after applying the €6,000 minimum | €6,600 |
| Separate platform fee | €500 |
| Expected invoice before applicable taxes | €7,100 |
If the provider instead charges 12% of €60,000 plus €500, its invoice reaches €7,700 before tax. The €600 difference is a billing-basis error, not a missing-gameplay problem.
Validate tax treatment, invoice entity and any withholding obligations separately with the relevant finance or tax adviser. Gameplay reconciliation alone cannot establish the correct tax treatment.
Classify discrepancies before opening a dispute
Give each difference an owner and an explanation category. This prevents finance from asking engineering to investigate a pricing error or asking a provider to explain an internal reporting filter.
| Difference | Likely investigation path | Evidence to compare |
|---|---|---|
| Stakes or wins differ | Missing activity, scope mismatch or reporting definition | Transaction references, game mapping and cash versus promotional activity |
| Activity appears in different months | Cutoff or late-settlement mismatch | Event times, posting times and billing inclusion rule |
| Reversals disagree | Duplicate processing, incomplete rollback or status mismatch | Original transaction, reversal reference and posted ledger effects |
| Revenue matches but fees differ | Incorrect rate, tier, minimum or fee scope | Effective rate schedule and independent calculation |
| Converted totals differ | FX methodology or rounding mismatch | Rate source, conversion stage and precision |
| Previous correction appears again | Duplicate adjustment or untracked credit | Adjustment register, credit note and original invoice reference |
Start with aggregate comparisons by day, game and currency to locate the variance. Then drill into the affected transactions. This is usually more efficient than manually inspecting every row.
Keep unexplained differences visible. A small net variance can conceal larger offsetting errors, so track both the signed difference and the absolute differences across reconciliation groups.
Build a dispute packet that can be resolved
A useful dispute says what is wrong, why it is wrong and how the corrected amount was calculated. Sending a large transaction export without identifying the affected rows transfers the investigation rather than resolving it.
For each disputed line, retain:
- Billing reference: Invoice number, line item, period, provider and currency.
- Contractual basis: Relevant clause or rate schedule and its effective date.
- Calculation: Provider amount, independently calculated amount and variance.
- Supporting activity: Affected transaction references, timestamps and financial effects.
- Requested resolution: Corrected invoice, credit note or another adjustment permitted by the agreement.
Assign an internal owner and record the provider’s response, agreed action and closure evidence. Separate confirmed differences from items still awaiting investigation.
Follow contractual notice and payment terms. Raising a dispute does not automatically suspend payment obligations, and an expected credit should not disappear into an informal email thread.
When a credit is agreed, link it to the original invoice and verify that it appears exactly once in the subsequent billing cycle. Keep the relevant accrual, payable and adjustment records aligned under your accounting policy.
Automate repeatable checks, not unexplained acceptance
An automated reconciliation should produce an exception report and a reproducible calculation, not just a green status indicator.
Useful checks include missing expected files, unknown game mappings, duplicate financial events, unmatched reversals, rates outside their effective dates and unexpected fee lines. Compare totals by the dimensions used for billing, preserving the calculation logic and input versions for each run.
Separate documented rounding tolerances from operational review thresholds. A threshold can prioritize investigation, but it should not redefine what the contract allows or silently write off recurring errors.
Use independent review for material changes to rates, mappings and billing rules. Reprocessing the same source files with the same rule version should produce the same result. If a later run changes the invoice expectation, the system should identify whether the cause was new data, a corrected mapping or a changed commercial rule.
Frequently asked questions
Can I verify provider invoices using only a casino dashboard? A dashboard is useful for an initial comparison, but invoice approval needs sufficient supporting detail to reproduce the billing basis. Aggregate totals can hide cutoff differences, excluded activity and incorrect fee calculations.
Should provider reports or the wallet ledger take precedence? Neither is automatically authoritative for every question. Provider records describe reported game activity, while the wallet ledger records financial effects posted by the casino. Investigate differences against transaction evidence and the contract’s reporting provisions.
Should payment gateway data be included? Not usually in the core gameplay fee calculation. Deposits and withdrawals do not establish stakes, winnings or provider GGR. Payment data becomes relevant only where a contractual billing component explicitly depends on it.
How should late settlements be handled? Apply the agreed billing inclusion and adjustment rules. Preserve the original close, identify the late activity and track whether it is corrected through a revised invoice, credit note or subsequent-period adjustment.
Make billing verification part of platform selection
Spinlab offers game aggregation, real-time analytics and a customizable backoffice within its modular iGaming platform. When evaluating Spinlab’s casino platform, confirm the provider reports, transaction fields and export requirements your finance team needs during scoping.
The practical test is straightforward: can your team reconstruct a provider charge from identifiable activity and signed commercial terms, then explain every adjustment without relying on a dashboard total?
