A Bitcoin execution report is the document a liquidity provider gives you after a trade, showing exactly what was done on your behalf. A good one records the timeline of the order, the quantity and average price achieved, every cost, the result against a benchmark agreed in advance, and the settlement details. Without it, a finance team cannot show its board or auditors that the trade was well executed.
Why the report matters
A trade confirmation proves that a trade happened. An execution report explains how it happened. The difference matters for three audiences:
- The treasury team, which needs to judge whether the provider performed well.
- The board, which approved the policy and wants evidence that it is being followed.
- The auditors, who will test the existence, valuation and cost of the asset and the controls around its purchase.
For listed companies, the report also supports the numbers that end up in disclosures. For private companies, it is often the best single source document for the trade file. See internal controls over Bitcoin for how it fits into the wider control framework.
The core sections
An execution report should be structured, consistent across trades and machine-readable where possible. The sections below form a sensible minimum.
1. Order details
What the company asked for: side (buy or sell), quantity or notional amount, order type, any limit price, the execution style (single quote, worked order, block trade) and who placed the order.
2. Timeline
Timestamps, to the second and in a stated time zone, for each key event: order received, quote provided, quote accepted, execution start, execution end, and each settlement step.
3. Execution result
Quantity filled, average execution price, number of fills, and the venues or liquidity sources used where the provider acts as agent. If the order was only partly filled, the report should say so and explain why.
4. Costs
Every cost, separately stated: spread or mark-up embedded in the price, explicit commission, settlement or withdrawal fees and on-chain network fees. Costs hidden inside the price should still be estimated against the mid-price at the time.
5. Benchmark comparison
The benchmark agreed before the trade (arrival price, TWAP, VWAP or the competing quotes received) and the difference in basis points. A positive or negative number on its own means little; the report should state which direction is favourable to the company.
6. Settlement record
Bank payment reference, value date, Bitcoin transaction ID, receiving address, block height and confirmation count. This links the trade to both the bank statement and the blockchain.
A sample Bitcoin execution report layout
The layout below is illustrative. Prices are expressed relative to the arrival mid-price so the example does not depend on any market level; your provider's report will show actual prices.
| Field | Illustrative entry |
|---|---|
| Report reference | EXR-0001 |
| Client entity | [Company legal name] |
| Provider entity | [Contracting entity name] |
| Side / instrument | Buy / BTC against USD |
| Order quantity | 100.00000000 BTC |
| Execution style | Worked order, TWAP over 4 hours |
| Order received | 09:00:00 UTC |
| Execution start / end | 09:05:12 UTC / 13:04:48 UTC |
| Quantity filled | 100.00000000 BTC (100%) |
| Number of fills | 48 |
| Arrival mid-price | Reference = 100.00 |
| Average execution price | 100.06 (6 bps above arrival) |
| Benchmark: interval TWAP | 100.04 |
| Result vs benchmark | 2 bps above TWAP (unfavourable) |
| Explicit commission | [Amount and bps] |
| Network fee | [Amount, paid by provider or client] |
| All-in cost vs arrival | [bps, including commission] |
| Cash leg | [Amount], value date [date], bank ref [reference] |
| Bitcoin leg | TXID [hash], to [whitelisted address], block [height] |
| Confirmations at report time | [Number] |
| Exceptions | None |
A report for a single firm quote via RFQ will be shorter. It should still show the quote time, the accepted price, the competing quotes received and the settlement record.
CFO tip: before signing with any provider, ask for a redacted sample execution report from a real trade. If the sample cannot show timestamps, a benchmark and an on-chain settlement record, the live reports will not either.
Reading the report critically
A report is only useful if someone reads it with questions in mind.
- Was the benchmark set before the trade? A benchmark chosen afterwards can make any result look good.
- Do the timestamps make sense? A long gap between order received and execution start needs an explanation.
- Do the costs add up? The all-in cost should reconcile to the cash paid and the Bitcoin received.
- Does the settlement record match? Check the transaction ID on a block explorer or through the custodian, and confirm the receiving address is on the whitelist.
- Are exceptions disclosed? Partial fills, delays and re-quotes should be stated, not left for you to discover.
Over several trades, aggregate the results. A single trade can be unlucky. A pattern of results consistently on the wrong side of the benchmark is information. Measuring that pattern is the basis of best execution and of slippage analysis.
Storing and using reports
Keep each report with the trade confirmation, the approval record and the reconciliation in a single trade file. Retain it for the period your record-keeping policy and local law require.
Use the aggregated data in periodic reporting to the board. Average cost against benchmark, settlement performance and exceptions by provider are natural inputs to Bitcoin treasury reporting KPIs. Companies should take their own accounting advice on which costs are capitalised and which are expensed.
How The Bitcoin World helps
We agree the execution report format and benchmark with providers before any trade, review each report when it arrives, and summarise execution quality across trades for the finance team and board. Execution, custody and settlement are carried out by licensed third-party institutions. See our OTC liquidity and board advisory services.