Settlement date not respected in tax calculations

Hi,

In EU, the settlement date of a stock market transaction is 2 business days after the trade is executed. If we sell a position on the last session in the year, the settlement date will fall in the next year – and the transaction should be included in the next year’s tax report. At least according to Polish law interpretations. The currency rate should be taken from the business day preceding the settlement date.

Tax reports In Capitally does not assign transactions to the correct tax year.
For data imported from IBKR, the transaction date is taken, not the settlement date, for Polish PIT-38 calculations.

Best,
Adam

Hmm, you’re right. I think I can add the settlement period option to tax presets, that would be used to:

  • assign transaction to a proper year
  • be the basis for currency exchange offset (eg. D-1)

One thing I haven’t think before is that dividends are settled at payout date, while stock has T+2/T+1. So that settlement would have to apply to Open/Close. What complicates it further, is that theoretically any fees are settled immediately, so they should use a different offset :cold_sweat:.

1 Like

What complicates it further, is that theoretically any fees are settled immediately, so they should use a different offset :cold_sweat:.

In tax calculators and interpretations I’ve seen this is not distinguished, i.e. fees use the same settlement date as the connected (stock/dividend) transaction. Should be good enough.

1 Like

Hi,

When I change the Offset in Taxable Income Report, it changes the Tax Paid, but not Tax Due. Not sure if this is another issue or connected with this somehow.

BTW could I have a possibility to set different offsets for dividends and sales? (as it needs to be different)

The Tax Due is controlled by the tax preset, which has it’s own offset which cannot be overridden by the report. That’s why only Tax Paid is changed. For any tax purposes, the Tax Due Report should be used.

Currently not, but I plan to add a separate “Ownership change settlement offset”, which would be +2 business days for Poland (& EU in general). This would be applied only to Buy/Sell transactions.

This way, you can better model the PL tax (and probably others as well):

  • Currency offset is always D-1
  • Buy/Sell has D+2 settlement & D-1 currency, so effectively D+1
  • Dividends, transfers and similar are settled at the transaction date, so their currency offset is D-1

For tax report I have to subtract Tax Paid from Tax Due in case of dividends (as PL has tax agreement with US to avoid double taxation) and pay only the difference.
In my case, both Tax Paid and Tax Due are in USD, but have to be converted to PLN. The conversion rate used depends on the offset for both Tax Paid and Tax Due, so I would expect both of those numbers to change (when they are shown in PLN) when I change the offset.

Great :slight_smile: I think T+2 is correct for European exchanges, but since 28th May 2024, US changed to T+1 (I know, it gets even more complicated):
Source

Correct, and you should use the Taxes Due report to check the number. You can even add Tax to pay column there which does the subtraction and uses proper offset.

Taxable Income gives an overview for the whole portfolio, so it may encompass multiple different tax presets.

Yep, the offset will be configurable per preset.

Hm, I am not sure I understood your point now… I think both Tax Paid and Tax Due should use the same Offset. Having them use different does not seem correct from tax law perspective and currently as I understand it - if I have multiple brokers with different presets, only Tax Due will respect that, but Tax Paid will use a single offset from Taxable Income Report page for all brokers, which does not seem correct for me. Or maybe I missed something?
When doing tax report I have always calculated my ‘Tax to pay’ value by subtracting already coverted to PLN values (which results in slightly different numbers than by subtracting USD values, due to rounding to nearest grosz, but that is the way I found it should be done), so Tax Paid offset will affect the calculation.

Your point exactly. When using Taxable Income Report to check for Tax to be paid you may get mixed offsets. This is a report which can be used if you want to calculate everything yourself or give it to an accountant.

When you use Tax Due report, the offset will always be the same. This report is optimized for working with tax presets.

Btw, when doing PL taxes, you report both numbers separately for dividends - Due & Paid. You make the subtraction on the form. Same goes for regular Revenue & Expense.

Oh, I now know what is the miscommunication.
I am not writing about Taxes Due Report at all, I am only talking about Taxable Income Report.
I am referring to ‘Tax Due’ column in Taxable Income Report.
So those two columns ‘Tax Due’ and ‘Tax Paid’ in Taxable Income Report are using different offsets, which does not seem correct.

Yes, that is correct. And I always convert for each transaction the USD/EUR/etc. values to PLN first, round value for each transaction to nearest grosz, and only after that I sum them all up and report totals (separately for due, paid, revenue and expense). I found that sometimes people sum/subtract foreign currency values instead of PLN, but tax office usually when asking for a report, requires each transaction to be converted to PLN values to nearest grosz separately and the reported totals (revenue etc.) should be equal to sum of those (rounded) PLN values.

So again, it’s not possible. Taxable Income Report can be used for taxes when you don’t use Tax Presets at all (so you don’t have Tax Due calculated).

Tax Presets have a much more detailed calculation model, and they cannot be changed in-flight.

Why don’t you use Taxes Due for this? It should give you all the numbers you’re looking for, no?

Interesting, currently the Tax Preset in C sums everything up as it is, but it’s actually pretty simple to modify it, so that it does the rounding.
Then, you’ll see all the numbers rounded per tax event (eg. transaction) and the sum will include it as well.

This is using a formula, but I think I’ll add precision option, to make it simpler.

BTW, the current Tax Due UI was done pretty hasty for the last tax season.

I’m more than open to discuss how it could be improved before April reigns down on us :slight_smile: So bring your ideas and proposals please - preferably in separate threads.

Hm, I just noticed that changing the Offset combobox changes only ‘Tax Paid’ column, but not the other (‘Tax due’). If you think it is not a bug, then I guess ok, I do not care so much, as I can use the other report, as you stated :slight_smile: (I assume dividends and transactions will use different offsets as you stated above).

Wow, I did not know it is configurable in so much detail, will look into that definitely. Thanks!