Mid-Year Filer Change
Contents
Overview
In instances where a filing entity changes mid-year, there are typically two options with respect to year-end reporting:
- File a single tax form for each Account – typically under the go-forward entity, or
- File two separate tax forms for each Account – one before and after the filer change
In the Taxbit platform, a single Filer ID is assigned to each Account, and only a single tax form is generated per year for each Account. The purpose of this article is to provide some helpful information with respect to handling a mid-year change to a filing entity, particularly for instances where two separate tax forms should be generated for each Account.
Please reach out to your CX representative or contact your Customer Success Manager for additional information.
Things to Consider
It’s helpful to consider the following, as the answers may impact the potential next steps:
- When did the change occur? If at year-end, a simple update to Filer Setup may be sufficient.
- Should cost basis information for historical activity be retained by the new filing entity? Or should the inventory be considered “noncovered,” as a result of a transfer from one entity to another?
- Are new, unique Account IDs being generated under the new filing entity? This is typically the most critical question.
To the extent new, unique Account IDs are generated, inventory may be transferred from the “original” Account ID to the “new” Account ID.
Otherwise, it’s typically recommended that a separate organization be created.
If you’re still looking for alternatives, certain clients have also explored migrating ending inventory – where information about open lots at the time of the filer change is exported, and that information is transposed into the appropriate transaction types, before getting re-ingested. Please refer to the following guide for more information: Migrate Open Lots
Transfer Inventory
Taxbit supports a transaction type/subtype of Deposit > Internal-Personal, which can be used alongside the Withdraw transaction type, for instances where a digital asset is received as a transfer from one Account to another Account (i.e., typically sharing the same Account Owner).
For inventory transferred using this transaction type, the original cost basis of the lots transferred will be retained. For future disposition, the original acquisition date will be used for any disposition method sorting logic and will also be used to determine the ultimate holding period of the asset, where applicable, if it is later disposed of.
Example –
| Original Account | New Account | |
| Transaction ID | [UUID_1] | [UUID_2] |
| Transaction Type | Withdraw | Deposit > Internal-Personal |
| Received | – | 1 BTC |
| Sent | 1 BTC | – |
| Fee | – | – |
| Counterparty Transaction ID | – | [UUID_1] |
This transaction type can be leveraged to assist with a mid-year filer change. Any activity that occurs prior to the filer change would be associated with the “original” Account ID. The ending inventory (as of the date of the filer change), is transferred to the "new" Account. And any activity that occurs after the filer change would be associated with the “new” Account ID.
Please note: The Deposit > Internal-Personal transaction type/subtype cannot pull inventory or cost basis information from a different organization.
Separate Organization
To the extent you would like to continue to leverage the same Account IDs for both periods – before and after the filer change – it’s recommended that a separate organization is created.
Once created, historical activity can be ingested into the new organization. Note, however, that certain adjustments should be made to the historical transaction activity prior to re-ingesting, to ensure that the activity that occurred prior to the filer change is not treated as reportable in the new organization. Any activity that occurs after the filer change can solely be provided to the new organization – this information does not need to be provided to the original organization.
This approach allows you to include all of the historical transactions in the new environment, while ensuring they are not picked up as taxable events for the new filing entity.
Backfill Historical Activity
When backfilling all historical activity, the following updates should be made to the activity that occurred prior to the filer change.
Please note: While the below covers a majority of relevant updates, it is not intended to be an exhaustive list, and may vary depending on your integration. Please reach out to your CX Representative or Customer Success Manager, if you have any additional questions.
1. Update any Sell and Expense transactions to Withdraw transactions
| Original | Updated | |
| Type | Sell | Withdraw |
| Received | 75000 USD | – |
| Sent | 0.5 BTC | 0.5 BTC |
| Fee | – | – |
| Original | Updated | |
| Type | Expense | Withdraw |
| Received | – | – |
| Sent | 0.5 BTC | 0.5 BTC |
| Fee | – | – |
2. For any Trade transaction with a digital asset on both sides, split the activity into two separate transactions.
| Original | Updated | ||
| Type | Trade | Deposit > Cost-Basis-FMV | Withdraw |
| Received | 0.5 BTC | 0.5 BTC | – |
| Sent | 20 ETH | – | 20 ETH |
| Fee | – | – | – |
3. For any transaction with a fee of a digital asset that matches the Sent Asset, the fee amount should be included in the Sent Quantity field
| Original | Updated | |
| Type | Withdraw | Withdraw |
| Received | – | – |
| Sent | 0.5 BTC | 0.51 BTC |
| Fee | 0.01 BTC | – |
| Original | Updated | |
| Type | Sell | Withdraw |
| Received | 75000 USD | – |
| Sent | 0.5 BTC | 0.51 BTC |
| Fee | 0.01 BTC | – |
| Original | Updated | ||
| Type | Trade | Deposit > Cost-Basis-FMV | Withdraw |
| Received | 0.5 BTC | 0.5 BTC | – |
| Sent | 20 ETH | – | 20.1 ETH |
| Fee | 0.1 ETH | – | – |