GGR versus NGR explained for iGaming operators: understand the revenue waterfall, gaming duty, partner costs, reporting, and ERP control across markets.
← All insights
A sportsbook can report record GGR and still miss its profitability plan. An online casino can appear highly profitable until gaming duty, bonus costs, and revenue-share agreements are applied consistently. That is why GGR versus NGR explained is not a glossary exercise for iGaming finance teams. It is the basis for trustworthy management reporting, tax treatment, commercial decisions, and recognized revenue.
The distinction is simple in principle. In practice, it becomes difficult as soon as an operator spans multiple products, jurisdictions, currencies, tax rules, affiliates, and platform contracts. Generic ERP setups tend to treat the gap between GGR and NGR as a handful of journal entries. That approach does not hold up under audit, during a close, or when leadership asks which market is actually generating cash and profit.
Gross gaming revenue (GGR) is the amount an operator retains from betting or gaming activity before the direct deductions that determine its net gaming position. For casino, it is generally stakes less player winnings. For sportsbook, it is turnover less winning bets. The exact source data and calculations vary by product, but the commercial meaning is consistent: GGR measures the house win before operating the regulated gaming business.
A simplified formula is:
GGR = Stakes or turnover - player winnings
Net gaming revenue (NGR) is GGR after deductions defined by the operator's accounting policy, commercial agreements, and regulatory environment. These deductions commonly include gaming duty, bonuses or promotional costs where relevant, jackpot contributions, affiliate commissions, revenue shares, and platform or content-provider fees. The precise NGR definition is not universal. It must be explicit, governed, and applied consistently.
A simplified formula is:
NGR = GGR - agreed revenue deductions
That word, "agreed," matters. A supplier contract may calculate its revenue share on GGR, NGR after bonus costs, or a bespoke adjusted measure. A jurisdiction may calculate gaming duty on GGR, GGR less specific player incentives, or a statutory base with rules that do not match management reporting. One label cannot safely do the work of a defined calculation.
Finance leaders often ask for a single NGR number. It is a reasonable request, but it can hide material differences. The NGR used to settle a content provider may not be the NGR used for an affiliate agreement. Neither may match the taxable gaming revenue reported to a regulator, nor the revenue recognized in the general ledger under the applicable accounting policy.
Consider an operator with $10 million in GGR for a month. It incurs $1.8 million in gaming duty, $900,000 in bonus cost, $700,000 in affiliate commissions, and $600,000 in game-provider revenue share. A management definition that deducts all four produces NGR of $6 million. But a game-provider contract might exclude affiliate costs from its calculation. The supplier settlement base would therefore be different even though both teams call it NGR.
This is not semantics. If finance uses a management NGR figure to calculate a supplier invoice, the operator can over-accrue or under-accrue costs. If commercial teams use a tax-adjusted NGR definition to assess acquisition economics, they may make poor channel decisions. If statutory returns use a number rebuilt outside the ledger, auditability weakens quickly.
The better question is not, "What is our NGR?" It is, "Which NGR definition is being used, for which purpose, and from which controlled data set?"
GGR remains essential. It shows the fundamental result of gaming activity before the cost of operating in a market. Product leaders use it to understand hold, game performance, betting margins, and player behavior. Commercial teams use it to evaluate the quality of acquired players before the full cost base is applied.
But GGR cannot answer whether a market is economically attractive. Two jurisdictions may generate the same GGR while producing very different NGR because their gaming-duty regimes, bonus restrictions, affiliate mix, and supplier contracts differ. A high-GGR market with punitive duty and expensive acquisition may contribute less than a smaller market with more favorable economics.
This is where finance architecture becomes a commercial issue. When deductions are allocated late, inconsistently, or through spreadsheets, management sees topline performance without the economics needed to act on it. Decisions on market entry, promotional intensity, pricing, and partner terms become slower and less defensible.
Gaming duty is frequently where generic finance designs fail. It is not a simple indirect-tax workflow attached to an invoice. It is generally a regulated levy on a defined gaming-revenue base, subject to jurisdiction-specific rates, thresholds, reporting periods, and treatment of incentives or adjustments.
The accounting question is equally important: should the duty reduce revenue, be recognized as an operating expense, or be presented differently under the operator's accounting policy and applicable reporting framework? There is no responsible universal answer. The treatment depends on facts, legal obligations, principal-versus-agent considerations, and auditor guidance.
What an ERP must do is preserve the calculation logic, source transactions, rate tables, jurisdictional attributes, and accounting outputs. Finance should be able to trace a duty return back to the underlying activity and reconcile that return to the ledger without reconstructing the waterfall in a separate file.
GGR and NGR are operational and commercial measures. Recognized revenue is a financial-reporting outcome. They may align in some business models, but they should never be assumed to be interchangeable.
For example, an operator may report GGR as a key performance indicator while recognizing revenue net of certain player-related payments or levies. A platform business may have principal-versus-agent considerations that alter gross versus net presentation. Timing can also differ where unsettled bets, jackpot liabilities, free bets, chargebacks, or wallet movements require careful treatment at period end.
The consequence is straightforward: a CFO should be able to reconcile operational GGR, one or more NGR measures, tax bases, partner settlement bases, and recognized revenue. Each should have a clear purpose and a documented bridge. If the bridge only exists in the knowledge of one finance manager, it is a control risk.
The practical answer is not more spreadsheet discipline. Spreadsheets are useful for analysis, but they are a weak system of record for calculations that drive tax filings, supplier liabilities, revenue recognition, and board reporting.
An iGaming ERP should capture the dimensions that make the waterfall meaningful: legal entity, jurisdiction, brand, product, wallet or currency, channel, supplier, affiliate, and reporting period. It should ingest or reconcile controlled data from player-account-management platforms, sportsbook engines, casino platforms, payment service providers, and settlement systems.
From there, the system can apply governed calculation rules to create distinct outputs. Gaming duty can be accrued by jurisdiction. Affiliate commission can follow the contracted revenue base. Supplier revenue share can be calculated at the relevant brand and product level. Bonus cost can be recognized according to policy. Finance can then post, reconcile, and explain the resulting balances without losing the connection to operational data.
This design also makes close faster. Instead of asking teams to submit local calculations and manually explain variances, finance can review exception reports: missing feeds, unexpected hold movements, changed duty rates, unusual bonus deductions, or partner costs that diverge from contract expectations. The work shifts from rebuilding numbers to investigating what matters.
A credible GGR-to-NGR model has to serve more than the monthly management pack. It should support the controller closing the books, tax and legal teams preparing filings, commercial teams negotiating revenue shares, and executives assessing market profitability.
At a minimum, leaders should expect a documented definition for every reported metric; version-controlled rules for jurisdictional duty and commercial deductions; a reconciliation from source activity to the ledger; and reporting that can drill from group results into legal entity, market, brand, product, and partner detail. They should also expect clear ownership when a definition changes.
There is a trade-off. Highly granular models take more care to configure and govern than a single monthly journal. But the apparent simplicity of the latter is expensive: slower close, disputed settlements, weak audit trails, and profitability reporting that arrives after decisions have already been made.
Artio is boutique by design because iGaming finance does not need a generic chart of accounts with gaming labels added later. It needs NetSuite configured around how the operator makes money - and around every controlled deduction between the wager and the reported result.
The useful next step is to take one recent month and map every number from player activity through GGR, each NGR definition, gaming duty, partner settlement, and recognized revenue. Wherever the trail breaks, requires a manual override, or produces competing answers, you have found the part of the finance architecture that deserves attention.
The blog is the long read. For your actual numbers — the engine, gaming duty, the close — book a short call with a partner who would configure it.
Independent, objective advice. We reply within one business day.