An iGaming multi-jurisdiction reporting guide for finance leaders: build auditable GGR, duty, NGR, and profitability reporting by market with control.
← All insights
A group finance pack can show growing revenue while concealing a much more serious problem: nobody can explain, consistently and quickly, how each market arrived at its net result. One jurisdiction may calculate gaming duty on GGR, another on a defined NGR base. One license may sit in a separate legal entity, while another is operated through the same entity but requires different regulator submissions. This iGaming multi-jurisdiction reporting guide sets out the financial architecture required to report by market without rebuilding the numbers in spreadsheets every month.
The objective is not simply to produce more reports. It is to create a controlled path from player activity and payment flows to GGR, gaming duty, NGR, recognized revenue, and market-level profitability. If that path changes depending on who exports the data, the operator does not have reporting control. It has a month-end workaround.
A useful jurisdiction report answers more than what the business earned. It should show where the revenue arose, which legal entity and license are responsible, the applicable gaming duty treatment, the commercial costs attached to that market, and the cash and balance-sheet consequences.
For a CFO, that means being able to compare market contribution without mixing tax mechanics into commercial performance. For tax and legal leaders, it means tracing declared gaming duty back to an approved transaction population and rule set. For commercial teams, it means seeing whether a market that appears to deliver high GGR is being eroded by bonuses, affiliate costs, revenue share, payment fees, or unfavorable payment mix.
Those questions cannot be answered reliably with a single country field added at the end of the close. Jurisdiction is part of the accounting design. It needs to be present when data enters the finance process, not only when the board asks for a new view.
Before configuring dashboards or statutory packs, decide the lowest level at which results must be explained. For most regulated operators, that includes legal entity, licensed jurisdiction, brand, product vertical, currency, accounting period, and source system. Depending on the operating model, player location, license location, and contracting entity may all matter - and they are not always the same thing.
That distinction is where generic ERP designs often fail. A single customer or revenue record cannot carry every regulatory and commercial meaning by default. Finance needs agreed rules for which dimension determines the gaming-duty calculation, which determines statutory reporting, and which supports management profitability. The answer can differ by market.
A sportsbook operating across states, for example, may need reporting by state of wager acceptance, while group management also needs visibility by brand and operating entity. An online casino group may need to distinguish a locally licensed subsidiary from a platform entity that provides services under an intercompany agreement. Treating those scenarios as exceptions creates reconciliation work forever. Modeling them as standard dimensions creates a repeatable close.
The central reporting object for an iGaming operator is the revenue waterfall. It should be calculated from governed data and retained in a form that finance, tax, and auditors can inspect.
At a high level, the waterfall moves from stakes and winnings to GGR, then through market-specific deductions and charges to NGR, recognized revenue, and contribution. The labels may sound familiar, but the treatment behind them is not universal. Bonus cost, jackpot funding, voided bets, free bets, loyalty rewards, progressive contributions, and settlement adjustments can affect different stages depending on policy, product, contract terms, and local regulation.
Gaming duty is not VAT. It should not be treated as a generic sales-tax overlay that can be bolted onto an invoice process. In many markets, duty is calculated on a prescribed gaming-revenue base, subject to timing rules, deductions, thresholds, or product-specific rates. The system must preserve both the calculation and the basis used to calculate it.
Revenue share also requires discipline. A royalty, platform fee, local operating partner share, or market-access fee may be calculated from GGR, NGR, or another contract-defined base. If the base is calculated outside the ERP and posted as a monthly journal, operators lose the ability to see margin movement early or challenge a settlement with confidence.
One source of truth does not mean one presentation of truth. Statutory reporting, tax filings, regulatory submissions, and management reporting have different purposes. The underlying transaction data and rule definitions should be controlled centrally, while the reporting layers apply the appropriate view.
A statutory report may need local currency, prescribed gaming-duty categories, and a legal-entity perimeter. A management report may translate results to group currency, allocate shared costs, and compare contribution by brand or product. Both should reconcile to the same ledger and source activity, even when the measures are different.
This is also where multi-book accounting matters. A group may need local statutory books, a group reporting book, and specific treatment for revenue recognition, foreign exchange, or intercompany arrangements. Maintaining separate spreadsheets for each view does not create flexibility. It creates competing versions of margin.
The strongest report cannot repair weak source data. Each material transaction should arrive with the dimensions and attributes required for accounting, duty, reconciliation, and analysis. That does not mean copying every event into the general ledger. It means retaining a traceable subledger or summarized transaction layer that can be reconciled to the ledger by jurisdiction and period.
The core design normally includes market and license attributes, legal entity, brand, product, transaction type, currency, payment method, counterparty, and tax or duty rule. The value comes from how those fields are governed. A jurisdiction selected manually without validation will eventually be wrong. A license mapping maintained in a controlled rule table can be reviewed, approved, and applied consistently.
Rule effective dates are especially important. Gaming-duty rates change. Market launches occur mid-month. Contracts are renegotiated. If the finance system overwrites an old rule with a new one, it can no longer explain prior submissions or rerun historical reporting accurately. Effective-dated rules allow finance to calculate the right treatment for the relevant transaction period while retaining an audit trail of the change.
Multi-jurisdiction reporting is only credible when the numbers reconcile across operational and financial systems. GGR may originate in the gaming platform, but cash moves through payment service providers, wallets, bank accounts, chargeback processes, and settlement cycles. Each creates timing differences that must be understood rather than buried in unexplained balances.
A practical close process reconciles gaming-platform activity to the revenue and liability subledger, then reconciles PSP settlement files and bank activity to cash and clearing accounts. The ledger should show the resulting balances by entity, currency, and relevant market. Foreign-exchange treatment needs equal care: transaction currency, settlement currency, and functional currency can differ in the same flow.
The aim is not to force every operational event to equal cash on the same day. It is to make timing differences visible, aged, and owned. A delayed PSP settlement, disputed card transaction, or unmatched wallet movement should be identifiable by market and payment method, with evidence supporting the balance.
Month-end reporting becomes slow when exceptions are discovered after reports are drafted. Build controls around the items most likely to affect duty, revenue, or partner settlements: late game settlements, voids after period end, manual player adjustments, bonus corrections, chargebacks, FX revaluations, and changes to jurisdiction mappings.
Each exception needs a defined owner, approval path, and accounting treatment. Material items should be visible in the close pack rather than absorbed into a broad manual journal. That is how finance retains judgment without sacrificing auditability.
Market reporting is often strongest at the top of the revenue waterfall and weakest below NGR. That leaves leadership unable to distinguish a market with genuine operating leverage from one that is buying growth through incentives and expensive acquisition channels.
A commercially useful view brings together gaming duty, affiliate commissions, revenue-share obligations, PSP fees, bonus cost, customer-support costs where relevant, and allocated or directly attributable operating expenses. The appropriate level of allocation depends on the decision being made. A market launch decision may require fully loaded profitability; a pricing or promotional decision may focus on contribution after variable costs.
Do not pretend that one allocation method is objectively correct. Shared technology, central compliance, and group overhead require policy choices. The discipline is to document those choices, apply them consistently, and present a contribution view alongside fully allocated profit where both are useful.
A reporting model that works only for the current legal structure will fail at the first acquisition, new license, or product launch. Build jurisdiction, entity, and reporting-rule structures that can accommodate new markets without redesigning the chart of accounts or creating a fresh spreadsheet pack.
That means testing the model against realistic events: a new jurisdiction with a different duty base, a local partner paid on NGR, an acquired business using different source systems, or a regulatory request for a revised historical period. If the response is a manual data project, the architecture is not ready for expansion.
Artio approaches this as an iGaming finance design issue, not a generic reporting feature. The ERP should reflect how the operator actually makes money, settles obligations, and proves its numbers - from GGR through recognized revenue and market-level profitability.
The most valuable outcome is simple: when a new market opens or a regulator asks a difficult question, finance should be able to explain the number from source activity to ledger, without asking a spreadsheet to make the case.
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 ›