Prediction Market Accounting: A Technical Guide for Traders, Funds, and Institutions

Last Updated on June 25, 2026 by Patrick Camuso, CPA

Quick answer

The core problem: Prediction market platforms produce transaction-level data not designed for accounting or tax purposes.

Who this affects: Retail traders reconciling year-end positions, algorithmic traders and market makers running daily books, entities with audit or financial reporting obligations, and funds that need GAAP-compliant financial statements.

What is missing: The platforms issue no standardized tax forms for event contract activity. GAAP has no guidance on how to classify open positions on a balance sheet and there is no chart of accounts exists for this asset class. Every trader and institution that takes this seriously builds the methodology and a prediction market accounting system from scratch, like we already did at Camuso CPA.

The tax debate around prediction markets gets most of the attention. Patrick Camuso recently published Prediction Market Tax Analysis in Tax Notes analysing this tax classification issues. Those questions matter and remain unsettled but accounting is a separate problem.  The gap between what platforms provide and what traders and institutions actually need is large enough to produce a deficient return before the characterization question is even reached.

The Data Problem

Every prediction market platform produces some version of transaction history but none of them produce accounting records. The data was built to show traders what happened to their positions, not to support a general ledger, a tax return, or an audit. The gap between those two purposes is where the accounting work begins.

The specific problems vary by platform but the pattern is consistent overall with values in non-standard units, no category separation, no character determination, no session-level structure, and no connection to the forms needed to complete a return.

Kalshi is the clearest example of the unit problem since its CSV exports store all monetary values in cents, not dollars. Summing the P&L column without dividing by 100 overstates gains or losses by a factor of 100. The column header reads “realized_pnl_with_fees_cents” but that is easy to miss in a high-volume file with tens of thousands of rows. Beyond the unit issue, Kalshi produces no gain and loss summaries by contract category, no short-term versus long-term separation, and applies no accounting characterization to the data.

Robinhood also illustrates the aggregation problem since its Event Contracts Annual Statement explicitly states it is not a substitute tax reporting form. It contains aggregate figures only, no contract-level detail, no separation of sports from macro or political contracts, no holding period information, no session-level data. A trader who needs contract-by-contract records for a capital treatment return has to reconstruct everything from transaction history.

Polymarket is the most labor-intensive since it produces no standardized data. All activity is on the Polygon blockchain, so transaction history must be reconstructed from wallet-level on-chain records and then reconciled against Polymarket’s native portfolio export. USDC settlement adds a parallel layer, receiving USDC at contract settlement and subsequently converting it to USD are two separate taxable events, each requiring its own accounting entry.

Retail Trader Accounting

The platform gives you a transaction history but the tax return needs a complete contract-level record of acquisitions and dispositions. The minimum record for each contract includes acquisition date, cost in the platform’s unit of account, disposition date, and proceeds. For Kalshi, every value must be divided by 100 before it enters any accounting record. For Polymarket, the USDC received at settlement has a dollar-equivalent fair market value that becomes the proceeds figure and the cost basis for the USDC position, with the USD conversion recorded separately.

A retail trader with several thousand contracts cannot reconcile manually. Any automated output needs manual verification before it supports a filing.

For retail traders under gambling treatment, the IRS requires per-session tracking, with winning and losing sessions recorded separately. None of the platforms produce session-level data. This is exactly the kind of structure the tax law requires and the platforms have no reason to build. A session methodology must be adopted, documented, and applied consistently across the year. That choice directly affects the gross winnings figure that caps deductible losses.

Four record-keeping requirements apply at the retail level that no platform export satisfies on its own. Each one represents information the platform tracks for trading purposes but does not produce in the form accounting or tax requires.

The first is how each contract was closed. Whether a position was sold before maturity or held to resolution affects how the gain or loss is characterized, and platforms do not always make the distinction clear in their exports.  The second is contract category. Platform exports do not reliably separate sports contracts from macro or political contracts.  The third is lot identification methodology. When the same contract is acquired in multiple lots at different prices, which lot’s cost basis applies to a partial sale is a meaningful question with real dollar consequences.  The fourth is how platform fees are treated. Whether fees are added to cost basis or deducted as a business expense depends on the trader’s facts and the applicable tax rules.

Most retail traders arrive at tax time with a platform export and not much else. No accounting software handles this natively and no platform produces data in a form that maps directly to a return. Reconstruction is possible but it is manual work, and the further from the original activity, the harder it gets.

Each platform presents a different version of the same problem. Kalshi’s full transaction history export is the starting point, not the summary, and every monetary value must be divided by 100. Contract category and disposition type are not always clear from the export and may need to be verified against the event record. Robinhood’s Annual Statement is an aggregate document; contract-level detail requires pulling the full transaction history separately. Polymarket requires starting from the wallet itself, using a Polygon block explorer to reconstruct activity that the platform’s own export may not fully capture, with USDC settlement values needing a fair market value at the time of each transaction.

Across all three, the practical reality is the same since a trader who reviews and categorizes activity monthly has a manageable problem at year-end. One who starts in March with twelve months of unreviewed exports has a reconstruction project with meaningful gaps that may not be resolvable.

Camuso CPA has developed a structured process for retail prediction market accounting that handles the normalization, categorization, and reconciliation work across all major platforms. Rather than starting from raw exports and trying to build a defensible record at filing time, we work with traders throughout the year to maintain records that support the return before it is ever prepared.

Institutional and Algorithmic Trader Accounting

For institutional participants, the data problems that create reconciliation work for retail traders become internal control failures at the institutional level. Without a structured response to the absence of standardized accounting data, a fund’s financial statements, NAV calculations, and K-1 allocations all rest on records the platform was never designed to produce.

Balance Sheet Presentation

Where open prediction market contracts appear on the balance sheet is unresolved. No accounting standard addresses event contracts directly, and there is no settled industry practice. Classification depends on how the contracts are characterized under the applicable standards, a determination that needs to be made in consultation with auditors before the first period-end close. Whatever classification is adopted, it should be disclosed in the financial statement footnotes along with the basis for it and the significant accounting policy applied, precisely because there is no authoritative guidance to point to.

Valuing Open Positions

Where observable market prices exist for prediction market contracts, fair value measurement under ASC 820 is conceptually possible. Whether those prices satisfy the Level 1 criteria, meaning quoted prices in active markets for identical assets, depends on liquidity, bid-ask spreads, and the depth of the market at the reporting date, none of which are defined for prediction market contracts by any existing standard. Thinly traded contracts raise valuation questions that exchange-traded futures do not, and the determination of which ASC 820 level applies requires judgment. Any entity marking open positions to fair value needs a documented methodology that addresses these questions and can be defended in an audit.

Market Maker Revenue

How market maker spread income is recognized is an open accounting question for this asset class. The applicable standard depends on how the entity is structured, how it characterizes its trading activity, and which industry guidance, if any, applies to its operations. None of that has been settled for prediction market activity, which means recognition policy requires a deliberate documented decision rather than a default.

A few distinctions consistently matter regardless of which recognition approach is applied. Rebate income from providing liquidity to the exchange is economically different from trading gains and generally warrants separate presentation on the income statement. Gross versus net presentation of wins and losses is a significant financial statement design decision with disclosure implications since a market maker with $50 million in gross wins and $49.5 million in gross losses looks very different on a gross basis than a net basis, and the choice affects how counterparties, lenders, and auditors read the operation. For accrual-basis entities with long-dated contracts, there is a potential year-end timing question around when income is recognized relative to when cash settles. For most short-duration prediction market contracts this is not material, but for any position that spans a reporting period, the timing policy needs to be addressed and documented.

All of these are areas where working with CPAs to establish a documented policy before the first close is more practical than trying to reconstruct the reasoning after the fact.

Audit Trail and Subledger

Institutional participants need prediction market positions in a dedicated subledger that rolls up to the general ledger. Without one, contract-level activity is invisible to the accounting system and there is no mechanism for reconciling open positions, computing period-end fair value, or producing auditable journal entries. The general ledger entry at period end reflects only what the platform reported, not what accounting and tax actually need.

The subledger carries for each position: acquisition date and cost, current fair value at each reporting date, cumulative unrealized gain or loss, and realized gain or loss at settlement. For multi-platform operations, platform identifiers allow segregation of Kalshi, Robinhood, and Polymarket activity under potentially different characterization frameworks.

Journal entries depend entirely on which accounting model applies to the entity, a determination that requires auditor alignment before the first close. Entities that apply fair value accounting, either because they are investment companies under ASC 946 or because they have established a fair value obligation through another standard or election, will record mark-to-market entries on open positions at each reporting date along with settlement entries when positions close. Entities that carry positions at cost record only the settlement entry. The point is that the journal entry structure is not predetermined by the nature of the contracts. It follows from an accounting policy determination that needs to be made deliberately, not defaulted into.

Building the Institutional Record

There is no accounting software built for this. Institutions building serious operations in this space are constructing methodology from scratch, typically through a combination of spreadsheet-based subledgers, custom data pipelines from platform exports, and manual reconciliation workpapers.

The practical starting point for any institutional operation is a data normalization layer that converts each platform’s export into a consistent format before anything enters the accounting system. For Kalshi this means cents-to-dollars conversion and category assignment. For Robinhood this means supplementing the Annual Statement with contract-level transaction history. For Polymarket this means on-chain reconstruction from the wallet, separate from the native portfolio export, with USDC values marked to market at each transaction date.  From there, the subledger needs to be populated and reconciled against each platform’s reported balances before each period close.

Camuso CPA has built purpose-built systems specifically for this. Rather than adapting general-purpose accounting tools to a problem they were not designed for, we built a process from the ground up that handles platform data normalization, subledger maintenance, and period-close reconciliation for prediction market activity. That process is what sits between the platform export and the general ledger for the institutional operations we work with.

Multi-Platform Reconciliation

An operation across Kalshi, Robinhood, and Polymarket combines three data sources that were each built for different purposes and produced in incompatible formats. Kalshi exports in cents. Robinhood provides an aggregate Annual Statement in dollars. Polymarket requires on-chain reconstruction from wallet addresses. None of them were designed to be combined. The reconciliation work is the direct consequence of each platform solving the trader’s problem without considering the accountant’s.

Where one characterization framework applies across all platforms, which is the most defensible posture, the ledger aggregates contract-level gains and losses consistently and reconciles to the return. Where different frameworks apply to different platforms, the ledger segregates by platform and framework with a documented analytical basis for each. Unexplained differences between the transaction-level record and reported figures are an audit risk under any examination standard.

What the Subledger Must Produce

A prediction market subledger exists because the platforms do not produce what accounting requires. Its job is to bridge the gap and to take what each platform provides, transform it into records that support the general ledger, the financial statements, and the tax return, and preserve the evidentiary chain connecting all three. Debits and credits are a byproduct. Every position should carry an accounting classification and a separate tax characterization field, independently updatable.

How Camuso CPA Approaches This

Camuso CPA has spent over a decade building custom accounting systems for digital asset investors, active traders, funds, and on-chain protocols. That work predates the prediction market category and covers the full range of accounting problems that arise when financial activity runs through infrastructure that was not designed with tax or audit in mind including on-chain reconstruction, multi-wallet reconciliation, token-level basis tracking, fund-level NAV computation, and the book-tax gap that opens when GAAP treatment and tax treatment diverge on novel instruments.

Prediction market accounting sits at the intersection of everything that work covers. The absence of standard-setter guidance is something we have operated in for years.

No standard software handles this. The accounting work requires methodology that does not exist in any off-the-shelf package, applied to data no platform was designed to produce. Camuso CPA built a process for it. Contact us to discuss your situation.

Frequently Asked Questions

What records does a retail prediction market trader need to support a tax filing?

At minimum a complete transaction-level data for every contract with acquisition date, cost, disposition date, and proceeds; contract category tagged at acquisition not reconstructed at year-end; a documented method for identifying which lot’s basis applies where the same contract was acquired at different prices; a record of whether each closed contract was sold before maturity or resolved at maturity; and how platform fees were treated. For traders under gambling treatment, add a contemporaneous session log. Platform exports are the starting point for all of this, not the finish line.

Is there accounting software that handles prediction market contracts?

No major platform does natively. QuickBooks, Xero, and similar systems have no contract type that maps to a binary event instrument. Crypto tax software with Polygon wallet support can help normalize Polymarket transaction data but misclassifies prediction market contracts regularly and requires manual review. Institutional participants need a purpose-built process that handles platform data normalization, subledger maintenance, and period-close reconciliation. Camuso CPA has built that process for traders, funds, and institutional operations.

Do institutional prediction market operations need a dedicated subledger?

Yes. The general ledger entry at period end reflects only the net settlement flow from the platform. That is not enough to support financial statement disclosure, tax provision calculations, NAV computation, or an audit. A dedicated subledger that rolls up to the general ledger is the structure that sits between the platform export and the accounting records. It carries acquisition date and cost, fair value at each reporting date, cumulative unrealized gain or loss, and realized gain or loss at settlement for every position. For multi-platform operations it also needs platform identifiers so activity across Kalshi, Robinhood, and Polymarket can be segregated under potentially different characterization frameworks. Without it, the accounting records cannot support the reporting, and no off-the-shelf system builds this for prediction market activity.

Does GAAP require mark-to-market accounting for prediction market positions?

It depends on the entity type. Investment companies under ASC 946 carry all investments at fair value through earnings on trade date regardless of instrument type, so mark-to-market is mandatory for funds. For other entities, the answer depends on whether the contracts qualify as derivatives under ASC 815, financial instruments under ASC 825, intangible assets under ASC 350, or something else. There is no GAAP standard that addresses prediction market event contracts directly, which means classification is a judgment call that needs to be made with auditors before the first period-end reporting date.

Do prediction market platforms issue tax forms?

No. None of the major platforms issue standardized tax forms for event contract trading activity. Kalshi provides an Event Contracts Annual Statement that it explicitly states is not a substitute tax reporting form, Robinhood provides a similar aggregate document with the same disclaimer and Polymarket issues nothing. All activity is on-chain and reconstruction starts from the wallet. No platform issues a 1099-B, 1099-DA, or W-2G for event contract dispositions. The full burden of characterizing activity, reconstructing records, and determining what to report sits entirely with the trader. The absence of a form does not affect the obligation to report.

For prediction market tax reporting and characterization analysis, see our prediction market tax guide. For professional assistance with prediction market accounting and tax reporting, contact Camuso CPA.