Koinly Cost Basis Settings Guide: FIFO, HIFO, Wallet Tracking and Method Migrations

Koinly can calculate different gains from the same transaction history when the home country, cost-basis method, tracking scope or migration date changes. That does not mean the software is choosing a convenient answer at random. Each setting controls which acquisition lot is matched to a disposal and where Koinly is allowed to look for that lot. This guide explains FIFO, LIFO, HIFO, Optimized HIFO, adjusted cost basis, share pooling, universal tracking, wallet-based tracking and method migrations so changes can be reviewed before they alter a tax report.

Last reviewed: October 22, 2026. Koinly can change its settings, migration tools, supported methods, reports and plan requirements. Tax rules vary by country, tax year and individual circumstances. Confirm current Koinly documentation and obtain advice from a qualified tax professional before selecting or changing a method. This independent guide is educational only and is not affiliated with Koinly. It is not tax, legal, accounting or investment advice.

Cost basis is a calculation trail, not a number to type over

Cost basis generally starts with the value of an asset when acquired, adjusted according to applicable rules and relevant fees. When part of that asset is disposed of, Koinly selects one or more acquisition lots and assigns their cost to the disposal. Proceeds minus the selected cost contribute to the calculated gain or loss.

Koinly calculates this from previous history and account settings. Its official guidance says the cost basis displayed on a disposal is not directly editable. If it looks wrong, review the acquisitions, transfers, classifications, dates and settings that produced it. Correcting the source trail allows later calculations to update consistently.

Five concepts that should not be confused

A user can choose FIFO and still obtain different results under universal and wallet-based tracking. FIFO describes ordering; tracking scope describes the pool within which that order is applied.

What is a crypto tax lot?

A tax lot is a quantity of an asset connected to an acquisition date and cost. Buying one BTC today and another next year normally creates distinguishable acquisition history even though both units are fungible. A later disposal needs a rule for deciding which acquisition is treated as sold.

Transfers between a person’s own wallets should preserve the underlying acquisition trail rather than create a new purchase merely because the location changed. That is why complete source and destination history, quantities, timestamps and fees matter.

Why fees matter

Trading, network and transfer fees can be treated differently according to transaction type, settings and local law. Some acquisition-related fees may increase cost; disposal-related fees may affect proceeds; transfer fees can have separate consequences. Koinly includes settings for transfer fees and other calculation choices.

Do not add the same fee twice—once in an exchange trade and again as a manual expense. Compare exchange fills, blockchain records and imported transactions before correcting a discrepancy.

Home country comes before method selection

Koinly uses the selected home country to provide localized reports and recommended calculation settings. Countries do not share one universal rule. A method accepted in one jurisdiction may be unavailable, restricted or inappropriate in another. The relevant law and the taxpayer’s circumstances control—not which result is smallest.

Review residency, reporting currency, tax-year dates and entity ownership. A personal portfolio and a company portfolio should not be combined merely because one Koinly account makes that convenient.

FIFO: oldest eligible units first

First In, First Out assigns the oldest eligible acquisition lots to a disposal first. If one coin was bought for $1,000 and a later coin for $3,000, a sale of one coin under FIFO generally begins with the older $1,000 lot, subject to the applicable pool, transfers and special rules.

FIFO is easy to describe but not always easy to audit. The “first” lot may have travelled through several wallets, been partly disposed of or inherited an adjusted cost through another event. Use Koinly’s Cost Analysis and Ledger views to follow the actual selected quantity.

LIFO: newest eligible units first

Last In, First Out selects the newest eligible lots first. It can generate a different result when market prices have changed between acquisitions. It should not be selected only because recent lots have a favourable cost. Confirm whether the method is permitted and whether consistent records support its use.

Under wallet-based tracking, “newest” means the newest eligible acquisition lot present in the relevant wallet. Moving an older lot into that wallet does not normally turn its original acquisition date into the transfer date.

HIFO: highest eligible cost first

Highest In, First Out prioritizes eligible units with the highest cost. This can reduce a current calculated gain or increase a calculated loss relative to FIFO, but it requires sufficient lot-level identification and must be allowed by the applicable rules.

HIFO is not a button that repairs incomplete data. A missing high-cost acquisition, duplicated low-cost deposit or zero-cost lot can change the output dramatically. Reconcile first, then compare methods.

Optimized HIFO

Koinly documents Optimized HIFO as a specialized US method intended to use specific identification while considering long-term and short-term treatment. It is not equivalent to ordinary HIFO and should not be generalized to non-US taxpayers.

Confirm plan availability, documentation requirements and the tax professional’s interpretation before relying on it. Keep lot-level evidence showing which units were selected.

Adjusted Cost Basis

Adjusted Cost Basis commonly pools or averages cost according to jurisdiction-specific rules rather than selecting individually priced lots in the same way as an xIFO method. Canada is a prominent example in Koinly’s documentation, with additional superficial-loss considerations.

An average-cost calculation can change after acquisitions, disposals and relevant adjustments. Do not recreate it by averaging only purchases visible in one exchange if the applicable pool includes activity elsewhere.

Share Pooling

Share Pooling combines cost according to rules used in jurisdictions such as the United Kingdom, alongside same-day and matching rules. It is not simply a generic average chosen for convenience. Transaction order and repurchases can affect which rule applies.

Use Koinly’s country-specific guidance and official tax-authority sources. A US FIFO tutorial is not an appropriate substitute for UK share-pooling rules.

Methods compared

Cost-basis method versus cost-tracking method

The cost-basis method orders or pools lots. The cost-tracking method defines where Koinly looks for them. Koinly describes a universal pool as treating eligible holdings across wallets together, whereas wallet-based tracking applies the selected method within the wallet involved in the disposal.

This distinction can materially change a gain. Two portfolios with identical acquisitions and sales can produce different lot matches if one uses a universal pool and the other restricts selection by wallet.

Universal tracking example

Suppose ten XRP were bought on Exchange A for $1,000 and another ten on Exchange B for $500. Ten XRP are later sold on Exchange B. With a universal pool and FIFO, the older Exchange A lot may be selected even though the sale occurred on Exchange B.

This is conceptually possible because the pool does not treat wallet location as the boundary for lot selection. Complete transfer and ownership records are still essential.

Wallet-based tracking example

Using the same facts, wallet-based tracking limits the disposal to eligible lots in Exchange B. If only the $500 lot was held there, that lot would normally be selected. The resulting basis differs even though the trade itself is unchanged.

Do not assume the wallet name alone proves lot location. Transfers, partial quantities and imported timestamps determine where Koinly’s ledger places the units.

A transfer does not reset the original acquisition date

Koinly explains that FIFO or LIFO follows the original acquisition date rather than the date the asset enters another wallet. If BTC bought in 2017 is transferred to an exchange in 2026, it remains an older acquisition than BTC bought in 2022 already held there.

This requires correct transfer matching. If the outgoing and incoming sides are missing or chronologically impossible, the lot trail can break.

Incorrect timestamps can select the wrong lot

A CSV timezone error can make a receiving transaction appear before the corresponding withdrawal or make a sale precede its acquisition. Koinly’s transfer-handling documentation notes that implausible timelines can affect calculations, especially where wallet location is significant.

Compare UTC offsets, exchange exports, blockchain timestamps and daylight-saving treatment. Correct source time; do not move a transaction merely until a warning disappears.

Why missing purchase history must be fixed first

When Koinly sees a disposal or transfer without sufficient prior acquisition, it can report missing purchase history or a negative balance. The affected units may carry zero or incomplete cost, overstating gain. Under a migration, those defective lots can also be allocated between wallets.

Import the missing exchange or wallet, investigate API date limits and reconcile the asset chronologically. Do not proceed with a method comparison while a material portion of the available lots has no reliable cost.

Changing a global setting can rewrite earlier years

If a user simply changes the current cost-basis or tracking setting, Koinly may recalculate the entire history according to that setting. Previously downloaded reports can then differ from the current account, complicating amendments, audits and comparisons with filed returns.

Before any change, export the existing tax report, transaction report, settings evidence and applicable lot detail. Record which reports were actually filed.

What a Koinly cost-basis migration does

Koinly’s migration feature allows a supported method to change from a specified point while earlier disposals retain the prior method. This is different from editing past transactions or globally replacing a calculation rule.

The migration record should identify the previous method, new method and effective date. Koinly currently documents limits on supported transitions and the number of migrations, so verify the live interface instead of relying on an old screenshot.

Cost-basis migrations and cost-tracking migrations differ

A cost-basis migration changes between supported ordering methods such as FIFO, LIFO, HIFO or Optimized HIFO. A cost-tracking migration changes the scope from universal to wallet based. These operations solve different problems and can have different direction restrictions.

Do not create both simply because both appear in the same settings area. Identify the legal or record-keeping reason for each change.

Why deprecated overrides should not guide a new workflow

Koinly’s documentation states that cost-basis migrations replaced the older override mechanism. Historic accounts may still show prior configurations, but new guidance should follow the current migration feature.

Preserve evidence of old settings and ask support or a professional how a legacy configuration interacts with current reports before removing it.

A safe migration preparation checklist

1. Confirm the taxpayer, home country, reporting currency and tax-year boundary.
2. Ask a qualified professional which method and tracking scope are permitted.
3. Import every historical wallet, exchange and relevant address.
4. Resolve negative balances and missing purchase history.
5. Review duplicate transactions, transfers, fees and timestamps.
6. Download reports already used for filed returns.
7. Record current cost-basis and portfolio settings.
8. Choose the legally appropriate effective date.
9. Create the supported migration rather than silently rewriting history.
10. Download the migration or allocation evidence.
11. Compare results before and after the effective date.

The US wallet-based transition

Koinly provides a specific workflow for US users moving from universal to wallet-based cost tracking. Its documentation describes a migration date, activation through wallet-based tracking and an allocation of unused lots among wallets. This US workflow should not be copied into another jurisdiction without checking local law.

Some accounts may already show a migration prepared by Koinly. Verify its status, date, wallet-based toggle and allocation report instead of assuming presence means completion.

Lowest Cost to Biggest Wallet

Koinly currently documents a supported allocation method that assigns lower-cost lots to wallets holding larger balances at migration. That is an allocation convention for the transition—not a general statement that the taxpayer purchased those exact lots in those wallets.

Review whether the resulting allocation reflects the intended and permitted process. Preserve the report showing how each unused lot was distributed.

Negative balances can contaminate allocation

Koinly warns that negative balances and missing purchase history can produce zero-cost lots that then enter migration allocation. This can create surprising future gains even if the migration screen itself appears active and complete.

Resolve the underlying missing data before relying on the allocation report. Re-run calculations after corrections and compare the revised allocation.

Lot allocation evidence matters after migration

A future sale needs an explainable opening inventory for each wallet. Save the lot allocation report, pre-migration holdings, effective-date balances, chosen method, decision record and any professional advice. These records help connect pre-transition acquisitions with post-transition disposals.

Store them with tax records, not only inside a live software account whose interface can change.

Practical FIFO versus HIFO example

Assume one ETH was acquired for $1,000, another for $2,500 and one was later sold for $3,000. Ignoring fees and special rules, FIFO could assign the $1,000 lot and show a $2,000 gain. HIFO could assign the $2,500 lot and show a $500 gain.

This example shows why method matters, but not which method is lawful. It also assumes both lots are eligible within the same tracking scope and that their history is complete.

Practical universal versus wallet-based example

One BTC bought cheaply sits in cold storage; another bought recently at a higher price sits on an exchange. A sale occurs on the exchange. Universal HIFO might select the higher-cost eligible lot regardless of location, while wallet-based FIFO or HIFO can only select eligible lots assigned to that exchange wallet.

If the cold-storage BTC had previously moved through the exchange, lot-location history becomes important. Review the Ledger instead of inferring from current balances.

Practical migration mistake

A taxpayer used FIFO in reports already filed, then changes the global setting to HIFO while preparing a new year. Earlier gains now differ from archived Form 8949 totals. The user cannot tell whether old returns or current Koinly data represent the original calculation.

A safer workflow preserves filed reports and uses a supported migration from the permitted effective date. The user then checks transactions on both sides of the date and retains evidence of the change.

Why stablecoin cost basis may not equal one dollar

A stablecoin can trade away from its peg, include fees or inherit cost under a setting that defers gains on crypto-to-crypto trades. Koinly gives an example where a stablecoin carries cost transferred from another asset until a later taxable event.

Do not overwrite the result with $1 automatically. Review the original trade, market value, crypto-to-crypto setting and applicable law.

Swap tags can carry cost and acquisition date

In Koinly, a Swap classification can preserve cost and acquisition date across an asset change according to the selected treatment. This can make Cost Analysis reference a date on which the final token symbol does not appear.

Filter earlier Swap-tagged transactions and determine whether the classification is factually and legally appropriate. A label that makes a warning disappear is not necessarily correct.

Liquidity transactions can redistribute cost

When realization on liquidity events is disabled, entering or exiting a liquidity pool can move cost between received assets rather than realizing the entire result immediately. Later disposals may then show an unexpectedly high or low basis.

Trace Liquidity In and Liquidity Out records, token quantities and settings. DeFi tax treatment remains fact-specific; obtain professional advice where the amounts are material.

Wash-sale and superficial-loss rules can postpone a loss

Some country-specific methods apply anti-avoidance or matching rules when an asset is repurchased near a disposal. A visible economic loss may be added to another lot or deferred instead of appearing immediately.

Review Cost Analysis for the affected sale and later acquisition. Do not change to a generic method simply because the expected loss is absent.

How to investigate a basis that looks wrong

1. Confirm the applicable country rules and permitted method.
2. Record the current Koinly cost-basis and tracking settings.
3. Open the exact disposal in Transactions.
4. Review Cost Analysis to identify selected acquisition lots.
5. Review Ledger to confirm quantity and chronological order.
6. Filter the asset across all relevant wallets.
7. Trace each selected lot back through transfers to its acquisition.
8. Check fees, timestamps, classifications and market values.
9. Resolve missing or duplicate source transactions.
10. Allow Koinly to recalculate, then compare again.

Cost Analysis and Ledger have different jobs

Cost Analysis helps explain which lots and calculations contributed to a disposal. Ledger helps follow the chronological movement and balance of an asset. Use both. A plausible selected lot can still depend on an impossible transfer order, while a non-negative ledger does not prove the correct tax method was selected.

Common causes of zero or low basis

• An acquisition or old wallet is missing.
• A transfer brought cost from an untracked source.
• Missing purchase history exists in another wallet.
• A Swap classification intentionally preserved or shifted cost.
• Merged transactions conceal their true time order.
• A migration allocated a defective zero-cost lot.
• A reward or receipt genuinely has different basis treatment.

Settings review table

What not to do

• Do not choose HIFO solely because it produces the lowest current gain.
• Do not change global settings without preserving filed reports.
• Do not migrate while material balances are negative.
• Do not invent an acquisition to eliminate missing history.
• Do not treat transfer date as original purchase date.
• Do not mix separate taxpayers or entities in one pool.
• Do not assume every stablecoin unit has exactly one dollar of basis.
• Do not use a US migration workflow as universal tax advice.
• Do not delete the allocation report after migration.

Post-change validation

After changing data or completing a migration, compare a sample of disposals before and after the effective date. Verify selected lots, acquisition dates, holding periods, proceeds, cost, fees and gain. Check totals against archived reports where they should remain unchanged.

Review dashboard balances, negative-balance warnings, Tax Reports and any Comprehensive Audit Report available to the account. A completed calculation is not proof that the chosen legal method is correct.

Records to preserve

• Original exchange and wallet exports.
• Public transaction identifiers and wallet-ownership map.
• Koinly transaction and tax reports before the change.
• Screenshots or exports of relevant settings.
• Migration date and type.
• Lot allocation report.
• Post-migration validation report.
• Professional advice and the taxpayer’s method decision.
• A dated log of manual corrections.

Frequently asked questions

Which Koinly cost-basis method gives the lowest tax?

Different methods can produce different timing of gains and losses, but the appropriate method is the one permitted by the taxpayer’s jurisdiction and supported by adequate records. Do not choose solely from the lowest preview.

Is wallet-based tracking the same as FIFO?

No. FIFO determines lot order. Wallet-based tracking determines the wallet pool within which FIFO or another method selects lots.

Can I directly edit cost basis on a sale?

Koinly states that disposal cost basis is calculated automatically. Correct the relevant acquisition, transfer, price, classification or setting that generated it.

Will changing the current method affect old reports?

A global setting can recalculate earlier history. Preserve existing reports and use a supported migration where the change should begin on a defined date.

Why is cost basis zero when I bought the asset?

The acquisition may be missing, located in an untracked wallet, chronologically after the disposal, duplicated incorrectly or disconnected by a transfer. Trace Cost Analysis and Ledger back to the source record.

Should every US user create a wallet-based migration manually?

Not necessarily. Koinly notes that some US accounts may already have a migration configured, while users who always used wallet-based tracking may not need one. Confirm current account status and professional guidance.

Can Koinly decide which method is legally correct for me?

Koinly can provide country settings and calculation options, but the taxpayer and qualified adviser remain responsible for determining the correct treatment.

Official Koinly references

Use these first-party Koinly resources to confirm the live interface and calculation behaviour before changing settings:

• Koinly Blog — official crypto-tax guides, product explanations and regulatory updates.
• Koinly Help Center — Cost Basis Method — FIFO, LIFO, HIFO, Optimized HIFO, ACB, Share Pooling and country context.
• Koinly Help Center — Wallet-Based Cost Tracking — how universal and wallet-based scope can select different lots.
• Koinly Help Center — Cost Basis Migrations — supported method and tracking changes from defined dates.
• Koinly Help Center — US Wallet-Based Migration — migration status, allocation method, negative-balance warning and lot report.
• Koinly Help Center — Troubleshoot Cost Basis Calculations — Cost Analysis, Ledger and common causes of unexpected basis.
• Koinly Help Center — Cost Basis on a Trade — why disposal basis is computed from earlier history rather than edited directly.
• Koinly Help Center — Supported Countries — country coverage and supported standard calculation methods.
• Koinly Pricing — current plan limits and availability of wallet-based tracking and tax reports.

A defensible cost-basis result is not simply the smallest gain Koinly can display. It is a result that follows the applicable rules, starts from complete history, selects eligible lots within the correct scope and remains reproducible from saved reports. Treat every settings change as an accounting decision with a date, evidence and review trail.