How to Journal Crypto Trades (the Right Way)

Most traders know they should keep a journal. Almost none do it properly. The gap between a useful journal and an abandoned spreadsheet comes down to how you set it up in the first place, and whether the setup can actually survive contact with real crypto markets.

Why most crypto trade journals fail

A spreadsheet works fine for equities. You buy 100 shares, you sell 100 shares, you record the difference. Crypto breaks this model in at least four distinct ways.

Partial fills. A limit order for 0.5 BTC might fill across six separate executions at different prices. A spreadsheet row that shows "entry: $68,400" is almost certainly wrong. The real entry is the VWAP across all those fills. Most traders either use the first fill price, or give up and log only approximate entries.

Funding payments. On perpetual futures, you receive or pay funding every eight hours. On a trade held for three days that funding can add up to a meaningful fraction of your PnL. If you don't attribute it to the trade, your win rate looks cleaner than it is. Your losers also look worse when funding happened to pay you during them.

Inverse contracts. On Binance USD-margined contracts, PnL is in USDT. On coin-margined inverse contracts, PnL is denominated in the base currency: BTC on BTCUSD. A $500 profit on a BTC inverse contract at $60,000 is 0.00833 BTC, not $500. Mixing these in the same P&L column is a silent data corruption problem.

Fee currencies. Bybit charges fees in the quote or settlement currency of the contract you trade. Some exchanges offer BNB/platform-token discounts. If you record the face-value fee instead of the actual settled currency equivalent, your fee column is garbage.

These aren't edge cases. They're the normal mechanics of serious crypto trading. Any journal system that doesn't handle them by design will drift further from reality with every trade you log.

What to record on every trade

A complete trade record has two categories: the mechanical facts and the qualitative context. Both matter.

Mechanical facts:

• Entry VWAP: the volume-weighted average price across all entry executions, not the first fill
• Exit VWAP: same logic on the way out
• Size: in base currency (BTC, ETH, SOL) and in quote currency at entry VWAP
• Fees: in the currency actually settled, converted to quote currency at execution time
• Funding received/paid: per funding interval, summed and attributed to the trade
• Net PnL: entry VWAP to exit VWAP, minus fees, plus/minus funding
• Duration: open timestamp to close timestamp

Qualitative context:

• Setup / playbook name: which of your defined trade types is this? "Breakout retest," "range fade," etc.
• Planned risk: where was your stop loss at entry? This is what makes R-multiple calculation possible later.
• Mistakes made: moved the stop, sized too large, took early profit, held through a signal violation
• Screenshots: the chart at entry and exit, annotated. This is what you'll actually review

Round-trip reconciliation. Multiple executions that are part of the same directional position belong in a single trade record. If you partially filled long, added to the position, then closed in two pieces, that's one trade. Record it as one trade with VWAP entry, VWAP exit, and cumulative fees. Tools that auto-import from exchange APIs handle this with round-trip matching. They group by instrument and net position changes rather than treating each execution as a separate row.

The metrics that actually change behavior

Raw PnL is the most available metric and the least useful. It conflates trade quality with position size. A $2,000 winner on a 2 BTC position with a $1,000 stop is worse risk-adjusted performance than an $800 winner on a 0.4 BTC position with a $400 stop.

R-multiples normalize for risk. If you risked $400 (1R) on a trade and made $1,200, that's a 3R winner regardless of absolute dollars. Tracking R-multiples makes your performance data comparable across different market conditions, different position sizes, and different instruments. A journal without R-multiple tracking is measuring effort, not skill. Learn more in our deeper post on R-multiples explained.

Win rate by setup. Your breakout trades might win 60% of the time. Your mean-reversion counter-trend trades might win 25% but average 4R when they work. If you're not tagging trades by playbook, you can't see this split. You're probably doing the wrong trades in the wrong conditions without knowing it.

Mistake cost. This one changes behavior faster than anything else. When your journal shows "moved stop: -$340 this month," or "overtraded after a loss: -$890 in revenge trades," the dollar number makes it concrete. Behavioral problems that feel like vague discipline issues become quantified liabilities.

Time-of-day performance. Many traders consistently lose during certain sessions: early New York when liquidity is thin, or overnight when they're tired and trigger-happy. Slicing PnL by hour of day takes about 20 data points to show a signal. Most traders never look at it because their journal can't generate it.

Handling crypto-specific accounting

Funding on perpetuals. Every eight hours (or one hour on some venues), funding is either charged to or credited from your margin balance. The correct treatment is to attribute these payments to the trade that was open at the time. If you hold a long BTC-PERP for 48 hours across six funding intervals, those six payments are part of the trade's economics. A journal that only captures entry and exit price is ignoring 5 to 15% of real PnL variation on multi-day carries.

Inverse contracts. On coin-margined inverse contracts, one contract is worth a fixed USD amount (typically $1 or $100), and you're long or short in contracts but your margin and PnL settle in the base currency. BTC PnL = contracts × contract value × (1/entry_price − 1/exit_price). That formula is correct; naively subtracting entry from exit in dollar terms is wrong. If your journal doesn't know whether a position is linear or inverse, every inverse PnL calculation is incorrect.

Platform token fee discounts. Paying fees in BNB on Binance gives roughly a 25% discount. This means your effective fee rate is lower, but you're spending an appreciating (or depreciating) asset to pay it. The correct record is the USDT equivalent of the BNB actually spent at the execution price. Logging the nominal fee tier without accounting for the discount overstates your costs. And if BNB has appreciated, you're also missing a cost-basis event.

Cross-pair settlement. Some positions net against each other. A spot BTC purchase that settles a short BTC-PERP creates what looks like an orphaned exit on one side. This cross-pair inventory problem is a known gap in many journal importers: if you opened a hedge position on a different instrument or account than the original trade, the importer may see an unmatched sell. Manual reconciliation or a system that tracks full portfolio inventory is the solution.

Manual vs automated journaling

The core problem with manual journaling isn't discipline. It's latency and cognitive load. After a volatile trading session (multiple fills, a couple of stop-outs, one partial close where you took 50% off), reconstructing accurate VWAPs and fee totals from memory two hours later is hard. Reconstructing them accurately three days later is almost impossible.

More importantly, manual journals select for what you remember. You're more likely to record the 3R winner in detail than to carefully document the messy revenge trade that followed a stop-out. The journal becomes a highlights reel, which means your review is based on a biased sample.

Automated import via read-only API keys solves both problems. The journal sees every execution as it happens, calculates VWAP and fees from raw trade data, and matches funding payments to open positions automatically. Read-only API keys cannot withdraw funds or place orders. You grant the importer access to trade history only. Viktury supports auto-sync for Binance, Deribit, Hyperliquid (via wallet address), and Coinbase, with CSV import as a fallback for venues that don't support API history access.

CSV import with duplicate detection is the minimum viable fallback. If you're using Bybit, their trade history CSV exports include all fills with timestamps, fees, and position direction, so a properly built importer can reconstruct round trips from that data without manual entry.

Turning the journal into an edge

A journal only produces edge if you actually review it. The review needs structure.

Weekly review ritual. Every Sunday (or whatever day you're not trading), open the journal and run three queries: which setup had the highest R expectancy this week, which trade was the biggest mistake in dollar terms, and what's the average mistake cost per trade over the last 30 days. These three numbers take five minutes to check. They tell you whether you're improving.

Playbook grading. Grade each setup A, B, or C at entry based on how cleanly it matches your rules. A-grade setups have all conditions met. B-grade setups have most conditions met with one compromise. C-grade setups are chased entries or setups taken out of boredom. After 50 trades per playbook, compare average R-multiple by grade. If your B and C trades are negative expectancy while A trades are positive, you know exactly what to cut.

Cut the worst setup. Once a quarter, identify the setup with the lowest average R-multiple across at least ten occurrences. Stop trading it entirely for one quarter. This is the clearest, most evidence-based way to improve your trading: not adding complexity, but removing what demonstrably doesn't work.

The difference between a trader with an edge and one without is rarely talent. It's usually who has systematically reviewed 500 trades and made specific rule changes based on what the data showed. That review only happens if you have clean, complete data to review.

Start your free trial at Viktury and connect your exchange accounts in about five minutes. For a list of all supported exchanges and their import methods, see the exchanges directory.