Same-Day and Bed & Breakfast Rules for Crypto — HMRC Matching Explained

The Bed and Breakfast rule sounds like it belongs in a period drama, but it'll absolutely affect your crypto tax bill. It's one of three HMRC matching rules that determine which acquisition gets paired with each disposal when you calculate capital gains — and if your tax tool ignores them, every number it produces is wrong.

These rules aren't optional. They aren't a "UK variation" you can toggle on. They are the law, codified in the Taxation of Chargeable Gains Act 1992 and extended to cryptoassets in HMRC's Cryptoassets Manual (CRYPTO22200). If your tax tool uses FIFO instead of these matching rules, your entire capital gains figure is wrong. Full stop.

The three rules are applied in strict priority order: same-day, then 30-day B&B, then Section 104 pool. Each one exists for a reason, and DeFi activity triggers them far more often than most people realise.

Rule 1: The same-day rule

If you acquire and dispose of the same token on the same calendar day, the acquisition is matched against the disposal before anything else. Not your Section 104 pool. Not a 30-day lookforward. The same-day match takes absolute priority.

The logic is straightforward: HMRC doesn't want you disposing of tokens in the morning to realise a loss, then rebuying the same tokens that afternoon and claiming the loss was real. Same day, same token — they're matched.

Worked example

You sell 2 ETH at £3,000 each on a Tuesday morning. Proceeds: £6,000. That afternoon, you buy 1 ETH at £2,900. Here's what happens:

• 1 ETH is matched against the same-day acquisition. Proceeds: £3,000. Cost basis: £2,900. Gain: £100.
• 1 ETH has no same-day match. It moves to the next rule — the 30-day B&B check. If nothing matches there either, it hits your Section 104 pool.

Notice the cost basis for that first ETH is £2,900 — the price you actually paid that afternoon. Not your pool average, which might be £1,800 from accumulating ETH over two years. The same-day rule overrides the pool entirely.

What counts as "the same day"?

This is where it gets subtle. HMRC uses the calendar day in the UK timezone, not UTC. During British Summer Time (late March to late October), the UK is UTC+1. A transaction at 00:30 UTC on April 7th is actually 01:30 BST on April 7th — same day. But a transaction at 23:15 UTC on April 6th is 00:15 BST on April 7th — that's the next day in London, even though it's still April 6th in UTC.

Get this wrong near midnight and you'll match the wrong transactions. We use Europe/London timezone for all day-boundary calculations because that's what HMRC expects.

Rule 2: The 30-day Bed and Breakfast rule

The name comes from an old stock-market trick: sell shares before the end of the tax year to crystallise a loss, "sleep on it" overnight, buy them back the next morning. The government closed that loophole decades ago by extending the matching window to 30 days. The same rule now applies to crypto.

After same-day matching, any remaining disposed tokens are checked against acquisitions in the next 30 calendar days. If you sell ETH today and buy ETH any time in the following 30 days, those acquisitions are matched against your disposal. The cost basis of the rebought tokens replaces whatever your Section 104 pool would have given you.

Worked example

On March 1, you sell 5 ETH at £2,000 each. Proceeds: £10,000. On March 15, you buy 3 ETH at £2,100 each. Cost: £6,300.

• No same-day match (different days).
• B&B match: 3 of the 5 ETH are matched against the March 15 acquisition. Proceeds: £6,000 (3 × £2,000). Cost: £6,300. Loss: £300.
• The remaining 2 ETH go against your Section 104 pool at whatever its average cost is.

The loss-harvesting trap

This is the scenario that catches people. You hold 10 ETH with a pool average cost of £2,500. ETH drops to £1,800. You sell all 10 to "harvest" a £7,000 loss (£25,000 cost minus £18,000 proceeds). Two weeks later, ETH is at £1,850 and you buy 10 back.

The B&B rule matches the rebuy against your disposal. Your cost basis becomes £1,850 per ETH (the rebuy price), not £2,500 (your old pool average). Instead of a £7,000 loss, you get a £500 gain on the matched portion. The loss you thought you were harvesting? Gone.

Rule 3: Section 104 pool (the fallback)

Anything not matched by the same-day or B&B rules goes against your Section 104 pool — a running weighted average of all your acquisitions of that token. We have a dedicated deep dive on Section 104, but the key point here is that it's the last resort, not the default. The other two rules carve out matched portions before the pool is ever consulted.

Why DeFi makes these rules much harder

If you're just buying and selling on Coinbase, the matching rules are tedious but manageable. DeFi is a different story.

Active DeFi users trip the B&B rule constantly. Selling ETH on Uniswap, then buying it back a week later on a different pool. Exiting an LP position (disposal of both tokens), then re-entering the next day. Swapping through an aggregator that routes ETH → USDC → ETH internally, creating a same-day acquisition and disposal you might not even realise happened.

Consider a simple Uniswap swap. You sell 1 ETH for 2,000 USDC. That afternoon, a different trade routes through an ETH pair and you end up acquiring 0.3 ETH as part of a multi-hop swap. Same-day rule kicks in: 0.3 ETH is matched against your morning sale at the afternoon's price, not your pool average. The remaining 0.7 ETH falls to B&B or S104.

The frequency is the problem. A traditional investor might trigger the B&B rule once or twice a year. An active DeFi user might trigger it dozens of times in a month. Every single match needs to be identified, applied in the correct order, and reflected in the gain calculation before the Section 104 pool is updated.

LP positions are especially tricky

Removing liquidity from a Uniswap V2 pool gives you back two tokens. That's two disposals (of your LP token) and two acquisitions (of the underlying tokens). If you added liquidity to a different pool that same day, the tokens going in are disposals and the LP token received is an acquisition. Same-day matching applies across all of these events, per token.

Try tracking that by hand across 500 transactions. It's not realistic.

How ChainTax applies the matching rules

We run these matching rules automatically in priority order, exactly as HMRC specifies. After classifying every transaction in your wallet, the engine runs a three-pass HMRC matching process:

1. Pass 1 — Same-day matching: all disposals are checked against acquisitions on the same London-timezone calendar day. Matched portions are removed from both sides.
2. Pass 2 — 30-day B&B matching: remaining unmatched disposals are checked against acquisitions in the next 30 calendar days. Matched portions are removed.
3. Pass 3 — Section 104 pool: everything left goes against the weighted average pool, which is built incrementally as each disposal is processed.

Every disposal in your tax report includes a "Show Working" breakdown that tells you exactly which matching rule was applied, the cost basis used, and the resulting gain or loss. No black boxes.

What most crypto tax tools get wrong

The majority of crypto tax software was built for the US market and retrofitted for the UK. That means FIFO by default, with HMRC matching bolted on as an afterthought — if it's there at all. Common failures:

• Using UTC for day boundaries. Misclassifies same-day matches during BST. A one-hour error window, but it affects real transactions near midnight.
• Skipping B&B matching entirely. Some tools apply Section 104 directly after same-day, treating the 30-day rule as optional. It isn't.
• Not recognising DeFi acquisitions. If a tool doesn't classify a Uniswap swap correctly, the "buy" side of the trade is invisible. No acquisition means no B&B match — losses slip through that HMRC wouldn't allow.
• Applying B&B backwards. The rule looks forward 30 days from the disposal, not backward. Some implementations check the wrong direction.

The result is a tax report that looks plausible but produces the wrong gain figure. Sometimes by hundreds of pounds, sometimes by thousands. For active DeFi users with frequent trades, the cumulative error compounds across every disposal in the tax year.

How this interacts with loss carry-forward

The matching rules determine your gain or loss on each disposal. Those individual results then feed into the loss carry-forward system, where net losses from previous years can offset current-year gains down to the annual exempt amount (£3,000 for 2024/25). But if the matching rules are wrong, your per-disposal gains and losses are wrong, which means your carried-forward losses are wrong, which means every future tax year is wrong too. The errors cascade.

Getting the matching rules right isn't just about this year's tax bill. It's about building a correct foundation that every future calculation depends on.

See the matching rules applied to your wallet

Want to see how these rules affect your actual transactions? You can classify any transaction for free using our public explainer, or scan your wallet to get a full HMRC-compliant breakdown with same-day, B&B, and Section 104 matching applied automatically. Every disposal shows its working — which rule matched, what cost basis was used, and exactly how the gain was calculated.