Crypto.com cashback reversals

[Roadrunneruk]

Crypto.com does card cashback which means that every time you use there crypto card they give you back cro coins which the parser categorises to Gift-Received in TYPE Column which is correct, but if say you take an item you bought on your crypto card back to get a refund, crypto.com does a card cash reversal which Bittytax categorises as TYPE Gift-Sent when creating the xlse file.
The problem is when Bittytax is run to create the pdf you now have a number of disposals some could be quite high, my question is it possible to have an ignore drop down in the xlse TYPE Heading so when calculating Bittytax ignores this. This way you still keep the information in the excel file, or do HMRC treat these as disposals?

Thanks Andy

[nanonano]

Hi Andy, can you give an example showing the credit card purchase, the cash back and the refund?
Does the cash back get removed also?

If I'm understanding correctly, you could remove the transaction record data (columns A to M), keep the raw data so your records are complete, for both the credit card purchase, and the refund. I'm assuming they match, and you get to keep the CRO? So it should all balance okay.

[Roadrunneruk]

Example
when you make a purchase and the transaction fails for what ever reason, Toolstation store does not like crypto cards and fails when authorising your card, but crypto.com see the failed transaction and does not take money off card but for some strange reason gives you CRO coins as cash back as if the transaction went ahead, Then several days later you get the card cashback Reversal.
When you purchase an item then take it back to the shop for a refund the transaction I presume crypto.com removes the transaction as I can't find any record of the traction, only the card cashback and card cashback reversal .

example.csv

[nanonano]

Ok I understand now, it's just the cashback reversal.

So for the moment you would have to remove the transaction record for the Card Cashback and it's matching Card Cashback Reversal.

It's a shame there's no transaction ID to pair these 2 together so they could automatically be removed.

I'll change this to a future enhancement, to find a simple way to flag transactions to be ignored.