Learn how to configure gaming revenue waterfalls in NetSuite for auditable GGR, duty, partner costs, and multi-jurisdiction profit reporting at scale.
← All insights
A gaming operator can report strong GGR and still have no clear view of what it actually earned. That gap usually appears between platform data, tax calculations, partner settlements, and the general ledger. To configure gaming revenue waterfalls properly, finance needs more than a set of journal entries. It needs a controlled model of how every wager moves from player activity to recognized revenue and jurisdiction-level profitability.
Generic ERP configuration tends to fail here because it starts with chart-of-accounts labels. iGaming finance starts with economic events. A bet is placed, settled, adjusted, reversed, bonused, taxed, shared with a game supplier or platform partner, and ultimately settled through payment channels. The waterfall must preserve that chain without asking finance to rebuild it in spreadsheets at month-end.
The first configuration decision is not technical. It is commercial: what does each legal entity, market, and product line define as GGR, NGR, and recognized revenue?
For an online casino, GGR commonly begins with stakes less winnings, subject to treatment for voids, canceled rounds, progressive contributions, and bonus mechanics. A sportsbook may require distinct handling for settled bets, cash-outs, resettlements, free bets, and trading adjustments. The figures may look similar on a management dashboard, but their accounting treatment is only reliable when source events and business rules are explicit.
Build the waterfall from atomic transaction categories rather than from a monthly platform export. Each category should have a defined destination, timing rule, legal entity, jurisdiction, product, brand, currency, and accounting treatment. That makes it possible to answer a question an auditor, investor, or tax authority will eventually ask: why did this revenue number change?
A useful core structure is:
The order matters, but it is not universal. Some markets calculate duty before certain deductions; others permit limited deductions or impose product-specific rates. Some commercial agreements calculate revenue share from GGR, while others use NGR after bonus cost, duty, or payment costs. A waterfall that assumes one global formula will create reporting differences the moment the operator enters its second regulated market.
Jurisdiction should be a configuration driver, not a reporting tag added after posting. It affects tax rates, taxable events, effective dates, filing entities, currencies, document requirements, and sometimes whether particular promotional costs are deductible at all.
Gaming duty is not VAT. Treating it as a generic indirect-tax workflow can obscure the taxable base and make rate changes difficult to evidence. Instead, configure duty rules that reference the relevant gameplay and adjustment transactions, apply the correct rate for the market and effective period, and post to dedicated duty accounts and liabilities. The system should retain the calculation inputs, not merely the final amount.
This is especially important where one operating platform supports several licensed entities. A player may see one brand while activity is legally attributable to different entities based on location, license, or product. The revenue waterfall must assign the event correctly before revenue, duty, and partner charges are calculated. Reclassifying activity later is a close-process failure, not a normal finance procedure.
Use consistent dimensions for legal entity, jurisdiction, brand, product, channel, and commercial partner. The exact segment design depends on the operating model, but the principle does not: a CFO should be able to see casino contribution in one market, sportsbook contribution in another, and consolidated performance without manually joining reports from several systems.
Rates, supplier terms, and affiliate deals change. Configuration must support effective-dated rules rather than overwriting the old rate with the new one. This protects historic reporting and allows finance to reproduce a prior-period calculation after a regulatory review or transaction due diligence request.
Where contracts contain thresholds, tiered rates, minimum guarantees, or negative carryover provisions, calculate those mechanics in controlled logic. A flat percentage field is not a revenue-share engine. The more complex the agreement, the more important it is to separate the calculation layer from the accounting posting layer while maintaining a direct audit trail between them.
PSP reconciliation is essential, but it is not the source of gaming revenue. Cash deposits, withdrawals, chargebacks, processor fees, and settlement timing must reconcile to player-wallet and bank activity. They should not determine GGR merely because they are easier to obtain from a statement.
Configure separate but connected workflows. Gaming events create the revenue waterfall. Wallet and PSP events establish receivables, payables, cash movement, fees, and settlement exceptions. The two streams should reconcile through player liability and clearing accounts, with identified timing differences rather than unexplained plugs.
That separation has practical value. Finance can close revenue based on settled gameplay data while continuing to investigate a delayed PSP settlement. Operations can see processor exposure by provider and currency. Leadership can distinguish a revenue issue from a cash-collection issue before either becomes a board-level surprise.
Revenue sharing and affiliate commissions are frequent sources of inconsistent reporting. The problem is not that the calculations are difficult. The problem is that commercial, finance, and legal teams often use the same phrase for different economics.
A game supplier's fee may be a cost of revenue, an affiliate may be paid on NGR, and a white-label arrangement may require an assessment of whether the operator is principal or agent. Those decisions affect reported revenue, margin, and comparability across brands. They should be documented as accounting policies and implemented consistently, with exceptions visible rather than buried in manual journals.
Do not use the waterfall to force a preferred EBITDA outcome. Configure it to reflect contractual obligations and accounting policy. Management reporting can then present GGR, NGR, gross margin, and contribution margin clearly, each with a defined purpose. When those measures are blended, commercial teams optimize one number while finance reports another.
A well-designed NetSuite model does not need a journal entry for every player transaction in the general ledger. It does need controlled aggregation that can be traced back to the underlying events. The posting design should summarize high-volume activity at an appropriate daily or period level while retaining transaction identifiers, rule versions, source references, and reconciliation status in supporting records.
At minimum, configure mappings for GGR, bonus and promotional treatment, gaming duty, partner revenue share, affiliate commissions, PSP fees, player liabilities, cash clearing, accrued supplier charges, and intercompany balances. Where management reporting differs from statutory accounting, use the appropriate accounting books and reporting structures instead of maintaining competing offline models.
Multi-book accounting becomes valuable when group reporting, local statutory requirements, or acquisition structures require different views of the same activity. It is not a substitute for clean source logic. If the underlying jurisdiction or product classification is wrong, multiple books only reproduce the error more elegantly.
The strongest finance teams do not aim for a waterfall with zero exceptions. They aim for exceptions that are visible, categorized, assigned, and resolved. Examples include unsettled gameplay beyond a defined threshold, negative GGR at partner level, missing jurisdiction data, unexpected rate application, unmatched PSP items, and late source-file deliveries.
Configure exception reporting alongside the standard posting process. A daily control report should show volume, value, source completeness, calculated duty, partner accruals, and reconciliation breaks. By month-end, finance should be reviewing anomalies, not discovering that an entire market was mapped to the wrong legal entity.
Happy-path testing is inadequate for iGaming. Test voided and resettled bets, late game-round adjustments, jackpot events, free-bet treatment, reversals across accounting periods, currency conversion, regulatory rate changes, suspended accounts, chargebacks, tiered affiliate arrangements, and partner disputes.
For each scenario, validate three outcomes: the operational record, the accounting posting, and the management report. If one changes without the others, the configuration is incomplete. Finance also needs a clear close calendar defining cutoffs, source-data sign-off, accrual ownership, reconciliation timing, and approval of manual adjustments.
Artio approaches this work from the premise that the revenue waterfall is the operating logic of an iGaming ERP, not an integration detail to be addressed after the financials are live. That distinction is what turns NetSuite from a general ledger into a system finance can use to run the business.
The practical test is simple: when a new market, tax rate, supplier deal, or product launches, can the team model its economics before the first wager is placed? If the answer is yes, the waterfall is doing its job. If the answer requires a spreadsheet, a late journal, and a meeting to decide which number is right, the configuration still has work to do.
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.
Prefer to talk? Email [email protected] · call us ›