Average cost basis for capital gains

[Alice Ryhl]

Hi!

I live in Denmark, and under danish law, we must compute capital gains for a
given stock using the average cost basis. To avoid accumulating rounding errors,
this is done by keeping track of the total purchase price rather than the price
per share. When we sell, the gain or loss is computed and rounded to two digits,
and the gain/loss of the year is the sum of those rounded values.

If I have shares of the same commodity in different banks, the cost basis must
be considered together. But shares that I own are not counted together with
shares owned by my husband. So for each commodity, I actually need two "global"
counters: the total purchase price of the commodity for each person.

My current plan is to have an account called "Assets:CostBasis:Alice:IUSA" that
keeps track of the total purchase price for the commodity IUSA for Alice. Then
adjust it up or down each time I buy something. I can book the other end of the
transaction to the "Assets:CostBasis" account so that everything sums to zero
and doesn't affect the net worth.

Danish law also mandates taxation of unrealized gains on some assets. I'm
thinking that I can do this by having a transaction at the end of year that
increases the purchase price to the current market value.

Thoughts? Is there a better way to do this?

Alice

[Martin Blais]

On Sat, Jan 4, 2025 at 9:05 PM Alice Ryhl <al...@ryhl.io> wrote:

Hi!

I live in Denmark, and under danish law, we must compute capital gains for a
given stock using the average cost basis. To avoid accumulating rounding errors,
this is done by keeping track of the total purchase price rather than the price
per share. When we sell, the gain or loss is computed and rounded to two digits,
and the gain/loss of the year is the sum of those rounded values.

Interesting. They specifically state that? 

 

If I have shares of the same commodity in different banks, the cost basis must
be considered together. But shares that I own are not counted together with
shares owned by my husband. So for each commodity, I actually need two "global"
counters: the total purchase price of the commodity for each person.

My current plan is to have an account called "Assets:CostBasis:Alice:IUSA" that
keeps track of the total purchase price for the commodity IUSA for Alice. Then
adjust it up or down each time I buy something. I can book the other end of the
transaction to the "Assets:CostBasis" account so that everything sums to zero
and doesn't affect the net worth.

I would just write a script that knows about your linked accounts for the same commodity and that computes the average cost basis across them.

Then when you close positions, use that cost basis (entering it manually).

 

Danish law also mandates taxation of unrealized gains on some assets. I'm
thinking that I can do this by having a transaction at the end of year that
increases the purchase price to the current market value.

That seems right. 

MTM like our Section 1256 in the US (e.g., holding a futures position across the new year).

Thoughts? Is there a better way to do this?

Alice

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/bf6c8b26-e891-4296-a49c-de4bb38b37b9n%40googlegroups.com.

[Alice Ryhl]

On 1/5/25 12:06 AM, Martin Blais wrote:

On Sat, Jan 4, 2025 at 9:05 PM Alice Ryhl <al...@ryhl.io> wrote:

Hi!

I live in Denmark, and under danish law, we must compute capital gains for a
given stock using the average cost basis. To avoid accumulating rounding errors,
this is done by keeping track of the total purchase price rather than the price
per share. When we sell, the gain or loss is computed and rounded to two digits,
and the gain/loss of the year is the sum of those rounded values.

Interesting. They specifically state that?

Yeah, the law specifically states that average cost basis must be used for stocks, funds, ETFs and such. That said there are some exceptions, e.g. for crypto currencies you must use the FIFO method instead.

If I have shares of the same commodity in different banks, the cost basis must
be considered together. But shares that I own are not counted together with
shares owned by my husband. So for each commodity, I actually need two "global"
counters: the total purchase price of the commodity for each person.

My current plan is to have an account called "Assets:CostBasis:Alice:IUSA" that
keeps track of the total purchase price for the commodity IUSA for Alice. Then
adjust it up or down each time I buy something. I can book the other end of the
transaction to the "Assets:CostBasis" account so that everything sums to zero
and doesn't affect the net worth.

I would just write a script that knows about your linked accounts for the same commodity and that computes the average cost basis across them.

Then when you close positions, use that cost basis (entering it manually).

It seems tricky to do just based on the information in the transaction. I might buy something using USD, or I might sell something and receive USD. But it's the equivalent value in DKK that matters. Sometimes, the DKK value of a certain transaction is reported to the tax authorities by someone else, and in that case I need to use whatever DKK value they're using for it to add up.

I guess one option is to add meta attributes that specify the price for a transaction in DKK, and also let sales have a meta attribute containing the gain/loss, and have the plugin emit an error if the gain/loss is incorrect.

[Eric Altendorf]

/sub since I have vaguely related open questions around tracking cost basis of assets that are transferred between accounts -- in the US it seems unclear whether the determination of which lots are transferred needs to be done at transfer time or can be retroactively defined when closing the position.

On Sun, Jan 5, 2025 at 4:26 AM Alice Ryhl <al...@ryhl.io> wrote:

On 1/5/25 12:06 AM, Martin Blais wrote:

On Sat, Jan 4, 2025 at 9:05 PM Alice Ryhl <al...@ryhl.io> wrote:

Hi!

I live in Denmark, and under danish law, we must compute capital gains for a
given stock using the average cost basis. To avoid accumulating rounding errors,
this is done by keeping track of the total purchase price rather than the price
per share. When we sell, the gain or loss is computed and rounded to two digits,
and the gain/loss of the year is the sum of those rounded values.

Interesting. They specifically state that?

Yeah, the law specifically states that average cost basis must be used for stocks, funds, ETFs and such. That said there are some exceptions, e.g. for crypto currencies you must use the FIFO method instead.

I *think* the question was whether they specifically state that you must use the method you described, say, versus some other method that computes equivalent results.

The method you describe sounds amenable to manual ledgers.  When you're tracking assets with computers it's a lot easier to use arbitrary-precision math to avoid accumulating rounding errors.

If I have shares of the same commodity in different banks, the cost basis must
be considered together. But shares that I own are not counted together with
shares owned by my husband. So for each commodity, I actually need two "global"
counters: the total purchase price of the commodity for each person.

My current plan is to have an account called "Assets:CostBasis:Alice:IUSA" that
keeps track of the total purchase price for the commodity IUSA for Alice. Then
adjust it up or down each time I buy something. I can book the other end of the
transaction to the "Assets:CostBasis" account so that everything sums to zero
and doesn't affect the net worth.

I would just write a script that knows about your linked accounts for the same commodity and that computes the average cost basis across them.

Then when you close positions, use that cost basis (entering it manually).

It seems tricky to do just based on the information in the transaction. I might buy something using USD, or I might sell something and receive USD. But it's the equivalent value in DKK that matters. Sometimes, the DKK value of a certain transaction is reported to the tax authorities by someone else, and in that case I need to use whatever DKK value they're using for it to add up.

I guess one option is to add meta attributes that specify the price for a transaction in DKK, and also let sales have a meta attribute containing the gain/loss, and have the plugin emit an error if the gain/loss is incorrect.

 

Danish law also mandates taxation of unrealized gains on some assets. I'm
thinking that I can do this by having a transaction at the end of year that
increases the purchase price to the current market value.

That seems right. 

MTM like our Section 1256 in the US (e.g., holding a futures position across the new year).

Thoughts? Is there a better way to do this?

Alice

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/beancount/292de0d1-0e97-4b82-beff-b7ac4b88fa92%40ryhl.io.