bittytax / bittytax Goto Github PK

I have some trades in my Coinbase account which have a zero fee, and they are being mis-classified as Gifts received:

Buy | BTC | 0.06260391 | 7986.72 | 500 | 500 | 0 | Bought 0.06260391 BTC for £500.00 GBP

This was a legitimate trade, and as it's being classified as a Gift-Received, it is not decreasing the GBP account balance correctly. I'm not entirely sure how this can be resolved properly; I also have another transaction in my account:

'Buy | BSV | 0.00586463 | 50.72 | 0.3 | 0.3 | 0 | Bought 0.00586463 BSV for £0.30 GBP'

This is labelled in the GUI as "BSV Fork Balance Credit", and was not a proper trade. There is nothing I can see in the transaction log which would be able to resolve these two correctly.

Currently there are issues with TGBP prices as they are highly inaccurate (BT computes it from the the BTC price). The quickest fix I see is to automatically add a GBP value for buy/sell/fee equal to the TGBP amount.

Another "fix" (which is actually used by Accointing.com) is to simply replace TGBP with GBP -- this is fundamentally wrong as one is a crypto asset and the other is not, but the tax computation will be the same. I wouldn't do this though, I haven't given it any thought to see if there are any catch-out aspects.

It would appear that it doesn't take into account the Quantity Remaining column, meaning that if you have partially-filled orders things won't balance correctly (you'll quickly end up with negative balances). The buy or sell quantity in BittyTax should be Quantity minus Quantity Remaining from the Bittrex csv output.

bittytax calculation throws an error if "fee asset" is not the same as the buy or the sell asset but instead, a third asset type

For example often on Binance, fees are denominated in BNB and BNB is not the buy or the sell asset of a transaction then it throws error "Fee asset does not match"

This causes the program never to complete the calculation. There is some sort of buffer overrun because every row has this error in quick succession and it falls over.

One way I've fixed this (at least to complete the calculation) is by removing the exception trigger in import_records.py and of course it then runs just is as if it ignores the fees.

The elseif statement in record.py needs a third option to deal with this third fee type scenario, working out the price of the fee currency in an amount of the other assets, and adjusting buy or sell amount accordingly. I'm not sure it's the right treatment of fees anyway - the way you've chosen to do it adding and subbing in transaction. But without researching it more I'm not sure.

The exception below is raised when using the bittytax to process your transaction records if the excel file is in .xlsx format.

...
xlrd.biffh.XLRDError: Excel xlsx file; not supported

During handling of the above exception, another exception occurred:

...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb3 in position 14: invalid start byte

Currently original rows are included in the main sheet, starting with the 14th column. This is problematic and not future proof, since it kills backwards compatibility.

For example, you added a "Note" column recently at the end of the data, which killed all my previously converted files, some which had manual edits too :(, so now more manual work is needed. In the future we may want to add more column at the end with various functionality.

I suggest original rows to be included in a new sheet with a specific name or prefix, e.g. IGNORE-<blah> for the main tool to ignore altogether, instead of ignoring data after a specific column number (that is not safe future-proof wise). This also allows the user to add other sheets they want the tool to ignore for tax calculations, but want to keep for their own reference.

Hi nanonano,
I know the current version of the software does not deal specifically with futures but just wanted to double check with you to make sure my understanding is correct.

Due to foreign exchange effect, CGT calculations might be inaccurate if the transaction records file includes futures.

Example:

• day 1 : Buy 1 ETH-USD future at 400.00 and GBP-USD exchange rate is 1.30
• day 2 : Sell 1 ETH-USD future at 400.00 and GBP-USD exchange rate has moved to 1.28

With current code Capital Gains =GBP 3.75601
calculation -> [(400 / 1.28 - 400/1.30) / 1.28 ]

Capital Gains should be = GBP 0
calculation -> (400-400)/1.28 = 0

thx
Vi

The current Trezor export files have change the date format to be DD/MM/YYYY.

Previously it was in YYYY-MM-DD format.

Always check ambiguous dates have been parsed correctly when using bittytax_conv.

Hey Scott!

Happy new year :) I had wanted to run a 'delta' run of transactions to see whether there'd be any new surprises of unparsed data - and found an instance! It's likely an easy one...

Transaction description: "Supercharger Deposit (via app)" and "Supercharger Withdrawal (via app)". Currency is always in CRO.

Error looks like:

row[117] ['2020-12-30T13:36:08 ', 'Supercharger Withdrawal (via app)', 'CRO', '20008.45', '', '', 'GBP', '849.93', '1154.0774505', 'supercharger_withdrawal'] ERROR Unrecognised Transaction Kind: 'supercharger_withdrawal'

row[130] ['2020-12-28T07:50:26 ', 'Supercharger Deposit (via app)', 'CRO', '-635.5', '', '', 'GBP', '-26.91', '-36.5397435', 'supercharger_deposit'] ERROR Unrecognised Transaction Kind: 'supercharger_deposit'

It's more aesthetic an issue - these transactions should ultimately be ignored in the same way a "Crypto Earn Deposit" is ignored - all it's doing is moving CRO from one internal 'area' (not even wallet really) to another - to earn interest in another currency.

Not so much a 'bug' - as it just ignores these transactions, but if you do want to tidy up there's no harm for a quick win!

Thanks!

Coinbase doesn't show the fiat currency deposits in transactions when crypto is bought using card/ bank transfer. (Coinbase pro seems to be showing this well)

This is the issue with Coinbase, but I wonder if there can be a workaround here to deal with the problem.

However, the notes column in the transaction shows the amount used to buy the crypto and this can be used to make the assumption that the deposit has taken place.

Transaction example (Coinbase):
Trade | 0.01327044 | BTC | | 38.01 | GBP | | 1.99 | GBP | | Coinbase | 2019-01-15 20:14:09 | 2019-01-15T20:14:09Z | Buy | BTC | 0.01327044 | 2864.26 | 38.01 | 40.00 | 1.99 | Bought 0.01327044 BTC for £40.00 GBP

Traceback (most recent call last):
File "/usr/bin/bittytax_conv", line 8, in
sys.exit(main())
File "/usr/lib/python3.8/site-packages/bittytax/conv/bittytax_conv.py", line 117, in main
output = OutputExcel(parser.prog, DataFile.data_files_ordered)
File "/usr/lib/python3.8/site-packages/bittytax/conv/output_excel.py", line 66, in init
'num_format': '"' + config.sym() +
File "/usr/lib/python3.8/site-packages/bittytax/config.py", line 91, in sym
raise ValueError("Currency not supported")
ValueError: Currency not supported

Hi there,

I've just tried converting 3 extracts directly from coinbase / coinbase pro and ledger live. Source files are CSV with all the transacitons.

e.g.:
[root@rasp ~]# bittytax_conv /tax/ledgerlive-operations-2020.08.25.csv
WARNING File format is unrecognised: /tax/ledgerlive-operations-2020.08.25.csv

Any ideas?

An exception is raised by bittytax if the input transaction record file contains less than the 12 excepted columns. This happens for both Excel and CSV files.

The bittytax_conv tool does not parse exported Trezor files for wallets which have labelling disabled.

These exports are missing the "Address Label" column.

Hi.

I love the tool, thank you so much, it works great!

Could I just clarify what the best method is for recording transactions that are crypto-crypto trades via an intermediary exchange (say Changelly) where you never touch fiat? It is my understanding that those are taxable events.

Those transactions typically happen between two different wallets, have two different timestamps (sometimes up to few hours apart between the two legs) and have two sets of fees (although I suppose the one on the receiving end of the transaction is best netted off of the received crypto for simplicity in the spreadsheet).

I see the provided examples show these as 'trade' types directly between cryptos, which makes absolute sense, however, what is the right wallet in the transactions if they are different? The sending wallet or the receiving wallet? And which timestamp is the better one to pick?

Thanks

bittytax_conv HitBTC-Transactions.csv HitBTC-Trades.csv --format RECAP

WARNING File format is unrecognised: HitBTC-Transactions.csv
WARNING File format is unrecognised: HitBTC-Trades.csv

I take it the importer needs updating or something?

Hi there,

From what I understand, you can claim partial costs for mining costs - e.g. transaction fees, partial electrical costs etc. How would I represent that in the transaction statement? as "spend" in FIAT terms? Basically should be able to offset some of the income presented in the annual reports with costs to receive the income?

This is really an awesome tool - Thanks!

Price data looks right for most coins, it is off for stable coins (USDT and BUSD). Screenshot attached

The Bitfinex trades export has a slightly different new format.

Previous header:

'#,PAIR,AMOUNT,PRICE,FEE,FEE CURRENCY,DATE,ORDER ID'

New header:

'#,PAIR,AMOUNT,PRICE,FEE,FEE PERCENT,FEE CURRENCY,DATE,ORDER ID'

BittyTax is unable to get historical prices for tokens such as FARM (Harvest Finance) or BOND (BarnBridge).
After some investigation I found that this is because the CoinGecko API has more than one token with each of these symbols.
For example:
{"id":"barnbridge","symbol":"bond","name":"BarnBridge"}, ... {"id":"bonded-finance","symbol":"bond","name":"Bonded Finance"}, ...
Then in bittytax/price/datasource.py:252 we have a dictionary comprehension that would assign both of these to the same key ('bond') meaning that the second one would overwrite the first one.
Unfortunately these tokens aren't available in the other APIs either.
I'm not sure what an elegant solution would be. Perhaps sorting tokens by market cap and taking the first result would be a good default. Beyond that, I think we would need to allow records to be specified with the CoinGecko id rather than symbol?

Hi. First of all, thanks for the great tool! Trying it out on my exports

I've got error with Kraken format

WARNING File format is unrecognised: 2020.11.18-trades-kraken.csv

The header and first line are like this

"txid","ordertxid","pair","time","type","ordertype","price","cost","fee","vol","margin","misc","ledgers","postxid","posstatus","cprice","ccost","cfee","cvol","cmargin","net","trades"
"TZS2EQ-YQSZG-54KVMP","OTGYDI-3QTP7-LGJV63","XETHZGBP","2020-11-04 09:45:58.4168","buy","limit",295.00000,20.00100,0.03200,0.06780000,0.00000,"","L6UUKF-34A2Y-75LV4D,LGGKOM-ZHWFB-TKHY5K","TKH2SE-M7IF5-CFI7LT",,,,,,,,

I have some Coinbase transactions which are 'Convert' type, e.g., in the full transaction data exported from Coinbase, there are entries such as:

2019-05-23T06:31:43Z,Convert,BTC,0.0002905,6024.10,2.19,1.75,0.440000,Converted 0.0002905 BTC to 0.00575478 BCH

This produces the following output:
WARNING Parser failure for CSV file: data\Coinbase-TransactionsHistoryReport.csv row[19] ['2019-05-23T06:31:43Z', 'Convert', 'BTC', '0.0002905', '6024.10', '2.19', '1.75', '0.440000', 'Converted 0.0002905 BTC to 0.00575478 BCH'] ERROR Unrecognised Transaction Type: 'Convert'

These conversions from one crypto currency are not reflected correctly in the balances as they aren't being processed

Dropping this bug report here before I forget about it. Previously converted files did not have a Note field. Most of these now give errors because the 13th column previously was the first column of ignored rows, but now interpreted as Note. If this is a number or date, and not string, then the whole thing breaks -- and I'm very lucky that a lot of mine are numbers instead of strings.

In my case it's not a simple re-convert problem because I happened to have made manual edits to the converted files, so I have to manually open and add an empty column to all the files/sheets.

There is a fundamental danger of backwards compatibility when adding fields and assuming ignored data was also shifted - I was commenting on this in #73 where I also proposed moving ignored rows in a separate sheet in the same spreadsheet.

If an assets transactions are all matched by the same day or bed and breakfast rule, so no section 104 pooling is required (i.e. you bought and sold the exact amount of an asset on the same day). No holding for that asset exists. It should really have a holding of 0.

This is because the section 104 logic initialises the holding to zero, which does not happen in this case.

This would only be noticeable if show_empty_wallets: True.

bittytax_conv does not interpret Binance fees correctly.

There's an issue parsing the format of the Binance transactions csv whereby if fee asset does not match with either the buy or sell, then it does not import it correctly.

Furthermore the type of transaction "buy" or "sell" is then not parsed and in the resulting file everything is a buy. Asset names from second "market" column are not split so the asset name is parsed as ADAETH which is not correct.

I'm guessing Binance have changed their format and the program's not yet been updated.

Please feel free to close this issue, it's simply a suggestion.

Swipe.io have just added an 'Export History' option to the app. The history is exported as a CSV. An example of the data export below. Perhaps this could be added to the conversion tool.

Date field explanations:

receive - wallet deposit
rebateReward - card benefit rebate, example Spotify
cardReward - card cashback
exchangeSend/exchangeReceive. - trade
reserveEntry - staking lockup
send - wallet withdrawal

CSV:

Installed using pip
Mac OS 10.15.7

Traceback (most recent call last):
File "/usr/local/bin/bittytax", line 11, in
load_entry_point('BittyTax==0.4.2', 'console_scripts', 'bittytax')()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/init.py", line 489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/init.py", line 2843, in load_entry_point
return ep.load()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/init.py", line 2434, in load
return self.resolve()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/init.py", line 2440, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "/Library/Python/2.7/site-packages/BittyTax-0.4.2-py2.7.egg/bittytax/bittytax.py", line 16, in
from .config import config
File "/Library/Python/2.7/site-packages/BittyTax-0.4.2-py2.7.egg/bittytax/config.py", line 13, in
class Config(object):
File "/Library/Python/2.7/site-packages/BittyTax-0.4.2-py2.7.egg/bittytax/config.py", line 17, in Config
TZ_UTC = dateutil.tz.UTC
AttributeError: 'module' object has no attribute 'UTC'

Installation output

pip install BittyTax
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: BittyTax in /Library/Python/2.7/site-packages/BittyTax-0.4.2-py2.7.egg (0.4.2)
Requirement already satisfied: python-dateutil in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python (from BittyTax) (1.5)
Collecting requests
Downloading requests-2.25.0-py2.py3-none-any.whl (61 kB)
|████████████████████████████████| 61 kB 3.1 MB/s
Collecting pyyaml
Downloading PyYAML-5.3.1.tar.gz (269 kB)
|████████████████████████████████| 269 kB 4.3 MB/s
Collecting xlrd
Downloading xlrd-1.2.0-py2.py3-none-any.whl (103 kB)
|████████████████████████████████| 103 kB 5.4 MB/s
Collecting xlsxwriter
Downloading XlsxWriter-1.3.7-py2.py3-none-any.whl (144 kB)
|████████████████████████████████| 144 kB 4.6 MB/s
Collecting jinja2
Downloading Jinja2-2.11.2-py2.py3-none-any.whl (125 kB)
|████████████████████████████████| 125 kB 4.9 MB/s
Requirement already satisfied: xhtml2pdf in /Library/Python/2.7/site-packages/xhtml2pdf-0.2.5-py2.7.egg (from BittyTax) (0.2.5)
Requirement already satisfied: colorama in /Library/Python/2.7/site-packages/colorama-0.4.4-py2.7.egg (from BittyTax) (0.4.4)
Requirement already satisfied: tqdm in /Library/Python/2.7/site-packages/tqdm-4.52.0-py2.7.egg (from BittyTax) (4.52.0)
Collecting certifi>=2017.4.17
Downloading certifi-2020.11.8-py2.py3-none-any.whl (155 kB)
|████████████████████████████████| 155 kB 4.6 MB/s
Collecting urllib3<1.27,>=1.21.1
Downloading urllib3-1.26.2-py2.py3-none-any.whl (136 kB)
|████████████████████████████████| 136 kB 4.1 MB/s
Collecting idna<3,>=2.5
Downloading idna-2.10-py2.py3-none-any.whl (58 kB)
|████████████████████████████████| 58 kB 4.4 MB/s
Collecting chardet<4,>=3.0.2
Downloading chardet-3.0.4-py2.py3-none-any.whl (133 kB)
|████████████████████████████████| 133 kB 4.9 MB/s
Collecting MarkupSafe>=0.23
Downloading MarkupSafe-1.1.1-cp27-cp27m-macosx_10_6_intel.whl (17 kB)
Collecting html5lib>=1.0
Downloading html5lib-1.1-py2.py3-none-any.whl (112 kB)
|████████████████████████████████| 112 kB 4.8 MB/s
Collecting pyPdf2
Downloading PyPDF2-1.26.0.tar.gz (77 kB)
|████████████████████████████████| 77 kB 4.2 MB/s
Collecting Pillow
Downloading Pillow-6.2.2-cp27-cp27m-macosx_10_6_intel.whl (3.9 MB)
|████████████████████████████████| 3.9 MB 5.1 MB/s
Collecting reportlab>=3.3.0
Downloading reportlab-3.5.55-cp27-cp27m-macosx_10_9_x86_64.whl (2.5 MB)
|████████████████████████████████| 2.5 MB 4.8 MB/s
Requirement already satisfied: six in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python (from xhtml2pdf->BittyTax) (1.12.0)
Collecting python-bidi>=0.4.2
Downloading python_bidi-0.4.2-py2.py3-none-any.whl (30 kB)
Collecting arabic-reshaper>=2.1.0
Downloading arabic_reshaper-2.1.1-py2-none-any.whl (16 kB)
Collecting webencodings
Downloading webencodings-0.5.1-py2.py3-none-any.whl (11 kB)
Collecting configparser; python_version < "3"
Downloading configparser-4.0.2-py2.py3-none-any.whl (22 kB)
Requirement already satisfied: setuptools in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python (from arabic-reshaper>=2.1.0->xhtml2pdf->BittyTax) (41.0.1)
Requirement already satisfied: future in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python (from arabic-reshaper>=2.1.0->xhtml2pdf->BittyTax) (0.17.1)
Building wheels for collected packages: pyyaml, pyPdf2
Building wheel for pyyaml (setup.py) ... done
Created wheel for pyyaml: filename=PyYAML-5.3.1-cp27-cp27m-macosx_10_15_x86_64.whl size=45648 sha256=d953a46b14f6cb355c56442f0d52f6c6de81697b98a14740d432d4e8543e38e5
Stored in directory: /Users/user/Library/Caches/pip/wheels/d1/d5/a0/3c27cdc8b0209c5fc1385afeee936cf8a71e13d885388b4be2
Building wheel for pyPdf2 (setup.py) ... done
Created wheel for pyPdf2: filename=PyPDF2-1.26.0-py2-none-any.whl size=61083 sha256=0562e62b2a99e3472443b1fb80a43e48b06990be8dba5330e220b78e1fe11561
Stored in directory: /Users/user/Library/Caches/pip/wheels/c4/28/12/ea7a7966a605fd666786bc7e0482e8e52c23ec95e7616eb70c
Successfully built pyyaml pyPdf2
Installing collected packages: certifi, urllib3, idna, chardet, requests, pyyaml, xlrd, xlsxwriter, MarkupSafe, jinja2, webencodings, html5lib, pyPdf2, Pillow, reportlab, python-bidi, configparser, arabic-reshaper
WARNING: The script chardetect is installed in '/Users/user/Library/Python/2.7/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
WARNING: The script pybidi is installed in '/Users/user/Library/Python/2.7/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed MarkupSafe-1.1.1 Pillow-6.2.2 arabic-reshaper-2.1.1 certifi-2020.11.8 chardet-3.0.4 configparser-4.0.2 html5lib-1.1 idna-2.10 jinja2-2.11.2 pyPdf2-1.26.0 python-bidi-0.4.2 pyyaml-5.3.1 reportlab-3.5.55 requests-2.25.0 urllib3-1.26.2 webencodings-0.5.1 xlrd-1.2.0 xlsxwriter-1.3.7

Import all files csv's in a directory at ones ;-)

lets say you have a bunch of CSV's you have converted with the bittytax_conv and want to make a repport on all of them at once.

ex.
bittytax -D /all-tax-files-dir/
trys to to load all files in the dir

Hi Scott,

How does Bittytax manage coinbase and coinbase pro? Some oddities based on various tries I've done to get it right:

Scenario - I've taken raw export files from both platforms for the full duration - i.e. from signup day.

1. 'audit' table in the PDF report is wrong - shows sizeable balances in coinbase when it should be 0. Coinbase pro is correct.
2. I get "WARNING Balance at Coinbase:BTC is negative -0.02725305" error message during PDF generation - quite a few rows. I definitely didn't ever have a negative balance.
3. Looking at the exports from CB and CB Pro - I'm seeing that majority of the transactions are in BOTH these files.

e.g. Coinbase file:

coinbase pro:

Note the few minutes delta between these.

Not sure how to manage this?

Thanks!

Suppose I have the following data (exaggerated for effect):

Two transactions on the same date and time. As the buy/sell value is missing for both entries, BT is fetching it from online sources, and then computes a large gain, which I didn't expect. What BT does is:

• fetch the value of 1 ETH on the date, 447 GBP
• fetch the value of 1 BTC on the date, 14377 GBP
• compute a capital gain of 14377 - 447 = 13929 GBP

However, let's say that I happened to have found a schmuck or a clever person (*) to be happy to sell me 1 BTC for 1 ETH. Why is it assumed that I sold 1 ETH for 14377 GBP then bought 1 BTC with that, instead of selling 1 ETH for 447 GBP then buying 1 BTC with that? Basically, the cost basis is taken as equal to the notional value of one of the two assets - but what rules govern which asset is chosen?

This is a same-day transaction where I'd expect the source asset's cost basis to be propagated, not the target asset's. Obviously, the person is getting 1 ETH, which if sold on the market at the same time would be valued 447 GBP (notional value).

I expected 0 capital gain here, with a pool of 1 BTC having allowable cost (cost basis) of 447 GBP. A swap, rather than a trade (Koinly has an option for this, by the way).

(*) desperate, with only 60 seconds left to invest ETH in this 1000x yield ICO ...

keep getting the same error msg when I run line commands like bittytax example.csv , bittytax_price ETH etc. etc.

I am not familiar with colorama and just wondering if this has do with it and someone can help solve the issue.

Traceback (most recent call last):
File "C:\Users\Anaconda3\Scripts\bittytax_price-script.py", line 11, in
load_entry_point('BittyTax==0.4.1', 'console_scripts', 'bittytax_price')()
File "C:\Users\Anaconda3\lib\site-packages\pkg_resources_init_.py", line 489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "C:\Users\Anaconda3\lib\site-packages\pkg_resources_init_.py", line 2852, in load_entry_point
return ep.load()
File "C:\Users\Anaconda3\lib\site-packages\pkg_resources_init_.py", line 2443, in load
return self.resolve()
File "C:\Users\Anaconda3\lib\site-packages\pkg_resources_init_.py", line 2449, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "C:\Users\Anaconda3\lib\site-packages\bittytax-0.4.1-py3.6.egg\bittytax\price\bittytax_price.py", line 22, in
sys.stdout.reconfigure(encoding='utf-8')
File "C:\Users\Anaconda3\lib\site-packages\colorama\ansitowin32.py", line 29, in getattr
return getattr(self.__wrapped, name)
AttributeError: '_io.TextIOWrapper' object has no attribute 'reconfigure'

thank you
Vi

Both bittytax and bittytax_price raise this exception if they try and get the historical BTC price with a date after 2020-08-23.

This is primarily due the CoinDesk API which has stopped working after that date for historic prices.

Needs a fix to catch this exception and then try the next data source in sequence, by default this is currently CryptoCompare.

Several exports, e.g. Celsius, provide USD value for transactions. This is highly useful as it makes for accurate tax computation which a daily price might mess up (we again have >50% price swings in a single day).

I'd propose to use this, even though the translation to GBP would use a daily price -- there is much less volatility between fiat pairs.

This shouldn't be difficult to implement in the current price logic, just another price table to fetch per $fiat/GBP pair.

Hey S!

I've been generating some historical tax records and I've found that the audit results will basically provide a table based on ALL your input data including years not included in the specific year I've requested - e.g. running bittytax -ty 2018 with an excel file that has all data from 2016 - 2020 will result in transactions showing data from 2018 but the audit results showing your current balance as of the end of the input data, in this case 2020.

I think what could be useful:

1. When running bittytax without -ty parameter, the PDF report should have an audit page for each tax year, showing what the balance was at the end of that tax year for each of your holdings

2. When running bittytax with the -ty parameter, it generates the audit table based on your holdings at the end of that tax year, rather than what's latest in your input file.

Workaround does exist - it just requires manipulating the source file (i.e. if you started crypto investing in 2016 you have a 2016 file, a 2016-2017 file, a 2016-2018 file, a 2016-2019 file etc) but that's just complicated!

Thanks!

What would be required to add tooling / support crypto tax reporting for USA?

There is an issue with the Ledger export when dealing with Uniswap (and probably other DEX) transactions. The trade is recorded as two different events in the export. As an example:

So the current output of bittytax_conv is:

But what is expected is:

The current bittytax_conv will balance the account but the tax calculation by bittytax would be wrong

Is it possible to use this tool with BitMex or other derivatives trade data?

Hello,

in the Crypto.com exports, there can be transactions marked as campaign_reward which currently are not recognised by the conversion tool:

row[422] ['2020-09-23 07:41:16', 'Competition Reward', 'BLZ', '481.2319538', '', '', 'GBP', '31.11', '43.2043002675', 'campaign_reward']
ERROR Unrecognised Transaction Kind: 'campaign_reward'

It would be great to add support to this kind of events

The format is as follows:

account_type,order_id,trade_id,create_time_utc,symbol,side,liquditiy_indicator,traded_price,traded_quantity,fee,fee_currency
SPOT,1038993879336470371,1038993954853985121,2020-12-24 09:13:52.801,ETH_USDT,BUY,MAKER,584.14,0.01711,0.00001711,ETH
SPOT,1039001110145862019,1039003008124075074,2020-12-24 09:18:22.609,ETH_CRO,BUY,MAKER,10608.0,0.07,0.742567,CRO

There is also a staking format:

create_time_utc,stake_currency,stake_amount,apr,interest_currency,interest_amount,status
2020-12-21 00:00:00.000,CRO,5000.00000000,10.00%,CRO,1.36986301,1
2020-12-22 00:00:00.000,CRO,5000.00000000,10.00%,CRO,1.36986301,1

Thanks!

The bittytax_conv tool raises the exception below if passed an unrecognised or missing file.

except FileNotFoundError:

NameError: global name 'FileNotFoundError' is not defined

This only happens when using Python 2.

I wrote a fix for this in my fork here aleqx@460818c

I get the following warning message when I do bittytax_con of coinbase transactions which has staking rewards for XTZ

row[38] ['2020-07-07T05:47:57Z', 'Rewards Income', 'XTZ', '0.033889', '1.96', '0.070000', '0.070000', '0.00', 'Received 0.033889 XTZ from Coinbase Rewards']
ERROR Unrecognised Transaction Type: 'Rewards Income'

On recap.io one can choose a default accounting price for transactions that are missing their cost basis or nominal value: day average, day open, day close, day low, day high.

Is there such a setting for bittytax? If not, which one does BT consider when fetching prices online?

As you know, luck or bad luck can add/subtract quite bit from the tax bill given we had plenty of 50%+ swings in a single day. Even though this choice should be made once and then stuck with (HMRC doesn't like us gaming the system), the nature of someone's trading can take advantage of this choice.

It's a useful option to have.

@nanonano offered a first reply in #42 (comment)

Example:

With transfers_include=True I get:

https://i.imgur.com/vi149On.png

And with transfers_include=False I get

https://i.imgur.com/XSvjAnA.png

I believe both are wrong. The HMRC guidance says that fees suffered before the transaction is recorded in the blockchain are to be considered allowable cost, deductible from gains.

First, I would expect that regardless of the value of transfers_include, the fee of 0.5 BTC to be recorded as allowable cost to be deducted from future gains. This doesn't seem to happen in either case above.

Second, I believe the pool cost and capital gains calculations are wrong in these example.

When transfers_include=False the former 0.5 BTC from fees (valued at 500 GBP) is allowable cost. Both Trades are done at a valuation of 1BTC = 1000GBP, so the price per token in the pool did not change after the 2nd trade -- here I agree with BT that the gain for the 2nd trade is 0 GBP. However, I'd expect BT to report a 500 GBP loss for the year, from the previous fees figure.

When transfers_include=True nothing really should change since the deposit happened before the 2nd trade, so the pool rebalances. The P&L for the year should be the same. The token cost for the 2nd trade also seems incorrect.

I'll have a look later myself at what the code is actually doing, after I'm done importing all data from my wallets and exchanges, but I thought to flag this for you now, as withdrawal fees are bound to exist in most people's books -- my example is exaggerated, obviously, but those with many transactions, arbitrageurs, etc can rack up significant exchange withdrawal fees.

Hi there

Total newbie question. I'm trying to add support for an exchange, but I am struggling to understand how I am supposed to run the bittytax_conv script to test. My first instinct is to run the script directly after installing all dependencies, which gives me this output:

$ python bittytax/conv/bittytax_conv.py  
Traceback (most recent call last):
  File "bittytax/conv/bittytax_conv.py", line 13, in <module>
    from ..version import __version__
ValueError: attempted relative import beyond top-level package

I am assuming this is completely wrong. Could somebody maybe advise how I should run the script to test locally?

Thanks!