CAPRETURN equalisation payments incorrectly applied

Hello,

I believe you are applying equalisation payments incorrectly. No specific shares or past purchases attract equalisation. Equalisation payments are considered a one off capital return on the date they are paid, which has the result of lowering your acquisition costs. Put another way, a one off adjustment to the running total pool cost and pool unit cost.

From your example, it is not "01/04/2020: Dividend equalisation of £50 on 15 shares". Instead it is simply "01/04/2020: Equalisation of £50".

From your example:

01/08/2019: BUY 10 at £100 (10 pool units, £1000 pool cost, £100 pool unit cost) 01/09/2019: SELL 5 at £105 (5 pool units, £500 pool cost, £100 pool unit cost, £25 capital gain) 01/01/2020: BUY 10 at £90 (15 pool units, £1400 pool cost, £93.3333 pool unit cost) 01/04/2020: Dividend equalisation of £50 (15 pool units, £1350 pool cost, £90 pool unit cost) 01/04/2020: Dividend income of £30 on 15 shares

01/06/2020: BUY 10 at £80 (25 pool units, £2150 pool cost, £86 pool unit cost) 01/07/2020: SELL 5 at £100 (20 pool units, £1720 pool cost, £86 pool unit cost, £70 capital gain) 01/04/2021: Dividend equalisation of £10 (20 pool units, £1710 pool cost, £85.5 pool unit cost) 01/04/2021: Dividend income of £40 on 20 shares

This also allows simplification of the input from: CAPRETURN 01/04/2020 GB00B41YBW71 15.0 50.0

To: CAPRETURN 01/04/2020 GB00B41YBW71 50.0

Regards,

Dan Dodex

No specific shares or past purchases attract equalisation.

That's right. However I put the number of shares in the CAPRETURN as an error checking function effectively. It's a way that the calculator will ensure that you have that number of shares on the date the equalisation payment happens. It's not strictly needed though for the calculations that's true.

In terms of how the calculator works, it does go back through the acquisitions before the capital return event to assign a lowering in the acquisition cost for those shares. I do this so that it can calculate correctly in the case where you have same-day and B&B matches.

@mattjgalloway , first of all, thanks for writing this tool -- it's the only one I found that attempts to deal with equalisation payments. I appreciate you writing it and making it available.

However I put the number of shares in the CAPRETURN as an error checking function effectively. It's a way that the calculator will ensure that you have that number of shares on the date the equalisation payment happens.

Despite this explanation, I'm still having troubles wrapping my head around how CAPRETURN is meant to work.

I took interest on your calculator because I bought/sold Vanguard Sterling Short-Term Money Market Fund - Income on a GIA, and Vanguards applies equalisation payments on this fund.

Vanguard's Consolidated tax certificate shows the Date paid (end of each month), how many units were being held (not on the date paid, but the dividend date, ie, end of the previous month.)

Yet it seems cgtcalc is conflating the dividend date with the dividend payment date.

Let's consider this made up example:

BUY 02/01/2024  ISIN:GB00BGB6GZ57   10000   0.999900    0
SELL    01/02/2024  ISIN:GB00BGB6GZ57   10000   0.999800    0
CAPRETURN   29/02/2024  ISIN:GB00BGB6GZ57   10000   18.06

It is based from https://fund-docs.vanguard.com/UK_Investment_Money_Market_Fund_ICVC_Interim_Report_and_Financial_Statements.pdf

distribution

In a nutshell, one buys 10,000 units in early January, sells them all on early February, then receives late February the dividend for the units held end of January.

This is a perfectly valid scenario, but cgtcalc fails:

$ swift run cgtcalc mmf.-atxt 
Building for debugging...
[1/1] Write swift-version-6DD4792143108706.txt
Build complete! (0.08s)
[INFO] Begin processing
[INFO] Begin pre-processing transactions for ISIN:GB00BGB6GZ57.
[ERROR] Failed: InvalidData("Error pre-processing ISIN:GB00BGB6GZ57. Capital return amount 10000 doesn\'t match acquisitions 0.")

If one uses the dividend date, instead of dividend payment date like this:

BUY 02/01/2024  ISIN:GB00BGB6GZ57   10000   0.999900    0
SELL    01/02/2024  ISIN:GB00BGB6GZ57   10000   0.999800    0
CAPRETURN   31/01/2024  ISIN:GB00BGB6GZ57   10000   18.06

Then cgtcalc seems happier:

$ swift run cgtcalc mmf-b.txt 
Building for debugging...
[1/1] Write swift-version-6DD4792143108706.txt
Build complete! (0.09s)
[INFO] Begin processing
[INFO] Begin pre-processing transactions for ISIN:GB00BGB6GZ57.
[INFO] Finished pre-processing transactions for ISIN:GB00BGB6GZ57.
[INFO] Begin processing transactions for ISIN:GB00BGB6GZ57.
[INFO] Begin matching processor.
[INFO] Finished matching processor. Matched 0 and there are 1 disposals left.
[INFO] Finished processing transactions for ISIN:GB00BGB6GZ57. Created 1 tax events.
[INFO] Finished processing
# SUMMARY

Tax year    Gain   Proceeds   Exemption   Loss carry   Taxable gain   Tax (basic)   Tax (higher)
================================================================================================
2023/2024   £17    £9998      £6000       £0           £0             £0            £0          

# TAX YEAR DETAILS

## TAX YEAR 2023/2024

1 gains with total of 17.
0 losses with total of 0.

1) SOLD 10000 of ISIN:GB00BGB6GZ57 on 01/02/2024 for GAIN of £17
Matches with:
  - SECTION 104: 10000 at cost basis of £0.99809
Calculation: (10000 * 0.9998 - 0) - ( (10000 * 0.99809) ) = 17

# TRANSACTIONS

02/01/2024 BOUGHT 10000 of ISIN:GB00BGB6GZ57 at £0.9999 with £0 expenses
01/02/2024 SOLD 10000 of ISIN:GB00BGB6GZ57 at £0.9998 with £0 expenses

# ASSET EVENTS

31/01/2024 ISIN:GB00BGB6GZ57 CAPITAL RETURN on 10000 for £18.06

~~But the 17 doesn't matches expectations ... That is it should be a £19 gain.~~ Nevermind: I was mixing up the the aquisition/sales cost.

Furthermore, after reading https://www.gov.uk/hmrc-internal-manuals/capital-gains-manual/cg57705 I also understand that the dividend date (not payment date) that really matters, no matter what Vanguard's consolidated tax statements show. So it seems there's no solution but to manually adjust the equalisation dates to be one month before before feeding cgtcalc.

So I think I finally got it. Thanks again.

No specific shares or past purchases attract equalisation.

That's right. However I put the number of shares in the CAPRETURN as an error checking function effectively. It's a way that the calculator will ensure that you have that number of shares on the date the equalisation payment happens. It's not strictly needed though for the calculations that's true.

In terms of how the calculator works, it does go back through the acquisitions before the capital return event to assign a lowering in the acquisition cost for those shares. I do this so that it can calculate correctly in the case where you have same-day and B&B matches.

Hello,

First of all apologies, as I had not noticed you had kindly replied to my bug report back in April, until now. I still think there is a bug in the way equalisation payments are applied.

Let's go through your example step by step. Once I again I'll repeat my logic (highlighted my own calculation of the running tally for the pool):

01/08/2019: BUY 10 at £100 (10 pool units, £1000 pool cost, £100 pool unit cost) 01/09/2019: SELL 5 at £105 (5 pool units, £500 pool cost, £100 pool unit cost, £25 capital gain) 01/01/2020: BUY 10 at £90 (15 pool units, £1400 pool cost, £93.3333 pool unit cost) 01/04/2020: Dividend equalisation of £50 (15 pool units, £1350 pool cost, £90 pool unit cost) 01/04/2020: Dividend income of £30 on 15 shares

01/06/2020: BUY 10 at £80 (25 pool units, £2150 pool cost, £86 pool unit cost) 01/07/2020: SELL 5 at £100 (20 pool units, £1720 pool cost, £86 pool unit cost, £70 capital gain) 01/04/2021: Dividend equalisation of £10 (20 pool units, £1710 pool cost, £85.5 pool unit cost) 01/04/2021: Dividend income of £40 on 20 shares

Now this converts to this input to your software:

BUY 01/08/2019 GB00B41YBW71 10 100 0
SELL 01/09/2019 GB00B41YBW71 5 105 0
BUY 01/01/2020 GB00B41YBW71 10 90 0
CAPRETURN 01/04/2020 GB00B41YBW71 15 50
DIVIDEND 01/04/2020 GB00B41YBW71 15 30

BUY 01/06/2020 GB00B41YBW71 10 80 0
SELL 01/07/2020 GB00B41YBW71 5 100 0
CAPRETURN 01/04/2021 GB00B41YBW71 10 10
DIVIDEND 01/04/2021 GB00B41YBW71 20 40

Which turns into this output (simplified):

## TAX YEAR 2019/2020
1) SOLD 5 of GB00B41YBW71 on 01/09/2019 for GAIN of £28
Matches with:
  - SECTION 104: 10 at cost basis of £99.33333
Calculation: (5 * 105 - 0) - ( (5 * 99.33333) ) = 28

## TAX YEAR 2020/2021
1) SOLD 5 of GB00B41YBW71 on 01/07/2020 for GAIN of £57
Matches with:
  - SECTION 104: 25 at cost basis of £88.53333
Calculation: (5 * 100 - 0) - ( (5 * 88.53333) ) = 57

For tax year 2019/2020 the capital gain is £25, not £28, as it is generated by the sale on 01/09/2019, by which point no equalisation payment event has yet taken place. From my comment above: 01/09/2019: SELL 5 at £105 (5 pool units, £500 pool cost, £100 pool unit cost, £25 capital gain)

For tax year 2020/2021 the capital gain is £70, not £57. By the time of the sale on 01/07/2020 only one equalisation payment event has happened, on 01/04/2020, which has had the effect of lowering the cost of the pool from £1400 to £1350. From my comment above: 01/07/2020: SELL 5 at £100 (20 pool units, £1720 pool cost, £86 pool unit cost, £70 capital gain)

The equalisation payment on 01/04/2021 will only affect capital gain calculations for sales after this date, not for sales before. No specific shares or past purchases attract equalisation. Equalisation payments are considered a one off capital return on the date they are paid, which has the result of lowering your acquisition costs. Put another way, a one off adjustment to the running total pool cost and pool unit cost.

If you think there is a fault in my reasoning above please do let me know.

Thanks,

Dan Dodex

@dandodex wrote:

The equalisation payment on 01/04/2021 will only affect capital gain calculations for sales after this date, not for sales before. No specific shares or past purchases attract equalisation. Equalisation payments are considered a one off capital return on the date they are paid, which has the result of lowering your acquisition costs. Put another way, a one off adjustment to the running total pool cost and pool unit cost.

https://www.gov.uk/hmrc-internal-manuals/capital-gains-manual/cg57705 does state (my emphasis) "To compensate for this an equalisation payment is added to the cost of new units." which corroborates @dandodex 's interpretation.

This interpretation however means that the last equalisation payment can never be deducted from costs (as there are no subsequent new units to offset it against.) Ironically this means that the gains with @dandodex's interpretation will be lower than with @mattjgalloway's implementation, and therefore less CGT due.

@dandodex's interpretation is certainly much easier to implement, and also easier for the user to derive the CAPRETURN entries from statements like Vanguards' consolidated tax statement, as there's no need to workout the exact date the holdings were taken for dividend, and also no troubles is getting exact holdings (which is a problem with fractional shares and rounding.)

I suppose to be sure one will need to ask on https://community.hmrc.gov.uk/ , advisable especially because less CGT will be due.

@dandodex , one more thing looking at your example, IIUC, it's incorrect to have both DIVIDEND and CAPRETURN. My understanding is that DIVIDEND should only be used for Excess Reportable Income (ERI), normally of accumulation units (though some income units sometimes also report ERI.) According to https://www.kpmgreportingfunds.co.uk/ GB00B41YBW71 does not report ERI. Nevermind, ERI is for offshore funds. I suppose something similar happens for domestic funds like this one somehow.

https://www.gov.uk/hmrc-internal-manuals/capital-gains-manual/cg57705 also states that "It is a return of the initial price paid and it should therefore be deducted from the price paid when computing the chargeable gain on the eventual disposal" so it can also be argued to corroborate @mattjgalloway. Furthermore since @mattjgalloway yields higher CGT, it seems the "safest" interpretation...

@LateGenXer If you receive an equalisation payment, the value of the payment is deducted from your acquisition cost as it is treated as a part repayment of your original purchase. But the "refund" is applied only on the day it is paid, it does not change the past nor any transactions that have already happened. It really could not work any other way.

From your own link: CG57705 - Unit trusts: dividend equalisation payments It is a return of the initial price paid and it should therefore be deducted from the price paid when computing the chargeable gain on the eventual disposal.

Notice, that it is to be deducted from the price paid ONLY when computing the capital gain in a FUTURE disposal. It does not change capital gains from PAST disposals.

If you are not registered for self-assessment then you are expected to use the Real Time Capital Gains Tax service. Notice that you are expected to report capital gains as they happen in real time. Once declared it does not make sense that the capital gain reported would change months later when a equalisation payment happens (the amount of which would have been unknown to you when you first reported the capital gain).

Or put another way, it is a RETURN ON CAPITAL (as opposed to a dividend) that happens on the day it is paid. It is a capital return that will increase your capital gain whenever you dispose of more units in the future. But this return on capital only happens on the day it is paid, it does not retrospectively get applied to all previous purchases lowering their price at the time of purchase. It lowers the price of purchase of units on your pool on the day the equalisation payment is received.

Notice, that it is to be deducted from the price paid ONLY when computing the capital gain in a FUTURE disposal. It does not change capital gains from PAST disposals.

Yes, makes sense. Though to be correct I'd say PAST relative to ex-dividend date, not dividend payment date like you said, as payment can happen much further out in the future.

Perhaps a good way to frame this is that that equalisation payments should accrue to the units acquired from the previous ex-dividend date and still held on the current ex-dividend date (that is, not disposed.)

On the example above, the 01/04/2020 £50 equalisation payment would accrue to the 15 units held. For the 01/04/2021 £10 equalisation payment it's ambiguous: one could argue it accrues to 10 BUY units or to 10 BUY - 5 SELL = 5 units. In this particular case it doesn't matter which exact units it accrues, as the £10 equalisation it will simply be deducted from the Section 104's total cost.

I've just replicated the figures on my Vanguard's Consolidated tax certificate, using the Distribution Tables from the MMF Annual/Interim reports, and I now understand how Vanguard handles partial disposals like in the example mentioned.

Vanguard's assumes FIFO disposals, that is, on every dividend period where there are both acquisitions and disposals Vanguard will assume that the disposals were from units held before the dividend period (ie, Group 1 units, as opposed to Group 2 which attract equalisation, therefore not affecting equalisation), unless the number of units disposed exceeds the previously held, causing the excess disposals to be taken out from the Group 2 units acquired in the period, therefore reducing the equalisation payment.

According to https://github.com/mattjgalloway/cgtcalc?tab=readme-ov-file#unclear-rules-of-semi-disposals cgtcalc supposedly also assumes FIFO disposals, but then seems to do something weird:

So in the example above, the first dividend (both the equalisation and income) would be split 5/15 on the first buy, and 10/15 on the second buy.

It sounds like the 5/15 of the first buy is being accrued to the whole 10 units bought, instead of applying only the the 5 units outstanding.

Here's an even more pathological test case:

BUY 01/01/2010  FOO 10  100 0
SELL    01/02/2010  FOO 10  100 0
BUY 01/03/2010  FOO 10  100 0

DIVIDEND    01/01/2024  FOO 10  777

SELL    01/02/2024  FOO 10  100 0

cgtcalc ends up identifying the 2024's £777 dividend to the 2010/2011 tax year, even though it's many years before, which is unworkable:

# SUMMARY

Tax year    Gain    Proceeds   Exemption   Loss carry   Taxable gain   Tax (basic)   Tax (higher)
=================================================================================================
2009/2010   £-777   £1000      £10100      £777         £0             £0            £0          
2023/2024   £0      £1000      £6000       £777         £0             £0            £0          

# TAX YEAR DETAILS

## TAX YEAR 2009/2010

0 gains with total of 0.
1 losses with total of 777.

1) SOLD 10 of FOO on 01/02/2010 for LOSS of £777
Matches with:
  - BED & BREAKFAST: 10 bought on 01/03/2010 at £177.7 with offset of £777
Calculation: (10 * 100 - 0) - ( (10 * 177.7 + 0 + 777) ) = -777

## TAX YEAR 2023/2024

1 gains with total of 0.
0 losses with total of 0.

1) SOLD 10 of FOO on 01/02/2024 for GAIN of £0
Matches with:
  - SECTION 104: 10 at cost basis of £100
Calculation: (10 * 100 - 0) - ( (10 * 100) ) = 0

# TRANSACTIONS

01/01/2010 BOUGHT 10 of FOO at £100 with £0 expenses
01/02/2010 SOLD 10 of FOO at £100 with £0 expenses
01/03/2010 BOUGHT 10 of FOO at £100 with £0 expenses
01/02/2024 SOLD 10 of FOO at £100 with £0 expenses

# ASSET EVENTS

01/01/2024 FOO DIVIDEND on 10 for £777

I just noticed that this patch is necessary for cgtcalc to accept earlier years:

commit 4a67271b56d46b36c41158d99edc30c38d20b1d8 (HEAD -> main)
Author: LateGenXer <127238994+LateGenXer@users.noreply.github.com>
Date:   Sat Aug 10 14:39:12 2024 +0100

    https://www.rossmartin.co.uk/capital-gains-tax/110-capital-gains-tax-rates-a-allowances

diff --git a/Sources/CGTCalcCore/Tax/TaxYear.swift b/Sources/CGTCalcCore/Tax/TaxYear.swift
index 55e0143..40750e8 100644
--- a/Sources/CGTCalcCore/Tax/TaxYear.swift
+++ b/Sources/CGTCalcCore/Tax/TaxYear.swift
@@ -62,6 +62,11 @@ extension TaxYear {
   }

   static let rates: [TaxYear: Rates] = [
+    TaxYear(yearEnding: 2009): Rates(exemption: 9600, basicRate: 18, higherRate: 18),
+    TaxYear(yearEnding: 2010): Rates(exemption: 10100, basicRate: 18, higherRate: 18),
+    TaxYear(yearEnding: 2011): Rates(exemption: 10100, basicRate: 18, higherRate: 28),
+    TaxYear(yearEnding: 2012): Rates(exemption: 10600, basicRate: 18, higherRate: 28),
+    TaxYear(yearEnding: 2013): Rates(exemption: 10600, basicRate: 18, higherRate: 28),
     TaxYear(yearEnding: 2014): Rates(exemption: 10900, basicRate: 18, higherRate: 28),
     TaxYear(yearEnding: 2015): Rates(exemption: 11000, basicRate: 18, higherRate: 28),
     TaxYear(yearEnding: 2016): Rates(exemption: 11100, basicRate: 18, higherRate: 28),

I'm not familiar with Swift, and I couldn't understand how cgtcalc implements notional dividends / equalisation payments, so I ended up writing my own calculator as I felt that was the only way I'd ever understand this.

I then realized that trying to match notional dividends / equalisation payments to individual acquisitions is trying to fit a square peg in round hole: even if the dividends/equalisation follow a FIFO rule, trying to match them to shares identified to same-day or B&B acquisitions inevitably leads to time-travelling contradictions as the ones seen above.

The only thing that makes sense to ignore the FIFO and what shares are in Group 1 and Group 2, and simply update the Section 104 pool.

This is what https://www.quilter.com/siteassets/documents/platform/guides-and-brochures/20719-cgt-quick-reference-guide-1-section-104-holdings.pdf#page=3 describes. It's much easier to implement, and understand, and doesn't lead to time travelling effects.

FWIW, this is the output of my calculator for @dandodex's earlier example:

TAX YEAR 2019/2020

1. SOLD 5 GB00B41YBW71 on 01/09/2019 for GAIN of £25.00
Matches with:
- SECTION_104: 5 shares of 10 at average cost of 100.000000
Calculation: 525 - 500.00 = 25.00

19-20: Disposal Proceeds = £525.00 , Allowable Costs = £500.00 , Disposals = 1
19-20: Year Gains = £25.00  Year Losses = £0

TAX YEAR 2020/2021

1. SOLD 5 GB00B41YBW71 on 01/07/2020 for GAIN of £64.00
Matches with:
- SECTION_104: 5 shares of 25 at average cost of 87.200000
Calculation: 500 - 436.00 = 64.00

20-21: Disposal Proceeds = £500.00 , Allowable Costs = £436.00 , Disposals = 1
20-21: Year Gains = £64.00  Year Losses = £0

SECTION 104

GB00B41YBW71:
      Date     Trade   Shares  Amount Holding    Cost
2019-08-01       BUY 10 of 10 1000.00      10 1000.00
2019-09-01      SELL   5 of 5               5  500.00
2020-01-01       BUY 10 of 10  900.00      15 1400.00
2020-04-01  DIVIDEND            30.00      15 1430.00
2020-04-01 CAPRETURN            50.00      15 1380.00
2020-06-01       BUY 10 of 10  800.00      25 2180.00
2020-07-01      SELL   5 of 5              20 1744.00
2021-04-01  DIVIDEND            40.00      20 1784.00
2021-04-01 CAPRETURN            10.00      20 1774.00

And this is the output for my latter example:

TAX YEAR 2009/2010

1. SOLD 10 FOO on 01/02/2010 for GAIN of £0.00
Matches with:
- BED_AND_BREAKFAST: 01/03/2010 10 shares of 10 at average cost of 100.000000
Calculation: 1000 - 1000.00 = 0.00

09-10: Disposal Proceeds = £1000.00 , Allowable Costs = £1000.00 , Disposals = 1
09-10: Year Gains = £0.00  Year Losses = £0

TAX YEAR 2023/2024

1. SOLD 10 FOO on 01/02/2024 for LOSS of £777.00
Matches with:
- SECTION_104: 10 shares of 10 at average cost of 177.700000
Calculation: 1000 - 1777.00 = -777.00

23-24: Disposal Proceeds = £1000.00 , Allowable Costs = £1777.00 , Disposals = 1
23-24: Year Gains = £0  Year Losses = £777.00

SECTION 104

FOO:
      Date    Trade   Shares  Amount Holding    Cost
2010-01-01      BUY 10 of 10 1000.00      10 1000.00
2024-01-01 DIVIDEND           777.00      10 1777.00
2024-02-01     SELL 10 of 10               0    0.00

Sorry for the delay here in replying. I have been busy the past month or so, and haven’t had time to properly read through all this.

Thanks for digging in to it all!

One thing I would say in the most recent example is it’s a bit too contrived, and I would indicate that the calculator generally works for my situation (which is fairly standard so should work for many people too). I don’t use accumulation funds for my taxable accounts. So I don’t actually use dividends. I use capital return. But then that wouldn’t have the problem you say above because capital return dividends for anything I use always has one or more dividends a year, and so I always have one capital return entry each year for any new units I buy.

Your example that has the dividend 14 years later does look a bit wrong and I’ll have a proper look at the code there.

Right, the DIVIDEND example above is admittedly contrived to expose an extreme case, and indeed with CAPRETURN the issue can't be as far reaching in time, as CAPRETURN events regular, and shouldn't affect acquisitions before the previous CAPRETURN.

Still, even with CAPRETURN the previous tax year's gains might change middle of the next tax year. Here's a more realistic example highlighting this problem:

BUY 02/01/2024  FOO 10  100 0
SELL    01/02/2024  FOO 5   100 0
BUY 01/03/2024  FOO 5   100 0

CAPRETURN   01/06/2024  FOO 10  1554

SELL    01/07/2024  FOO 10  100 0

Again cgtcalc will split the CAPRETURN between tax years 2023/2024 and 2024/2025, instead of just the latter, making it impossible to file SA early , or forcing one to do a correction later 2024 if one file SA before receiving the dividend in June:

Tax year    Gain   Proceeds   Exemption   Loss carry   Taxable gain   Tax (basic)   Tax (higher)
================================================================================================
2023/2024   £777   £500       £6000       £0           £0             £0            £0          
2024/2025   £777   £1000      £3000       £0           £0             £0            £0

Obviously one can't calculate the a tax years CGT before the B&B rule's 30 days pass (as B&B rule has retrospective effects by design), but having to wait the whole next tax year data for computing the gains of the previous tax year is inconvenient at best. Especially because it might not be easy to know all CAPRETURNs until receiving consolidated tax certificates in the middle of 2025.

Assigning DIVIDEND's notional income and CAPRETURN's equalisation payments to the Section 104 pool avoids all that.

That said, changing how cgtcalc does this is not without issues for existing users, as it will retrospectively change old calculations. But there are ways to deal with it:

cgtcalc could change the calculations for tax years going forward, keeping the old way for older tax years
or users could start new, replacing the old trades with an artificial transaction to buy the Section 104 pool

IMO option 1 looks very complicated and error prone. An one-off clean break like 2 is probably better.

mattjgalloway / cgtcalc

CAPRETURN equalisation payments incorrectly applied #15