This isn’t a rounding error. This is a systematic reconciliation failure that’s costing you real money\u2014either in overpaid commissions, underpaid affiliates who leave your program, or compliance risk when your numbers don’t match during an audit.<\/p>\n\n\n\n We’ve worked with casino operators where the delta between affiliate tracking and platform revenue exceeded 18% month-over-month. Not because of fraud. Not because of a technical failure. Because five different systems were measuring the same events with different rules, different timestamps, and different currency conversions, nobody built a reconciliation framework that could align them.<\/p>\n\n\n\n Here’s what actually happens when a player clicks an affiliate link and plays at your casino:<\/p>\n\n\n\n A click event<\/strong> gets logged in your affiliate tracking system with timestamp, affiliate ID, source parameters, and a unique click identifier.<\/p>\n\n\n\n Registration<\/strong> happens on your iGaming platform. Player creates account. Platform assigns player ID, stores registration timestamp (possibly in a different timezone), and may or may not immediately communicate this back to your affiliate system.<\/p>\n\n\n\n KYC verification<\/strong> occurs in your compliance system. Could be instant. Could take 48 hours. Player status changes from “pending” to “verified” but this status change might not trigger an update to your affiliate tracker.<\/p>\n\n\n\n First deposit<\/strong> processes through your payment service provider. PSP records the transaction in their timezone, their currency (before conversion), and with their transaction ID. Your platform receives a webhook, creates an internal deposit record, credits the player’s account, applies any bonuses, and (hopefully) fires a postback<\/a> to your affiliate system.<\/p>\n\n\n\n Wagering activity<\/strong> generates gaming logs in your platform. Every bet, every win, every loss gets recorded. Your platform calculates Net Gaming Revenue (NGR<\/a>) by subtracting wins from wagers and deducting bonus costs. But which bonus costs? The welcome bonus the affiliate’s player used? Or all bonuses including retention bonuses you gave them three months later?<\/p>\n\n\n\n Revenue attribution<\/strong> is where it all falls apart.<\/p>\n\n\n\n Your affiliate system needs to know: which affiliate gets credit, how much revenue did this player generate, what commission do we owe?<\/p>\n\n\n\n Your platform knows: this player wagered X, won Y, generated Z in NGR.<\/p>\n\n\n\n Your PSP knows: this player deposited A, withdrew B.<\/p>\n\n\n\n Your CRM knows: this player is tagged with affiliate ID C but also came through a retargeting campaign last week.<\/p>\n\n\n\n None of these systems agree on the numbers. They weren’t designed to.<\/p>\n\n\n\n The fundamental problem is event definition mismatch.<\/p>\n\n\n\n When does a “conversion” happen in your affiliate system? At registration? At first deposit? At first qualified wager? Different operators define this differently, and even within one operator, the definition might vary by affiliate tier or traffic source.<\/p>\n\n\n\n Your top affiliate sends traffic on January 15th. Player registers same day. That’s a conversion in your affiliate tracker\u2014timestamp But the player doesn’t deposit until January 17th after KYC approval. Your iGaming platform records the “first deposit” event at Your affiliate dashboard shows a January 15th conversion. Your platform revenue reports show a January 17th first-time depositor. Your finance team is trying to reconcile these for monthly reporting and the dates don’t match.<\/p>\n\n\n\n Multiply this by 50,000 players per month.<\/p>\n\n\n\n Now add timezone drift. Your affiliate system runs in UTC. Your platform runs in Malta time (CET). Your PSP runs in UK time (GMT, or BST during summer). Your BI pulls data from all three and displays it in your local timezone.<\/p>\n\n\n\n A deposit that happened at 23:45 Malta time on January 31st becomes February 1st in UTC. Your January affiliate report includes this deposit. Your platform’s January revenue report doesn’t. You’re off by one day, and across thousands of transactions, this creates significant deltas.<\/p>\n\n\n\n Your casino accepts EUR, USD, GBP, CAD, and a dozen other currencies. Your affiliates get paid in EUR. Your PSP settles some currencies at different rates than your platform’s internal conversion.<\/p>\n\n\n\n Player deposits $100 USD on January 10th. Your PSP converts this to EUR at the current rate: \u20ac92.15. Your platform records \u20ac92.15 in the player’s account.<\/p>\n\n\n\n But your affiliate system calculates commission based on revenue, and it pulls revenue data from your platform API on January 31st when you run monthly reports. Your platform stores revenue in the currency the player used (USD), then converts to EUR for reporting. But it uses January 31st exchange rates: now $100 = \u20ac94.30.<\/p>\n\n\n\n Your affiliate report shows \u20ac94.30 in attributed deposits. Your PSP settlement shows \u20ac92.15 actually received. Delta: \u20ac2.15 per transaction. Across 10,000 USD deposits per month: \u20ac21,500 discrepancy.<\/p>\n\n\n\n Which number is correct? Both. They’re measuring different things at different times.<\/p>\n\n\n\n Some operators solve this by fixing exchange rates monthly. On January 1st, you lock in rates for the entire month. Every transaction uses those rates regardless of actual conversion. This creates consistency between systems but introduces basis risk\u2014if rates move significantly, you’re either over-paying or under-paying based on reality.<\/p>\n\n\n\n Others use transaction-time rates but then face the reconciliation nightmare of matching transactions across systems with different conversion timestamps.<\/p>\n\n\n\n There’s no perfect solution. Only trade-offs.<\/p>\n\n\n\n Your affiliate system uses browser cookies and click IDs to track players. Your platform uses email addresses and player IDs. Your CRM uses device fingerprinting and account credentials.<\/p>\n\n\n\n Player clicks Affiliate A’s link on mobile. Cookie gets set. Player browses, leaves without registering.<\/p>\n\n\n\n Three days later, player clicks Affiliate B’s link on desktop. New cookie. Player registers. Affiliate B gets credited with the registration in your tracking system.<\/p>\n\n\n\n But the player used the same email address they had entered in a “notify me” form from Affiliate A’s initial visit. Your CRM flags this as Affiliate A’s lead. Your platform sees one player ID, one registration, doesn’t know about the cookie conflict.<\/p>\n\n\n\n Who gets the commission?<\/p>\n\n\n\n Your deduplication rules determine this. First-touch attribution gives it to Affiliate A. Last-touch gives it to Affiliate B. Linear splits it between them. Time-decay weights it toward the most recent touch.<\/p>\n\n\n\n But here’s the problem: your affiliate system might use last-touch while your BI system uses first-touch for internal reporting. You’re measuring the same player registrations with different attribution models.<\/p>\n\n\n\n Your affiliate dashboard shows Affiliate B drove 1,000 registrations this month. Your BI dashboard attributes 1,000 registrations to various sources using first-touch, and only 600 of those go to Affiliate B.<\/p>\n\n\n\n Same data. Different rules. Irreconcilable numbers.<\/p>\n\n\n\n Let’s talk about what “revenue” actually means because every system defines it differently.<\/p>\n\n\n\n Gross Gaming Revenue (GGR<\/a>)<\/strong>: Total wagers minus total wins. This is what most gaming platforms calculate. Player bets \u20ac1,000, wins \u20ac700, GGR = \u20ac300.<\/p>\n\n\n\n Net Gaming Revenue<\/a> (NGR)<\/strong>: GGR minus bonuses and other costs. That same \u20ac300 GGR becomes \u20ac180 NGR after deducting the \u20ac120 welcome bonus you gave the player.<\/p>\n\n\n\n Net Revenue (to operator)<\/strong>: NGR minus payment processing<\/a> fees, chargebacks, taxes, game provider fees. That \u20ac180 NGR becomes \u20ac95 after all deductions.<\/p>\n\n\n\n Which number do you pay affiliate commissions on?<\/p>\n\n\n\n Most affiliate agreements specify “Net Gaming Revenue” but don’t clearly define whether that’s before or after payment fees, whether it includes or excludes bonus costs, and which bonuses count (only acquisition bonuses? or retention bonuses too?).<\/p>\n\n\n\n Your affiliate system might be calculating commission on GGR because that’s what your platform API returns by default. Your finance team is calculating payouts based on fully-loaded net revenue after all costs. The delta is massive.<\/p>\n\n\n\n I’ve seen operators where affiliate commission was calculated on \u20ac2.4M in monthly “revenue” while the actual net revenue to the operator after all costs was \u20ac1.7M. They were paying 30% commission on phantom revenue that didn’t exist after real costs.<\/p>\n\n\n\n The fix isn’t technical. It’s definitional. You need agreement across teams on which revenue figure is the source of truth for affiliate payouts, then ensure all systems calculate and report that exact figure consistently.<\/p>\n\n\n\n Player deposits \u20ac500 via credit card. Plays, loses \u20ac300, withdraws \u20ac200. Your affiliate gets credited with \u20ac300 NGR. Commission paid.<\/p>\n\n\n\n Sixty days later, the player disputes the original \u20ac500 deposit with their bank. Chargeback approved. You lose \u20ac500.<\/p>\n\n\n\n Does your affiliate system automatically deduct \u20ac300 from that affiliate’s revenue? Does it claw back the commission you already paid?<\/p>\n\n\n\n Most affiliate platforms don’t have native chargeback handling. You need to manually create a negative revenue adjustment, associate it with the correct player and affiliate, and ensure it appears in the next payout cycle.<\/p>\n\n\n\n But your PSP records chargebacks in their system with their transaction IDs. Your platform records them with player IDs. Your affiliate system needs affiliate IDs and click IDs. Linking these three identifiers across systems to create the correct adjustment is manual, error-prone, and often incomplete.<\/p>\n\n\n\n Operators typically handle chargebacks in one of three ways:<\/p>\n\n\n\n Ignore them for affiliate purposes.<\/strong> Treat chargebacks as operator risk, don’t adjust affiliate revenue. Simple but expensive.<\/p>\n\n\n\n Deduct from future revenue.<\/strong> When a chargeback occurs, create a negative revenue entry that offsets future commissions. Works if the affiliate continues sending traffic. Fails if they don’t\u2014you’re stuck with the loss.<\/p>\n\n\n\n Immediate clawback.<\/strong> Subtract chargebacks from the current month’s payout. Requires tracking chargeback-to-affiliate mapping in real-time. Complex but accurate.<\/p>\n\n\n\n Each approach creates different reconciliation requirements and different month-end numbers.<\/p>\n\n\n\n You offer a 100% deposit match up to \u20ac200. Player deposits \u20ac200, gets \u20ac200 bonus, has \u20ac400 to play with. They wager \u20ac400, win \u20ac100, cash out \u20ac100.<\/p>\n\n\n\n What’s the NGR for affiliate commission purposes?<\/p>\n\n\n\n Scenario A<\/strong>: Wagers (\u20ac400) – Wins (\u20ac100) – Bonus Cost (\u20ac200) = \u20ac100 NGR<\/p>\n\n\n\n Scenario B<\/strong>: Only count non-bonus funds. Wagers (\u20ac200) – Wins (\u20ac50) = \u20ac150 NGR<\/p>\n\n\n\n Scenario C<\/strong>: Count all wagering but exclude bonus cost. Wagers (\u20ac400) – Wins (\u20ac100) = \u20ac300 GGR, no bonus deduction<\/p>\n\n\n\n Your affiliate agreement probably specifies one of these, but does your platform calculate it that way? Does your affiliate system apply the same logic?<\/p>\n\n\n\n We, the team behind Scaleo<\/a>, have analyzed hundreds of casino affiliate programs and found that bonus cost allocation is the single most common source of reconciliation discrepancies. The platform calculates one way, the affiliate system calculates another, and nobody notices until month-end when the numbers are 12% apart.<\/p>\n\n\n\n Compounding this: retention bonuses. A player comes through Affiliate A in January. You give them a welcome bonus. They play, generate revenue, Affiliate A gets commission. In March, you run a reload bonus promotion to retain players. The same player uses a \u20ac50 reload bonus.<\/p>\n\n\n\n Do you deduct that \u20ac50 bonus cost from Affiliate A’s March revenue? The affiliate didn’t drive the reload\u2014you gave it to retain a churning player. But it reduces the player’s NGR.<\/p>\n\n\n\n Some operators deduct all bonus costs from affiliate revenue regardless of source. Others only deduct acquisition bonuses directly tied to the affiliate’s traffic. Others use a hybrid model where acquisition bonuses are fully deducted but retention bonuses are only partially allocated.<\/p>\n\n\n\n There’s no industry standard. Only what you define in your agreements and configure in your systems.<\/p>\n\n\n\n Most casino affiliate programs hold payouts for 30-60 days to account for potential chargebacks, fraud, or player refunds. But your platform reports revenue in real-time.<\/p>\n\n\n\n Your gaming platform shows \u20ac500,000 NGR for January. But your affiliate payouts for January won’t process until March 1st, and even then, you’re paying for revenue with a 60-day lookback period.<\/p>\n\n\n\n In March, you’re paying for:<\/p>\n\n\n\n Your finance team is reconciling January platform revenue (\u20ac500K) against March affiliate payouts (\u20ac427K for January traffic, but the number includes adjustments from December and excludes pending holds).<\/p>\n\n\n\n The numbers can’t match because they’re measuring different time periods with different recognition rules.<\/p>\n\n\n\n You need a separate reconciliation framework that accounts for:<\/p>\n\n\n\n Your biggest affiliate questions why their February payout is \u20ac8,000 less than they calculated. They want an explanation.<\/p>\n\n\n\n You need to show:<\/p>\n\n\n\n This requires joining data across your affiliate system, gaming platform, payment processor, and possibly CRM. Most operators don’t have this in a queryable format.<\/p>\n\n\n\n Your affiliate system shows high-level numbers: 847 registrations, \u20ac124,000 NGR, \u20ac31,000 commission.<\/p>\n\n\n\n Your platform has player-level detail but doesn’t store affiliate attribution long-term.<\/p>\n\n\n\n Your PSP has transaction detail but doesn’t know about affiliate IDs.<\/p>\n\n\n\n To answer the affiliate’s question, you need someone to manually pull reports from three systems, export to Excel, VLOOKUP the data together, and hope the player IDs match across systems.<\/p>\n\n\n\n This takes hours. For one affiliate inquiry.<\/p>\n\n\n\n Multiply by 200 active affiliates per month asking questions, and you have a full-time reconciliation team doing nothing but manual data joins.<\/p>\n\n\n\n Here’s what a proper casino affiliate reconciliation system needs:<\/p>\n\n\n\n Unified event logging.<\/strong> Every significant player action\u2014click, registration, deposit, wager, withdrawal, chargeback\u2014gets logged to a central data warehouse with consistent identifiers (player ID, affiliate ID, click ID, transaction ID) and consistent timestamps (store everything in UTC, convert for display only).<\/p>\n\n\n\n Revenue calculation engine.<\/strong> One system calculates NGR using agreed-upon rules. Not your platform’s default calculation. Not your affiliate system’s estimate. A dedicated calculation engine that applies your specific bonus allocation rules, currency conversion rules, and cost deduction rules. This becomes the source of truth.<\/p>\n\n\n\n Automated matching.<\/strong> Build ETL processes that pull data from platform, PSP, and affiliate system daily, match transactions using multiple identifiers (player ID + timestamp + amount), flag mismatches for review, and auto-reconcile matches.<\/p>\n\n\n\n Adjustment workflow.<\/strong> When chargebacks, refunds, or fraud occurs, create a standardized adjustment record that flows through all systems. Don’t manually update three databases. Create the adjustment once, let it propagate.<\/p>\n\n\n\n Reporting layer.<\/strong> Build dashboards that show the same numbers regardless of which team is looking. Finance sees the same affiliate revenue numbers that the affiliate manager sees that the affiliates themselves see. One source of truth, multiple views.<\/p>\n\n\n\n Is this complex? Yes.<\/p>\n\n\n\n Is it necessary at scale? Absolutely.<\/p>\n\n\n\n Operators processing \u20ac10M+ in monthly affiliate-attributed revenue cannot function on manual reconciliation. The error rate is too high, the time cost is too expensive, and the compliance risk is too significant.<\/p>\n\n\n\n The reconciliation problem exists because legacy affiliate systems were built as standalone tracking platforms, not as integrated components of a multi-system casino tech stack.<\/p>\n\n\n\n![\"partner](\"https:\/\/www.scaleo.io\/blog\/wp-content\/uploads\/2023\/01\/scaleo-partner-marketing-software-developed-fori-igaming-industry-scaled.jpg\" "\\"-\\"")
<\/a><\/figure>\n\n\n\nThe Multi-System Reality of Casino Affiliate Tracking<\/h2>\n\n\n\n
Event Mapping: Where Attribution Breaks Down<\/h2>\n\n\n\n
2026-01-15 23:47:33 UTC<\/code>.<\/p>\n\n\n\n2026-01-17 14:22:11 CET<\/code> (which is 13:22:11 UTC<\/code>, but your platform stored it in local time).<\/p>\n\n\n\nCurrency Conversion: The Silent Revenue Killer<\/h2>\n\n\n\n
Deduplication Rules: When Multiple Systems See the Same Player<\/h2>\n\n\n\n
Revenue Definition Chaos: Net vs Gross vs NGR vs GGR<\/h2>\n\n\n\n
Chargeback Handling: The Reconciliation Nightmare<\/h2>\n\n\n\n
Bonus Cost Allocation: Who Pays for Player Incentives?<\/h2>\n\n\n\n
![\"-\"](\"https:\/\/www.scaleo.io\/blog\/wp-content\/uploads\/2025\/12\/scaleo-casino-operator-affiliate-software-dashboard-screenshot.webp\" "\\"-\\"")
<\/figure>\n\n\n\nPayout Holds and Pending Revenue: Timing Mismatches<\/h2>\n\n\n\n
\n
\n
The Audit Trail Problem: Proving the Numbers<\/h2>\n\n\n\n
\n
Building a Reconciliation Framework That Actually Works<\/h2>\n\n\n\n
How Modern Affiliate Platforms Solve Multi-System Reconciliation<\/h2>\n\n\n\n
![\"-\"](\"https:\/\/www.scaleo.io\/blog\/wp-content\/uploads\/2025\/07\/scaleo-perfect-affiliate-software-for-gambling-business.webp\" "\\"-\\"")
<\/figure>\n\n\n\n