Where iGaming operators lose margin (affiliate overpayment, duty corrections, PSP fees, bonus classification) and how finance teams find and recover it.
← All insights
A monthly management pack can show revenue growth while quietly concealing margin loss. That is the uncomfortable starting point for this composite scenario: an established multi-market iGaming operator was reporting a healthy top line, yet finance could not consistently explain why cash, gross gaming revenue, net gaming revenue, and recognised revenue diverged.
The issue was not a single bad calculation. It was a finance architecture problem. Bonus costs were arriving from one platform, affiliate data from another, payment-service-provider fees from several more, and gaming duty was calculated outside the ERP. Each spreadsheet was defensible in isolation. Together, they created a revenue waterfall that could not be tested end to end.
This composite scenario reflects a pattern common among scaling casino and sportsbook operators. The details vary by market, licence structure, and commercial model. The underlying risk does not: when gaming economics live outside the ERP, leakage becomes difficult to see and even harder to recover.
The operator had grown through new market launches and product expansion. Its finance team had done what capable teams often do under pressure: build controls around the systems available. They reconciled deposits and withdrawals, maintained duty workbooks, calculated affiliate commissions, and posted monthly journals to create a consolidated view.
That process worked until it did not. Month-end was taking too long, adjustments were increasing, and commercial teams were challenging margin reports after the fact. Finance could report GGR, but the path from GGR to NGR and then to recognised revenue was not consistently modelled by jurisdiction, product, partner, and period.
Three questions exposed the weakness. Which bonus costs were reducing NGR in each regulated market? Were revenue-share partners settled on the same contractual basis used in management reporting? And was gaming duty calculated on the correct taxable base, with the right treatment of bonuses, adjustments, and prior-period corrections?
Those are not accounting housekeeping questions. They affect pricing decisions, market profitability, tax exposure, partner disputes, and the credibility of the board pack.
The review began with transaction-level data rather than the general ledger. That distinction mattered. A ledger can confirm that a journal was posted. It cannot establish that the journal reflects the right commercial event, tax treatment, or settlement rule.
Finance mapped two views for each material jurisdiction. The revenue waterfall ran from player stakes and wins to GGR, then bonus deductions where permitted and gaming duty where the definition includes it, to NGR and recognised revenue. Below it sat a profitability view: revenue share, affiliate commission, payment processing cost, and chargebacks. Those are costs, not steps to recognised revenue. Each component was traced to its source, calculation rule, owner, and journal entry.
The exercise surfaced four leakage points that had been obscured by aggregate reporting:
Not every variance represented recoverable cash. That is a critical distinction. Some were classification errors, some were timing differences, and some were genuine commercial overpayments. A credible recovery program separates those categories before anyone calls a number “leakage.”
The operator did not need another reporting layer. It needed the core ERP to represent how the business actually makes money.
The first step was to establish a controlled revenue model in NetSuite. This meant defining common data dimensions across entities, jurisdictions, products, brands, PSPs, and commercial partners. It also meant agreeing the calculation hierarchy before configuring automation. A poorly defined waterfall simply becomes a poorly automated waterfall.
For each market, the finance team documented the rule set that drives NGR and recognised revenue. Gaming duty was modelled as a jurisdiction-specific liability, not treated as a generic indirect tax. That is deliberate. Gaming duty is not VAT, and a finance system that treats it as though it were will create reporting and control problems at scale.
The revised design brought source transactions into a structured reconciliation process. Deposit and withdrawal data, PSP settlement files, bonus activity, affiliate performance, and gaming-platform extracts were matched against expected accounting outcomes. Exceptions were routed for investigation rather than buried in a monthly true-up journal.
The team also created clear ownership. Operations owned source-data completeness. Commercial leaders owned partner terms and approval of exceptions. Tax and legal validated jurisdictional treatment. Finance controlled the accounting policy, reconciliation status, and posting logic. The ERP became the common record, rather than the place where disconnected conclusions were summarised.
Once the calculation rules were visible, the operator could quantify the issues by period and counterparty. The affiliate overpayments were the clearest recovery opportunity. Finance prepared a contract-by-contract analysis, showing the approved commission base, the platform-calculated result, disputed transactions, and the net settlement position.
That did not mean immediately withholding payments. Long-standing partners, disputed interpretation, and data quality all matter. In some cases, the sensible response was a negotiated credit against future commission. In others, the review showed that internal reporting, not the partner invoice, had been wrong. The point was not to force a recovery figure. It was to establish a documented, defensible position.
PSP reconciliation produced a different outcome. Much of the variance was not overbilling. It was poor visibility into reserves, FX effects, fees, and chargeback timing. The value of correction was still substantial because treasury could forecast settlement cash with more confidence and finance could stop treating recurring unexplained differences as normal.
For gaming duty, the greatest gain was control rather than a retrospective windfall. The operator moved from a delayed spreadsheet process to a period-based calculation and reconciliation framework. Finance could now identify changes in taxable base before filing deadlines, retain an audit trail for adjustments, and distinguish an operational data issue from a tax-policy question.
The result was not merely a lower leakage number. The finance function changed how it closed the books.
Instead of posting broad revenue and cost journals at month-end, the operator worked through a defined sequence: validate source completeness, reconcile cash and PSP settlements, calculate revenue waterfall components, post controlled accounting entries, investigate exceptions, and certify the close. Management reporting was generated from the same underlying logic used for statutory accounting and duty support.
That matters when a CFO asks why one market’s NGR margin moved. The answer should not depend on whether a particular analyst updated the latest spreadsheet. It should be traceable to bonus behaviour, duty rules, partner economics, player-payment costs, or a real change in commercial performance.
The new model also improved decision-making outside finance. Commercial teams could see profitability after the costs that actually matter. Tax leaders had a clearer evidence trail. Executives could assess market expansion with a more realistic view of contribution margin. And when auditors or investors asked for support, finance could show the transaction path rather than reconstruct it under deadline pressure.
A practical leakage review should begin with a small number of high-value tests. Can finance trace a reported NGR figure to the underlying GGR, bonuses, and duty for a specific market and month, and the contribution below it to partner and payment costs? Can it explain the difference between PSP cash settlement and the related ledger entries? Can it prove that affiliate commissions follow current contract terms rather than legacy platform settings?
Then test governance. Are revenue-rule changes approved, dated, and applied from the correct period? Are exceptions visible before close? Is the same jurisdictional logic used in management reporting, statutory reporting, and tax support? If the answer depends on a spreadsheet owner, the control is not yet scalable.
Artio approaches this differently from a general ERP implementation. iGaming is not a vertical with a few extra fields. Its financial mechanics need to be native to the system design, from GGR through gaming duty, NGR, settlement, and recognised revenue.
The most useful next step is not a broad systems program. Take one material market, one month, and one revenue stream. Reconcile it from player activity through cash, tax, partner settlement, and the general ledger. The gaps that emerge will tell you where recovery is possible and where the underlying finance architecture needs to change.
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 ›