Tracking your Kalshi P&L for taxes starts with the trade history CSV you can export from your account — but the raw numbers in that file aren't in dollars. Kalshi represents prices and fees in cents as plain integers, both in its API and in every export, and if you total those columns directly in a spreadsheet or tax tool, your P&L will come out exactly 100 times too big or too small.
This trips up more Kalshi traders at tax time than almost anything else — and it's especially costly if you're running arbitrage across Polymarket, where prices export as normal dollars-and-cents decimals. A ÷100 error on one platform and not the other makes your combined numbers meaningless. Here's exactly how to export, clean, and reconcile Kalshi data so the P&L you report is the P&L you actually made.
What Kalshi's export actually gives you
From your Kalshi account, the trade history export is a row-per-fill log: ticker, side (yes/no), action (buy/sell), price, contract count, fees, and a timestamp. It is not a pre-summarized profit-and-loss statement — it's the raw fills, and it's up to you (or your software) to turn that into per-position and per-year P&L. Settlement rows, where a contract resolves and pays out $1.00 or $0.00, are typically separate from the entry fills, so a single trade you closed at resolution can span two or more rows in the export.
The ÷100 trap, explained
Kalshi's underlying data model prices everything in whole cents rather than decimal dollars — the same convention their API uses internally. A YES contract priced at 62¢ appears in the export as the integer 62. Multiply that directly by a contract count of, say, 50 and you get 3,100 — which looks like $3,100 but is actually $31.00. Fees follow the same convention: a fee column showing 7 means 7 cents, not $7.
The fix is mechanical: divide every price and fee column by 100 before you do any arithmetic. It sounds trivial written out like this, but it's easy to miss when you're pasting a CSV into a spreadsheet or feeding it into generic tax software that expects dollar-denominated inputs by default. Most crypto and stock brokers export in dollars, so this catches people who assume every trading CSV works the same way.
Turning fills into a real P&L ledger
Once every number is correctly in dollars, build your ledger by grouping fills by ticker:
- Cost basis — sum the dollar cost of every buy fill on that ticker (price × contracts, plus any entry fees).
- Proceeds — sum what you received: either the sale price on fills you closed manually, or $1.00 per contract on settlements that resolved YES (and $0 on settlements that resolved NO).
- Fees — sum separately so you can see fee drag on its own line, rather than burying it inside cost or proceeds.
- Net P&L — proceeds minus cost basis minus fees, per ticker, then summed for the tax year.
Kalshi issues a 1099-B to users with significant activity, which reports your proceeds and cost basis the way a stock broker would. Treat it as a check on your own ledger, not a replacement for it — you still need the underlying fills to reconcile arbitrage legs against Polymarket, and to catch any rows the 1099-B rounds or aggregates differently than you expect. Our full breakdown of how prediction market arbitrage is taxed covers the 1099-B, Section 1256 treatment, and short vs. long-term gains in detail — this article is specifically about getting the raw numbers right before any of that applies.
Reconciling arbitrage legs across Polymarket
If you're arbitraging, every trade has two legs: one on Kalshi, one on Polymarket, on the same underlying event. Reported separately, this looks worse than it is — a trade that resolved YES on Kalshi and NO on Polymarket will show a gain on one platform's export and a loss on the other, even though the combined position was a guaranteed, positive-edge trade by design.
To reconcile correctly: match each Kalshi fill to its paired Polymarket fill by event and date, then compute net P&L across both legs together — combined proceeds minus combined cost basis minus combined fees (Kalshi's fee on profit plus Polymarket's taker fee). That combined number is your real edge on the trade; either leg viewed alone is not a meaningful figure for tax purposes or for judging whether the strategy is working.
This is exactly the reconciliation problem Arbitrage Agent's dashboard export solves — every executed trade is logged with both legs already matched and the net edge calculated after both platforms' fees, so you're not manually pairing rows across two separate CSVs with two different price conventions. Join the waitlist to see it applied to your own trade history.
Common mistakes that distort your reported P&L
- Forgetting the ÷100 conversion — by far the most common error, and the one that produces numbers so obviously wrong (thousands of dollars on a small account) that it's usually caught, but not always before it's already in a spreadsheet you're trusting.
- Double-counting fees — Kalshi's fee is typically deducted at settlement, so if your proceeds figure already reflects the post-fee payout, subtracting the fee again understates your P&L.
- Treating each leg as an independent win or loss — for arbitrage specifically, this misrepresents what actually happened economically, even if it doesn't change your total tax liability once both legs are combined.
- Losing the settlement row — since entry fills and settlement payouts can appear as separate rows, filtering the export by date range without checking for settlements that landed just outside the window will understate proceeds.
What to hand your accountant
At minimum: your reconciled ledger (cost basis, proceeds, fees, and net P&L per position, already converted to dollars), Kalshi's 1099-B if you received one, and your Polymarket transaction history for the same period. If you're running arbitrage, note clearly which trades are paired legs so your accountant doesn't treat a designed, guaranteed-edge position as two unrelated speculative trades. None of this is tax advice — a professional familiar with prediction markets should confirm the specifics for your situation.