Home About Why Session Reporting
Process & Workflow Pricing Case Study
Contact Us
Real Engagement

Case Study

Three years, one IRS notice, and a platform that said the data didn't exist.

How We Reconstructed 3 Years of Gambling Records for an IRS Notice
How We Reconstructed 3 Years of Gambling Records for an IRS Notice

Note: this video may be AI-generated, but the thinking behind it comes from our rigorous, hands-on experience with this work.

Case Study

Three Years, One Notice, and a Platform That Said the Data Didn't Exist

A CPA partner needed a defensible, session-level accounting of activity going back to 2021, not just the current tax year, after their client received an IRS notice flagging unreported gambling income.

How It Started

We were brought into this engagement by a CPA partner who had a client in a difficult spot. The client had received an IRS notice flagging unreported gambling income, and the CPA needed a defensible, session level accounting of activity going back to 2021, not just the current tax year. The CPA had the notice and the client relationship. What they didn't have, and what they came to us for, was a way to actually reconstruct three years of betting history from a platform that, on its face, didn't make that possible.

The client himself wasn't a simple case either. He had been active across sports betting, table games, and poker, often within the same stretches of time, all on BetMGM. That mix matters more than it might sound like, because sports bets, casino games, and poker tournaments each follow different session logic under IRS guidance. Before we could even think about totals, we needed to separate three years of mixed activity by type.

The First Wall: A Platform That Only Remembered Six Months

The moment we requested the underlying data, the scope of the problem became clear. BetMGM's self service tools only displayed the trailing six months of account activity. There was no export function. Nothing to click, nothing to download. For a notice that reached back to 2021, that meant roughly two and a half years of exactly the data we needed simply wasn't visible through any normal channel the client or we could access.

This is where a straightforward data request turned into something closer to a sustained negotiation with the platform itself.

Two Weeks of Pushing Against a Moving Target

Getting BetMGM to release historical data outside its standard retention window took nearly two weeks of continuous back and forth, and the friction wasn't a single obstacle. It was several, stacked on top of each other.

Support was chat only. There was no email channel, and nothing in writing carried over from one conversation to the next. Every time we needed to reference something said earlier, there was no record to point back to. We ended up re-explaining the same request more than once simply because of this.

The answers we received depended entirely on who happened to answer. One agent confirmed that data going back to 2021 existed and could be retrieved. The next day, a different agent told us flatly that anything older than six months was no longer available. There was no way to reconcile these two answers, because neither one was ever documented anywhere we could refer back to.

More than once, support tried to close the request out entirely by offering the annual win loss statement instead, and pushed back when we explained that a summary wasn't sufficient. A net win loss figure tells you nothing about individual sessions, doesn't separate sports betting from table games from poker, and wouldn't have given the CPA anything usable to respond to an IRS notice with. We held that line every time it came up.

On top of all this, every login to the account required two factor authentication, with a one time code sent live to the client's phone. Coordinating that in real time, across two weeks of intermittent back and forth with a client who had his own work schedule to manage, added friction to nearly every step along the way.

Eventually, the persistence paid off. BetMGM agreed to pull historical data covering the full 2021 to 2024 window.

The Twist: What Came Back Wasn't What We Asked For

The first file BetMGM sent wasn't a transaction level bet history at all. It was a wallet history, a record of deposits, withdrawals, and account balance movement. Useful for tracking cash flow, but completely useless for reconstructing what was actually wagered, on what, and with what outcome. We went back to support again, specifically clarifying the difference between wallet activity and bet level transaction history, and waited for a corrected file.

When the second file finally arrived, we didn't take it at face value. We cross checked it line by line against the annual statements available directly on the platform, and found gaps. Stretches of activity reflected in the annual summary simply weren't present in the detailed export. That meant a third round of follow up, on top of the two weeks already spent just getting any historical data released in the first place.

What Three Years of Raw Data Actually Looked Like

Once the file was finally complete, the real work began. This wasn't a clean spreadsheet. It was hundreds of thousands of individual bet level rows spanning three years and three different activity types, with no consistent structure to speak of. Tracing session level activity by hand simply wasn't realistic at this volume. The data needed to be systematically normalized before any session logic could be applied at all.

A few of the specific problems we worked through along the way.

Date formats that changed mid file.
Some records used MM/DD/YYYY, others used raw timestamps, and the inconsistency wasn't even limited to different sections of the export. Every date had to be normalized before anything downstream could be trusted.
Time zones that didn't match.
Some records were logged in EST, others in UTC. Left uncorrected, this shifts session boundaries in ways that matter directly. A bet placed at 11:45 PM local time can appear to fall on the wrong calendar day entirely if the time zone isn't corrected first.
Voided bets hiding inside loss totals.
Nothing in the file distinguished a voided bet from a real settled loss. Left as is, this would have inflated the client's reported losses incorrectly across multiple sessions. Each one had to be identified and pulled out individually.
Parlays broken into individual legs.
Rather than appearing as a single wager, each leg of a parlay bet showed up as its own separate row. Left unregrouped, this both inflated the total bet count and distorted session math. A four leg parlay would have looked like four unrelated bets instead of the one wager it actually was.

Bringing It Together

With the data finally clean and normalized, we separated three years of activity by type, sports betting, table games, and poker, and applied session level methodology to each category independently, consistent with how the IRS treats them differently. What started as an unusable wallet history and a platform insisting six months was all that existed eventually became a defensible, session by session reconstruction of the client's full gambling activity from 2021 through 2024.

The Takeaway

For the CPA, this meant something they didn't have at the start of the engagement. An actual position to respond to the IRS notice with, rather than a thin annual summary that raised more questions than it answered. For us, it was a reminder that the hardest part of this work often isn't the tax methodology. It's the two weeks of persistence it takes just to get a platform to acknowledge that the data still exists at all.