iGaming ERP software should model GGR, NGR, gaming duty, partner settlements, and PSP reconciliation to give operators control at scale across markets.
← All insights
A finance team can close the ledger on time and still not know the economic truth of the business. If gross gaming revenue is calculated in one platform, gaming duty in spreadsheets, affiliate costs in a separate tool, and PSP cash in bank files, management reporting becomes a monthly negotiation. iGaming ERP software exists to turn those disconnected calculations into a controlled financial record.
For an operator expanding across products and jurisdictions, this is not a software feature checklist. It is an accounting architecture question: can the system represent how the business actually earns, shares, taxes, and collects money? Generic ERP configuration usually starts with invoices and standard sales tax. iGaming starts with the revenue waterfall.
An iGaming operator does not recognize revenue when a customer places a bet or makes a deposit. The financial story moves through wagers, wins, bonuses, adjustments, GGR, gaming duty, revenue shares, commissions, payment costs, and the resulting NGR. Each stage may differ by product, brand, country, licensee, supplier agreement, and reporting period.
That is why a credible iGaming ERP is not simply a general ledger with an industry dashboard. It should establish consistent rules for turning operational gaming data into accounting entries, supporting evidence, tax calculations, and management reporting. Finance should not have to rebuild those rules manually every month.
The distinction matters most at scale. A single-market operator can often tolerate spreadsheets maintained by a handful of people who understand the exceptions. A multi-market business cannot build a dependable close process around individual memory. Every new territory, commercial partner, payment provider, or acquisition compounds the risk.
The chart of accounts matters, but it is not the starting point. The starting point is the exact route from gaming activity to recognized revenue and contribution margin.
For online casino, sportsbook, poker, or a mixed portfolio, the calculation can include different bonus treatment, jackpot funding, voids, free bets, promotional deductions, supplier fees, and contractual revenue shares. The operator must decide which amounts affect revenue, which are costs of sales, which are liabilities, and which are recorded as accruals. Those decisions need to be applied consistently and traceably.
A well-configured ERP can receive summarized gaming data at the right level of detail, validate it against agreed rules, and post controlled journals to the correct entities, departments, products, markets, and accounting books. It can also retain a clear path back to the source data. That makes a material difference when auditors, tax teams, lenders, or prospective investors ask how a figure was derived.
GGR is a vital measure, but it is rarely the number leadership needs to run the business. Commercial decisions depend on NGR and on the profitability that remains after gaming duty, affiliate commissions, platform charges, payment costs, incentives, and other direct expenses.
If those deductions are assigned late, inconsistently, or only at a consolidated level, a market can look more attractive than it is. The same problem applies to a brand, campaign, or partner. Finance leaders need profitability views that reflect commercial reality, not just a top-line number that is easy to extract.
Gaming duty is not VAT. Treating it as a generic indirect tax workflow creates avoidable control problems because gaming taxes are commonly based on market-specific definitions of taxable GGR, deductible items, thresholds, periods, and filing requirements.
The challenge is not only calculating the liability. It is proving the calculation. A finance and tax team should be able to see the underlying gaming activity, the rule applied, the jurisdictional entity, the period, the adjustment history, and the final accounting treatment. Where rules change, the configuration needs effective dates and governance, rather than an unrecorded spreadsheet revision.
There is no single global duty model. Some jurisdictions tax GGR with narrowly defined deductions; others introduce product differences, progressive rates, or local reporting conventions. The ERP must be designed for variation without allowing every market to become its own uncontrolled finance process.
PSP reconciliation is often described as an operational chore. In reality, it is a core cash-control process. Deposits and withdrawals can be affected by fees, reserves, chargebacks, timing delays, rejected transactions, currency conversion, and settlement batches that do not align neatly with the gaming platform's day-end.
An operator needs to reconcile three positions: player and gaming-platform activity, PSP settlement activity, and cash received in the bank. When these records sit apart, the team spends too much time identifying exceptions and too little time resolving them. Unreconciled cash can also distort working-capital reporting and conceal issues that deserve immediate escalation.
Good iGaming ERP software does not claim that every transaction will match automatically. Complex businesses will always have exceptions. The objective is to automate the predictable matching, make unmatched items visible, assign ownership, and preserve an audit trail from transaction to settlement to ledger entry.
Affiliate agreements, game-supplier deals, white-label arrangements, and market access partnerships are central to the economics of many operators. Yet partner settlements are frequently calculated outside the ERP, then posted as a single monthly expense. That approach can pay the right amount eventually while still giving management weak insight during the month.
A better model calculates accruals using the contractual driver: NGR, GGR, first-time depositors, fixed minimums, tiered rates, or another agreed basis. It can distinguish estimates from finalized settlements and reverse or true-up accruals once supplier statements are received. This allows the close to reflect the period's economics rather than the timing of an invoice.
The trade-off is implementation discipline. Contract terms must be structured clearly enough to configure, and changes need formal approval. If commercial teams can create one-off deals without a controlled handoff to finance, no ERP design will protect reporting quality for long.
International growth often produces a familiar pattern: local teams use different definitions, different calendar conventions, and different reporting packs. Consolidation then becomes an exercise in translating numbers that should have been comparable from the start.
A NetSuite-based approach can support multiple legal entities, currencies, books, and reporting dimensions while retaining a shared operating model. The value is not merely faster consolidation. It is the ability to ask a consistent question across the group: which market, product, channel, or partner is producing profitable growth after the full cost of regulation and distribution?
Local statutory needs still matter. A group should not force every jurisdiction into a reporting structure that fails its legal or tax requirements. The practical goal is controlled local variation combined with a common group-level data model.
The most useful question is not, “Does the ERP support iGaming?” Almost any configurable platform can be made to carry gaming-related journals. The better question is, “Has the implementation been designed around our revenue waterfall and evidence trail?”
That changes the discovery process. Finance, tax, commercial, operations, and technology leaders should map the real flow of data and decisions: where GGR originates, how bonuses are treated, who owns duty rules, when partner accruals are recognized, how PSP breaks are investigated, and which reports directors rely on. Exceptions deserve as much attention as standard flows because exceptions are where manual work and audit risk accumulate.
Artio takes this specialist position because the distinction is material: iGaming is not a vertical to bolt onto a generic ERP project. It is a financial model that must be made native to the system.
A system built around the actual economics of gaming gives finance more than a cleaner close. It gives leadership a reliable basis for deciding where to invest, which markets to defend, and what profitable growth truly costs.
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.