Automate gaming duty accruals with jurisdiction-specific logic, auditable calculations, and faster close reporting for iGaming finance teams at scale
← All insights
Gaming duty is not VAT. It is a jurisdiction-specific cost of operating, calculated against gaming activity that can move materially before finance has finished reconciling payment providers, bonuses, voids, and operator adjustments. To automate gaming duty accruals properly, an iGaming business needs to make the duty calculation part of the financial architecture - not a month-end spreadsheet exercise.
That distinction matters when an operator is active across markets, products, entities, and licensing arrangements. A rate table alone will not solve the problem. Finance needs a controlled process that identifies the correct taxable base, applies the right rules for each jurisdiction, posts a traceable accrual, and reverses or settles it without obscuring the underlying economics.
A generic ERP implementation often treats gaming duty as a standard tax code or a manual journal. Neither reflects how gaming revenue is actually created or regulated. Duty may be based on gross gaming revenue, net gaming revenue, stakes, winnings, or a defined taxable gaming yield. The answer depends on the market, product, licence holder, reporting period, and local treatment of bonuses, player incentives, jackpot contributions, and other deductions.
The source data introduces another layer of difficulty. A sportsbook may calculate taxable activity differently from a casino vertical. A correction to a settled bet, a voided game round, or a late platform adjustment can change the duty position after the initial daily calculation. If finance uses a disconnected workbook, the team must manually establish which version of gaming data was used, which rate was applied, and whether the resulting journal agrees to the regulatory filing.
That is manageable at low volume. It becomes a control risk when the business enters new markets, adds legal entities, or faces an accelerated close timetable. The spreadsheet is rarely the original problem. It is the visible symptom of revenue logic living outside the ledger.
The right design begins with the revenue waterfall. Gaming activity should flow through a defined path from source transactions to GGR, then to the relevant NGR or taxable basis, before duty, revenue share, affiliate cost, and recognised revenue are considered. Each step needs an explicit owner, rule set, and audit trail.
For finance, this means the duty accrual should be calculated from controlled gaming data rather than entered as a top-side estimate. The ERP should retain the dimensions needed to explain the number: legal entity, jurisdiction, brand, product, licence, currency, period, and, where relevant, operator or platform relationship. Those dimensions are not reporting decoration. They determine whether finance can reconcile the ledger to the regulatory return and understand profitability by market.
A practical automation model usually has four connected elements:
The detail of the configuration depends on the regulatory landscape. Some operators require daily accruals to monitor exposure closely. Others may accrue monthly because the data is stable and materiality supports it. The point is not to automate every journal at maximum frequency. It is to select a cadence that gives management a timely, defensible view of duty without creating unnecessary operational noise.
One global percentage applied to GGR is fast to deploy and wrong for many businesses. Jurisdictional rules should be configured as controlled logic, with effective dates and clear treatment of changes in legislation or licence terms.
The calculation must also distinguish between an estimated operational accrual and the final filed amount. The two may be identical in a mature, well-integrated environment. They may also differ because a local return applies adjustments that arrive after the initial close. That is not a failure of automation. It is why the system needs a structured true-up process rather than a manual overwrite that erases the audit trail.
Where a business operates through multiple legal entities, the design must also establish which entity bears the liability, which entity records the cost, and how intercompany arrangements affect the posting. This is particularly relevant where a licence holder, technology provider, and commercial operator do not sit in the same company. Gaming duty can be economically understood in one part of the group while legally payable by another. The books need to show both realities correctly.
Automation should not mean that finance loses visibility into the calculation. The opposite should happen. A controller should be able to open an accrual journal and trace it back to the jurisdiction, period, source activity, calculation rule, and supporting report that created it.
A sound process separates calculated results from accounting approval. The system can generate a proposed accrual from validated data, while finance reviews exceptions before posting. Exceptions may include missing product mapping, an unexpected negative taxable base, a material period-over-period movement, a newly activated jurisdiction, or a rate change without approved effective-date logic.
This approach is more useful than forcing a binary choice between full automation and manual control. High-confidence activity can post under established rules. Unusual activity can be held for review. Finance retains judgment where it matters while removing the repetitive work of exporting data, rebuilding calculations, and keying journals.
The liability should then reverse or clear in a way that matches the settlement process. If the operator pays gaming duty after filing, the payment should clear the accrued balance against the filing support. If the final return differs from the estimate, the difference should post as a visible true-up to the correct period or current period, according to the accounting policy. Hidden netting makes the close look cleaner while making audit and forecasting harder.
Accurate gaming duty accruals affect more than compliance. They change the quality of commercial decisions.
When duty is calculated late or held outside the ERP, market-level profitability is incomplete. A commercial team may see strong GGR and assume a campaign is performing, while finance knows the margin is being compressed by duty, affiliate commission, bonus cost, payment fees, and revenue share. If those costs arrive weeks after the operational result, pricing and acquisition decisions are being made with a partial view of NGR.
Automated accruals also improve forecasting. Finance can model duty as a direct consequence of projected gaming activity by jurisdiction, rather than rely on a flat percentage of total group revenue. That is essential when expansion plans involve markets with different rates, thresholds, or allowable deductions. It also gives leadership a clearer view of cash requirements, especially where payment timing differs from the accounting period.
For a buyer, investor, or auditor, the benefit is equally practical: the business can explain how a material liability is calculated and controlled. This matters during due diligence. A month-end balance backed by repeatable system logic is easier to trust than a file maintained by one person with several undocumented adjustments.
NetSuite has no built-in gaming duty module. Duty logic is configuration and customisation: custom records, SuiteScript, saved searches, and workflows built on the standard ledger. Designed well, it gives finance the controls described above without a parallel spreadsheet. For how duty differs by market, see our overview of gaming duty across jurisdictions. A typical design includes:
There is no single gaming duty template that should be copied into every operator. The right design depends on the number of jurisdictions, the maturity of source data, the reliability of product and market mappings, the legal-entity structure, and the level of reporting granularity management expects.
An operator with one regulated market may prioritise a clean automated accrual and filing reconciliation. A multi-market group may need multi-book treatment, local currency translation, separate statutory reporting, and consolidated management views. A business using several platforms may first need to standardise data definitions before it can trust any automated journal.
This is where generic tax workflows tend to fail. They assume the tax engine is the centre of the problem. In iGaming, the revenue waterfall is the centre. Duty automation only works when it is designed around how the operator earns, adjusts, shares, and reports gaming revenue.
Artio configures NetSuite around those mechanics, because iGaming is not a vertical to be approximated after go-live. It is the financial model the ERP must represent from the start.
The most useful question is not whether your team can produce a gaming duty number at month-end. It is whether the number is available early enough, detailed enough, and defensible enough to run the business with confidence.
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 ›