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

Last Updated on July 24, 2026 by Patrick Camuso, CPA

Quick answer

The core problem: Prediction market platforms produce transaction-level data that is not automatically filing-ready or ledger-ready. The records that support a tax return, a general ledger, or financial reporting have to be built from that data, and the disciplines involved are not the same.

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 and institutions that prepare financial statements under an applicable framework.

What to understand first: Platform statements and information returns vary by platform and are not substitutes for tax or accounting analysis. Which accounting answer applies depends on the entity, the contract terms, and the applicable rules and authoritative literature. A workable methodology may need to be configured to your platforms, records, systems, and reporting obligations. This guide maps the disciplines and shows where specialist analysis is needed.

The tax debate around prediction markets gets most of the attention. Patrick Camuso recently published Prediction Market Tax Analysis in Tax Notes analyzing these 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.

Prediction Market Accounting Is Not One Discipline

The phrase covers several different disciplines that share source data but answer different questions. Tax-return reporting places reportable items on the right return after character, recognition, allowance, limitation, and taxpayer capacity are analyzed. Tax-basis transaction reconstruction rebuilds acquisitions, transfers, endpoints, fees, digital-asset flows, and values from platform and wallet data; it creates a defensible evidence layer but does not decide tax character or the return form. Operational bookkeeping records platform, bank, wallet, treasury, collateral, fee, and operating activity under documented policies, and the general ledger carries the entity’s official account-level books. A subledger holds the detailed position and digital-asset records that roll into the general ledger. Reconciliation and internal controls tie the layers together and keep them supportable.

Tax accounting translates tax positions into book-tax differences and, where applicable, a tax provision process; it is not the same thing as preparing the return. U.S. GAAP financial reporting governs recognition, measurement, presentation, and disclosure for entities that report under it. Valuation is the selection and application of measurement inputs and methods at the relevant date. Market-maker and institutional accounting is an operating context that combines all of the above with treasury, allocations, and investor or owner reporting where applicable. Bookkeeping entries do not determine federal tax classification, and shared source data does not make these disciplines interchangeable.

Three Boundaries That Control the Analysis

First, a platform profit-and-loss figure, dashboard balance, annual summary, export, or tax form is not automatically taxable income, recognized gain or loss, book income, or a filing-ready record. Second, federal income-tax treatment does not automatically determine GAAP recognition, measurement, classification, presentation, or disclosure. Third, GAAP recognition or fair-value treatment does not automatically determine federal tax reporting. Platform documentation can establish operational facts, but it is not tax authority, accounting authority, or proof that a platform label controls treatment.

The Platform Data Problem

The platforms discussed here produce some version of transaction history, but that output is not automatically ledger-ready or filing-ready. 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 gaps vary by platform, but the pattern is consistent: outputs differ in units, fields, labels, completeness, and tax readiness, they apply no tax characterization, and they do not determine how activity is reported. Verify units, headers, sign conventions, and report versions against the platform’s current export before importing anything.

Kalshi

Kalshi’s help center lists four information returns issued at applicable IRS thresholds: 1099-INT for interest, 1099-MISC for credits and rewards, 1099-B for certain broker transactions such as crypto transfers, and 1099-DA for digital asset transaction reporting. Kalshi also provides a yearly PnL statement computed on a FIFO basis and updated monthly. None of these documents is an event-contract trading tax form, none applies a tax characterization, and none determines how activity is reported. Export fields and units should be verified against the current file before use.

Robinhood

Robinhood’s Event Contracts Annual Statement includes individual event-contract transactions, closing dates, costs, proceeds, fees and commissions, and net profits and losses. Robinhood states that the annual statement is not a substitute tax reporting form, that it does not provide a 1099 for event contract trades, and that event contract trades are not reported to the IRS by Robinhood. The statement supplies transaction data, not tax characterization, and its completeness for your reporting needs must be tested.

Polymarket

Polymarket’s current on-chain exchange uses pUSD, an ERC-20 token on Polygon backed one-for-one by USDC, as its collateral and user-facing redemption asset; underlying protocol mechanics may involve native USDC. Activity is reconstructed from wallet-level on-chain records and reconciled against available platform records. The prediction-market position, the settlement asset, transfers, conversions between pUSD and USDC, and any later dispositions are separate analytical layers. Record quantities, timestamps, wallet flows, and fair market values as facts; the tax recognition and basis consequences depend on the contract endpoint, the transaction mechanics, and the ownership facts.

Retail Trader Accounting

The platform gives you a transaction history; a tax filing needs records that substantiate whatever reporting framework and measurement method ultimately apply. Useful records for each contract include the acquisition date and cost, the disposition or resolution details, the amounts received, and directly related fees, in the platform’s stated units after those units are verified. That record detail matters regardless of the reporting unit ultimately used. Reconstruction is the evidence layer since it does not itself determine tax character, and it is not the same thing as bookkeeping or return preparation. An actual pre-resolution transfer of a contract right to another participant for consideration may be described as a sale. Treatment of a position held to resolution depends on the contract terms and platform mechanics.

A retail trader with several thousand contracts is unlikely to reconcile the record by hand, and automated output needs manual review and reconciliation before it supports a filing.

Where the wagering rules apply, published guidance does not establish a required transaction or session unit for prediction-market activity. The measurement method adopted affects measured wagering gains and losses, so it should be supportable, documented, and applied consistently. Platform data may not be organized in the measurement unit ultimately adopted, which is one more reason to preserve detailed records. For the loss framework, see our prediction market loss deductions analysis.

Four record-keeping categories may require supplemental records at the retail level because a platform export may not satisfy them on its own. Each may involve information a platform records for trading purposes but does not present in the form needed for the adopted tax or accounting treatment.

Whether a position was sold before maturity or held to resolution affects how the analysis proceeds, and platforms do not always make the distinction clear in their exports. Platform exports do not reliably separate contract categories, and materially different categories may require separate analysis. When the same contract is acquired in multiple lots at different prices, which lot’s cost applies to a partial sale is a meaningful question with real dollar consequences. Whether fees are added to cost, netted in proceeds, or otherwise classified depends on the trader’s facts and the applicable tax rules.

A trader who arrives at tax time with only a platform export faces a reconstruction project. General-purpose accounting software and crypto tax tools may omit required fields, apply assumptions, or require manual review and reconciliation for prediction-market activity, and no export maps to a return without classification work. Reconstruction is possible, but 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, rather than any summary document, is the practical starting point, with units and fields verified against the current file and contract categories checked against the event record. Robinhood’s Annual Statement provides transaction-level detail but no characterization, and completeness must be tested against the full transaction history. Polymarket starts from the wallet, using a Polygon block explorer to reconstruct activity and reconcile it against available platform records, with digital-asset values measured at the relevant dates.

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 records and tax reporting support that handles the normalization, categorization, and reconciliation work across the 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.

Funds and Institutions: Books, Financial Reporting, and Controls

For institutional participants, the data gaps that create reconciliation work for retail traders become control failures if left unmanaged. Without a structured response, an entity’s financial statements, NAV calculations, investor or owner reporting, and allocations, where applicable, rest on records the platform was never designed to produce.

Platform labels and flows are source facts, not classifications. A platform balance is not automatically cash or a cash equivalent; deposits and withdrawals are not automatically income or expenses; collateral is not automatically an expense; trading gains are not automatically revenue; and trading losses are not automatically operating expenses. Each item is classified under the entity’s documented policies, the contractual rights and restrictions that actually apply, and the applicable accounting framework.

Bookkeeping and the general ledger

Operational bookkeeping records platform, bank, wallet, treasury, collateral, fee, and operating activity under documented policies, and the general ledger carries the entity’s official account-level books and period-end balances. The general ledger alone rarely preserves the detail that tax support or valuation work requires, which is why the subledger layer exists.

Subledger design

A position and digital-asset subledger carries the detail: acquisition dates and costs, endpoint status, settlement data, fees, transfers, wallet flows, source identifiers, timestamps, and reconciliation keys, with fair-value fields included where the applicable framework or management policy requires them. For multi-platform operations, platform identifiers allow activity to be segregated where materially different contract categories require separate analysis. Every position should carry an accounting classification and a separate tax characterization field, independently updatable. A tax-basis subledger is not automatically the GAAP ledger: the two layers can share source data while carrying separate classifications, measurements, and reconciliations, connected by a documented bridge. Detailed subledger records preserve flexibility; they do not prescribe the tax unit of account.

Journal entries follow the entity’s documented recognition and measurement conclusions, made with auditor alignment before the first close, and they should reconcile to the subledger. The 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.

Reconciliation and close

An operation across Kalshi, Robinhood, and Polymarket combines data sources that were built for different purposes and produced in different formats, and none of them were designed to be combined. The close process ties platform records, wallet data, bank activity, the subledger, the general ledger, valuation support where applicable, and the reporting outputs, and it resolves the differences.

The practical starting point is a data normalization layer that converts each platform’s output into a consistent format before anything enters the accounting system, with units and fields verified per platform, completeness tested, and digital-asset values measured at the relevant dates. From there, the subledger is populated and reconciled against each platform’s reported balances before each period close.

Where one concluded tax framework applies to the activity, the records aggregate consistently and reconcile to the return. Where materially different contract categories or activities require separate analysis, the records segregate them with a documented analytical basis for each. Unresolved differences between the transaction-level record and reported figures undermine close integrity, substantiation, and audit readiness.

Internal controls and audit trail

As an operational best practice, institutional operations need completeness checks, access and approval controls, pricing and exception procedures, documented policy changes, and an evidentiary chain connecting source data to the subledger, the general ledger, the financial statements where applicable, and the tax return. Without that structure, contract-level activity is invisible to the accounting system, and the period-end balance reflects only what the platform reported rather than what the books and the return require.

Tax Accounting and Book-Tax Differences

Tax accounting is a separate discipline from return preparation and from tax-basis reconstruction. For entities that prepare financial statements, book and tax recognition, measurement, character, and timing can differ, and those differences feed a documented book-tax bridge and, where applicable, a tax provision process covering current and deferred amounts and uncertain positions. Whether and where differences arise depends on the entity’s accounting framework and its tax positions; no particular difference arises in every case, and this guide does not calculate a provision or resolve those questions. What matters at the umbrella level is preserving the parallel book and tax attributes and the reconciliations that make the bridge auditable.

U.S. GAAP Financial Reporting

An entity must identify the contractual rights and obligations, determine which accounting guidance applies, and evaluate recognition, measurement, presentation, and disclosure based on its facts. Where open positions appear on the balance sheet, how they are measured, and what is disclosed are determinations to align with the entity’s auditors before the first period-end close, and the accounting policies adopted should be documented and disclosed as the applicable framework requires. This guide identifies the questions; it does not resolve them.

Fair Value and Valuation

Valuation is a separate workstream from recognition. Platform display values, quoted prices, bids, asks, midpoints, settlement values, and redemption values are not interchangeable, and none of them is automatically the measurement the applicable framework requires. Quoted prices, liquidity, bid-ask spreads, market depth, resolution mechanics, and reporting-date facts may all bear on the analysis, and thinly traded contracts raise questions that deep markets do not. An entity that must measure open positions needs a documented methodology appropriate to its framework and facts; the methodology itself is a specialist determination this guide does not make.

Market-Maker Accounting Considerations

Market-making and liquidity activity may produce economically different categories of receipts, costs, positions, and obligations. Their tax and financial-reporting treatment depends on the agreements, activity, legal rights, and applicable accounting rules. Trading results, spreads, rebates, maker incentives, fees, collateral movements, treasury activity, and service compensation are separate data streams that should be tracked separately; none of them is automatically revenue, a contra-expense, or trading gain, and no label should be adopted before the classification analysis is done.

The operational separations matter regardless of how classification ultimately resolves, because segregating the streams preserves the ability to classify each one correctly later. How results are presented in the financial statements, including gross-versus-net questions, and when amounts are recognized relative to cash settlement for positions that span a reporting period, are entity-specific determinations to resolve with the entity’s auditors and advisors; this guide does not resolve them.

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

What a Prediction-Market Subledger Should Produce

A prediction market subledger exists because platform output does not automatically provide what the books, the financial statements where applicable, and the tax return require. Its job is to take what each platform provides, transform it into records that support each of those layers, and preserve the evidentiary chain connecting all of them. Debits and credits are a byproduct. The tax-basis records and the book records are separate layers even when they share source data, and the subledger should support both without collapsing them.

When Specialist Analysis Is Required

Tax characterization and the loss framework are covered in our prediction market tax guide and our prediction market loss deductions analysis. Reconstruction beyond what platform exports support is the subject of our crypto cost basis reconstruction work. GAAP classification and measurement, valuation methodology, tax accounting and provision work, and market-maker accounting each require specialist analysis configured to the entity, and dedicated analyses of those areas are planned. Where a question in this guide affects your filing or your financial statements, the right time to resolve it is before the return is filed or the first close is run, not after.

How Camuso CPA Helps

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: novel instruments, data that has to be rebuilt from source records, and book and tax layers that have to stay reconciled.

Whether existing software is sufficient depends on the transaction volume, available fields, platform exports, wallet activity, position mechanics, entity structure, reporting objectives, and the ability to reconcile source data to the final records. Where it is not sufficient on its own, the methodology has to be configured to the engagement, and Camuso CPA has built a process for that: platform data normalization, subledger maintenance, and period-close reconciliation for prediction market activity, for both retail engagements and the institutional operations we work with. 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, complete transaction-level data for every contract with acquisition date, cost, disposition or resolution details, and amounts received; contract category tagged at acquisition rather than reconstructed at year-end; a documented method for identifying which lot’s cost 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. Where the wagering rules apply, add a contemporaneous log supporting whatever measurement method is adopted, since published guidance prescribes no required unit. Detailed records matter regardless of the reporting unit ultimately used. Platform exports are the starting point for all of this, not the finish line.

Is there accounting software that handles prediction market contracts?

It depends on the engagement. General-purpose systems such as QuickBooks and Xero were not designed around binary event instruments, and crypto tax software with Polygon wallet support can help normalize on-chain data. Any of these tools may omit required fields, apply assumptions, or require manual review and reconciliation before their output supports a filing or a close. Whether existing software is sufficient depends on the transaction volume, available fields, platform exports, wallet activity, position mechanics, entity structure, and reporting objectives. Camuso CPA configures and maintains that process for traders, funds, and institutional operations.

Do institutional prediction market operations need a dedicated subledger?

As an operational best practice, institutional operations generally benefit from one. A period-end general ledger balance alone rarely supports financial statement disclosure, tax provision work where applicable, NAV computation where applicable, or an audit. A dedicated subledger that rolls up to the general ledger carries acquisition data, endpoint status, realized results, fees, transfers, and source identifiers for every position, with fair-value fields where the applicable framework or management policy requires them, and platform identifiers so activity can be segregated where materially different contract categories require separate analysis. The tax-basis records and the book records remain separate layers even when they share this source data.

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

That depends on the entity, the contracts, and the applicable authoritative literature. U.S. GAAP does not begin with the platform’s label: an entity must identify the contractual rights and obligations, determine which accounting guidance applies, and evaluate recognition, measurement, presentation, and disclosure based on its facts. Those determinations should be aligned with the entity’s auditors before the first period-end reporting date, and the policies adopted should be documented. The detailed analysis is a specialist workstream this guide does not resolve.

Do prediction market platforms issue tax forms?

It varies by platform, and no platform document determines federal tax treatment. Kalshi’s help center lists 1099-INT, 1099-MISC, 1099-B, and 1099-DA at applicable IRS thresholds, plus a yearly FIFO PnL statement; none is an event-contract trading tax form. Robinhood provides a transaction-level Event Contracts Annual Statement, states that it is not a substitute tax reporting form, does not provide a 1099 for event contract trades, and states that event contract trades are not reported to the IRS by Robinhood. Polymarket’s on-chain environment provides no standardized tax forms, and reconstruction starts from the wallet; the regulated U.S. platform’s practices should be confirmed directly. The reporting obligation does not depend on receiving a form.

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