USA - IRS tax rules about bittytax

[jcperkins12]

@nanonano, thanks for the recent "Added local currency support" commit. I was just about to start looking into how to add that.

I'm going to take a shot at this when I have some time and if I end up with anything useful I'll submit a PR. In the meantime (and in case I fail) here are some notes that I've compiled for my own US taxes for 2020 in case they can be helpful for anyone else that stumbles across them. I'm not an accountant and I have pretty specific use cases (i.e. no mining, gifting, staking and I'm pretty concentrated on the rippled blockchain) so this will probably be more of a starting point than a comprehensive outline. I'm also not exactly sure how BittyTax will want to report the results to be useful when filing, but I'll be happy if I get to that problem.

IRS Notes for 2020

Events that are not taxable

1. Buying and holding [1]
2. Transferring funds between two wallets that you own [1]

Gains Reported as Income

1. Cryptocurrency received as a payment from providing some service or product[2]
2. Any cryptocurrency that results from a hard fork[2]
   • soft forks are not taxable events because no new currency is created
3. Currency received from Airdrops [2]
4. Interest earned from lending crypto[1]. See the CryptoTrader.tax DeFi tax guide for more details about this on DeFi apps because it looks like the IRS will treat DEFI liquidity pools differently based on how they execute their swapping/lending protocols.
5. Staking rewards [1]

Income can be reported several different ways[1]:

• Schedule C - If you earned crypto as a business entity, like receiving payments for a job or running a cryptocurrency mining operation, this is often treated as self-employment income and is reported on Schedule C.
• Schedule B - If you earned staking income or interest rewards from lending out your crypto, this income is generally reported on Schedule B.
• Schedule 1 - If you earned crypto from airdrops, forks, or other crypto wages and hobby income, this is generally reported on Schedule 1 as other income.

Note: The time of an airdrop or hard fork event is determined as the time that the owner gains access to the funds, i.e. if an airdrop is delivered to a users account at an exchange in December of 2019, but the exchange doesn't support the currency until January of 2020, then it would be income generated in 2020 and not in 2019.

Capitol Gains

In general the remainder of the transaction types require that cryptocurrency classified be classified as a property by the IRS and not as a currency or security - IRS Publication 551

• FIFO, LIFO and HIFO methods can be used to calculate cost basis[2]
• apparently multiple depot or single depot queuing methods may be used[2], i.e. transactions can be grouped by account and cost basis is tracked within a single account with exchanges between accounts or all transactions can be aggregated into one large queue that tax lots are selected from.
• "Short term capital gains apply for any crypto that was held for less than 12 months"[1].
  • "Short term capital gains don’t get any special tax treatment. They are simply treated as income on your taxes (just like income from your job), and thus you pay taxes on your short term capital gains according to your personal income tax bracket"[1]
• Long term capital gains apply for any crypto that was held for 12 months or more[1] and offer a lower tax rate on the gains.
• Capitol gains transactions are reported on IRS Form 8949
• Once your 8949 is filled out, take your total net gain or net loss from 8949 and include it on Schedule D.
• Note: If filing with TurboTax, I believe that you can manually enter the totals into the cryptocurrency income section using the date of the most recent transaction. Click on one of the cryptocurrency services and then at the bottom of the page I had a hyperlinked questions "What if I have more than 2251 transactions?" that provided more details.

Gifting Summary from CryptoTrader.tax Tax Guide

Gifting is tax-free up to $15,000 per friend or family member.

Donating your crypto is tax free and deductible as long as you are donating to a registered charity.

• Donations greater than $500 have to be reported on Form 8283.
• The amount of your donation that is tax deductible depends on how long you have held the assets:
  • For crypto held for more than 1 year, you can deduct up to 30% of your Annual Gross Income
  • For crypto held for less than a year, you can deduct up to 50% of your Annual Gross Income and the lesser of cost-basis or the fair market value of the donated crypto

Misc.

• if you were not aware that you needed to report your crypto on a previous years taxes, you will need to amend a prior years return with IRS Form 1040X amended tax return[1]
• Note: For people with more than 200 transactions AND $20,000 of gross payments, an IRS Form 1099-K may be issued to you or may be a useful tool for reporting transactions. I don't currently plan to do anything with this.

Sources:

• [1] CryptoTrader.tax Tax Guide
• [2] Accointing.com Tax Guide
• [3] TurboTax

Other resources

(more as a note to myself for the future)

• CryptoTrader.tax: The DeFi Crypto Tax Guide
• CryptoTrader.tax: Complete NFT Tax Guide
• CryptoTrader.tax:

Disclaimer - These notes are for informational purposes only and should not be construed as tax or investment advice. Please speak to your own tax expert, CPA or tax attorney on how you should treat taxation of digital currencies.

[rsnodgrass]

Besides the tax strategies (rule sets) in the core BittyTax engine, and the associated reporting templates, there may be additional conversion tools that might be useful. Or at least tools that reprocess Transaction Records into summaries based on various IRS rules for simplicity.

For instance, I've been working on a Transaction Record processing tool that combines all the transactions (for a specific type) in a day into a single transaction with a daily cost basis (per IRS Notice 2014-21):

    A taxpayer who receives virtual currency as payment for goods or services must,                        
    in computing gross income, include the fair market value of the virtual currency,                      
    measured in U.S. dollars, as of the date that the virtual currency was received.                   

IRS specifically calls out that the cost-basis is based on the date that the virtual currency was received, and does NOT need to be tracked on an individual crypto deposit level. This is critical and required since some crypto currencies generate lots of micro transactions across the day, which the US tax code was never really designed to even consider. Plus most tax processing systems fall apart with the sheer scale of this level of transactional data.

For example, I am seeing Helium wallets that will have 10s of thousands, or hundreds of thousands, of wallet deposit transactions EVERY DAY. Fortunately, the IRS allows at least for cryptocurrency deposits to roll up the total quantity of the cryptocurrency per day into a single amount (by transaction type), and then use a per-day price for this rollup (whatever price source is used must be consistently applied). This tax rule DOES NOT apply to any cryptocurrency dispositions. It is still unclear to me how this works with any transaction fees associated with those transactions.

In my case, I plan to keep and archive forever the following transaction files:

• original source files from all wallets (in their native format)
• BittyTax transaction files converted from those native wallet source files
• fully reprocessed BittyTax transaction files with rollups per IRS (as well as any other transformations to meet tax code)
• the final resulting output reports from running through all the "reproccessed" transaction files through tax processing software (e.g. BittyTax or other)

If BittyTax rules engine doesn't quite meet my needs, I would convert the BittyTax transaction files into something that could be processed by another rules engine. BittyTax conversion tools are awesome to have even if you don't use the BittyTax rules engine.

[rsnodgrass]

@jcperkins12 will be watching in interest! In the meantime, trying to make sure the conversion tools work for all my various wallets. It really does seem that splitting out the tax processing for different jurisdictions (UK, USA, etc etc) shouldn't be too crazy. The real work is in each tax jurisdictions figuring out the various implications, models, etc. Thanks!

[rsnodgrass]

US allows FIFO and LIFO....as well as HIFO (and other strategies) as long as you are using SpecID for identifying all transactions. However, SpecID is very complex. For most users, FIFO is probably correct model to use as it is simple. IRS requires consistent application by a tax entity. You can't willy nilly choose and change strategies over time.

The most important thing as a tax entity in the US is that once you have picked a strategy, you MUST stick with it pretty much forever across tax years. It is nearly impossible to change, without liquidating your entire positions in the currency you'd like to change the strategy. There are some ideas (proposed by @greg5 on Helium Discord) around having a year-end summarization of all transactions (and utilizing SpecID) so that each tax year you start with a complete set of historical records which allows flexibly changing tax strategy on an individual tax year basis. That is the "dream", but requires significant tooling to allow. That's where things like an open source tax computation platform enable innovation. Hopefully BittyTax can evolve into a more sophisticated platform over time.

[rsnodgrass]

One interesting aspect of Helium mining is that there are often multiple parties involved. For example, one person (tax entity/provider) may own the miner, another person (host) may get a commission for operating the miner on their premises, another person might get a commission for referring a host to the provider (referrer), and perhaps even other entities may get a cut of the mining rewards.

As more non-PoW based blockchains start appearing or evolving, I'm wondering if there are other Transaction Record Types that will be required for BittyTax. This will likely evolve as various taxation authorities around the world model these kinds of relationships differently.

[rsnodgrass]

And as always with my comments:

DISCLAIMER: My comments and strategies suggested in this discussion and within documents and tools provided for BittyTax are for informational purposes only and should not be construed as tax or investment advice. Please consult with your tax expert, CPA, and tax attorney on how you should be handling the taxation of cryptocurrencies.

[nanonano]

US version of BittyTax is looking for beta testers! :) Details are here: https://github.com/BittyTax/BittyTax/wiki/USA

[tiems90]

I tried it out and it worked well! For a koinly import I just had to change the header names manually on the export so bittytax_conv could pick it up, but it worked well!

[nanonano]

You can now choose the output format, using the--format argument.

The options available are:

Format	Description	Default Filename
PDF	BittyTax tax report in PDF format (default)	BittyTax_Report.pdf
F8949	IRS Form 8949	BittyTax_f8949-<year>.pdf
TURBOTAX_CSV	TurboTax Online "Other (Gain/Loss)" CSV format	BittyTax_TurboTax.csv
TURBOTAX_TXF	TurboTax Desktop TXF format	BittyTax_TurboTax.txf
TAXACT	TaxAct "1099-B CSV import" format	BittyTax_TaxAct.csv

If you use TurboTax or TaxAct would love some feedback if these are working correctly?

[tiems90]

I just validated the TXF with TurboTax Desktop; it worked well! The IRS form looked good too; just missing totals.

[nanonano]

The majority of the code is the same regardless of the countries tax laws.

All the data file parsers can be used for any country, and the splitting and pricing of the trades into buys and sells has been designed to support any currency. You just need to set CCY to 'USD' in the Config object.

Just need someone who understands the US tax rules to implement the tax calculations.

[rsnodgrass]

I worked a bit this evening on removing the dependency on GBP as the only fiat currency as a basis for all values. I'll slowly tease this apart as a first step. I've done this for the bittytax_conv conversion tool as well as bittytax that reads the CSV and Excel input files.

[rsnodgrass]

The more complicated aspect is coming up with how to split out tax rules. Right now there is a hardcoded UK ruleset for individuals, and another one for businesses. It seems like this entire model should be a bit more flexible, something like a rule set that lists which rules apply (and these can be reusable small components). This way you could tease apart and allow people to define their own rule sets (including replacing one of the rules in existing sets).

[nanonano]

Hi @rsnodgrass, you can already set a local currency which is not GBP, see ae8a592#diff-355fa8d03551cdffe4191d48035382462bf4911fd0f6634815130d7cdc701679.

The UK tax rules are very specific to the UK, what needs to be added is support for generic methods such as FIFO, LIFO as these are used by many counties, I believe the US is FIFO to a degree?

[nanonano]

Hi @tiems90, thanks for testing, glad it worked for you.

Please raise an issue for Koinly with details of the new header format, and I'll get the parser updated.

[nanonano]

Thanks @tiems90 that's awesome news!

Did you have any transactions with "Various" acquisition dates? Just wondering if TurboxTax categorised them correctly as long or short-term holdings?

I used different tax ref codes for short/long, hoping it would split them correctly without manual intervention.

[tiems90]

I don't have any—but if you have a specific test case of BittyTax_Records.xlsx that you'd like to me run + try to import I'm happy to give it a go.

[nanonano]

That would be very helpful thankyou.

Please could you try the example.xlsx file.

This will generate a disposal with "Various" acquisition dates, would it matter if the trades are in previous tax years?

[nanonano]

Hi, @tiems90, when you said "missing totals" did you mean on a F1040 schedule D? The totals in section 2 of F8949 should be present.

I just validated the TXF with TurboTax Desktop; it worked well! The IRS form looked good too; just missing totals.

[tiems90]

Ah! You're right, I do see them on the final page of a section. I was looking at the in-between pages that were reporting transactions. The final page of a Short term/long term section does show them.

It looks like the transaction with Various did not import correctly via TXF. I have attached the generated forms with Turbotax here. Short term matches with the generated F8949, Long term does not on account of missing the large tx. With a manual correction this can be fixed inside Turbotax; by going to the appropriate worksheet and selecting either S/L in the dropdown.

[nanonano]

Hi @tiems90, thanks for confirming the totals are on the final page.

According to the TXF spec. using "VARIOUS" is not supported, although I've read elsewhere that some platforms do recognise it.

I've just made this change 50708f5, for disposals with multiple acquisition dates, it will use "VARIOUS" in uppercase if it's a long-term disposal, and "various" lowercase for short-term.

This should make it easier to categorise the disposal correctly if the import does not recognise it.

[nanonano]

If you're using the USA version of BittyTax, please update and re-install as I found a bug in the tax logic, see 7b78c15.

This impacts you if you had a single disposal which was calculated from both short-term and long-term holdings.