Important Considerations

Execution Latency and UX Trade-offs

To provide a seamless UX and still comply with Austrian law, withholding ideally happens at the moment of realisation. Taxbit processes transactions at sub-second latency (P95 < 1s), but some delay between trade execution and withholding calculation is unavoidable. Customers must decide how to handle this gap — common approaches include optimistic withholding (based on a best-estimate gain) with a subsequent true-up, or a brief settlement hold before releasing net proceeds. These UX trade-offs have equally been established at prominent Austrian CASPs who built their own in-house solutions — a certain delay is effectively unavoidable industry-wide.

Austrian Tax Resident Identification

KESt withholding applies only to Austrian tax residents. Taxbit's Self-Certification module is intended to help perform residency determination. If customers do not use Taxbit's self-certification module, they must use their own KYC and onboarding data to flag applicable accounts and apply the AUSTRIA configuration only to those users. Accounts flagged as exempt (e.g., business accounts with a formal declaration) must not have withholding applied — Taxbit does not filter these automatically in this release.

Off-Platform Transfers (Fictitious Sales)

When a user withdraws crypto to an external wallet, Austrian law deems this a taxable fictitious sale unless: (a) it is an internal transfer within the same platform to an account owned by the same individual, (b) the user instructs the platform to share cost basis with the receiving domestic custodian, or (c) the user certifies it is a non-recognition transfer and has filed the appropriate paperwork with the tax authorities. Taxbit treats off-platform transfers as taxable disposals by default; customers must build the user-instruction workflow and communicate with receiving custodians independently, and must submit a non-taxable withdrawal transaction type only when they have determined all requirements have been satisfied.

Crypto-to-Crypto Trades

Under Austrian law, crypto-to-crypto trades between two qualifying crypto assets are non-realisation events: the cost basis of the disposed asset becomes the cost basis of the received asset. Two carve-outs are implemented and worth designing around:

• Old Stock leg: if the disposed side of a trade is an Old Stock lot, Taxbit treats it as a real taxable disposal (tax-free, since all Old Stock has exceeded the 1-year holding period) plus a fair-value acquisition into the received asset's Known Cost Basis pool — not a tax-neutral transfer. Any other pool touched by the same trade (Known, User-Basis, Missing Basis) still transfers tax-neutrally into the matching pool on the received asset.
• Non-qualifying received asset: a swap into a non-qualifying asset — most notably an NFT, which Taxbit does not support on either side of a transaction — makes the disposed leg a taxable disposal rather than a cost-basis transfer.

Customers must submit ordinary crypto-to-crypto trades as trade transaction types, not as sales; submitting them as sales will produce an incorrect withholding calculation.

Fee Treatment

Fees are ignored entirely for KESt withholding purposes on crypto transactions: fees on acquisition do not add to cost basis, fees on disposal do not reduce the capital gain, and crypto-denominated fees are not themselves a separate taxable disposal. Taxbit implements this by carving the fee out as its own disposition — consumed from inventory in the standard pool order (Old Stock → Missing Basis → User-Basis → Known Basis) so it still reduces available inventory correctly — but with its gain and withholding contribution forced to zero. This applies uniformly to trade fees and to fees on income inflows, regardless of whether the fee is denominated in the same asset as the transaction or a different one.

Staking and Lock/Unlock Transactions

Locking a digital asset (e.g., entering a staking pool) and unlocking it generate no gain, loss, or withholding by themselves. In the current implementation, locked inventory is moved into a separate, lock-type-specific pool and is not available to satisfy an ordinary disposal until it is unlocked — Taxbit's longer-term intent is for locking to have no inventory effect at all (a true pass-through), but that simplification has not shipped as of this release. Customers should expect that a sale which would otherwise draw from a lot currently locked will not be able to use that lot, and should account for locked/unlocked availability accordingly.

Current-Income Withholding at Inflow

🚧

Limitation

Austrian law requires withholding on current income (crypto lending interest, DeFi liquidity mining, mining, and staking-to-validate income) at the moment of inflow, at FMV. Taxbit's Austria transaction handling does not currently implement this: only staking-reward, airdrop, payment-goods, and payment-services income subtypes are accepted, and none of them trigger withholding at inflow. If your platform has current-income activity that Austrian law requires withholding on, you must calculate and withhold that amount outside Taxbit until this ships.

Internal Transfers

🚧

Limitation

Austria-configured accounts currently reject transfer and internal-transfer transaction types. Please reach out to Taxbit support if you need assistance with internal transfer type transactions.

Disentanglement Taxation (Exit Tax)

🚧

Limitation

Austrian law treats the cessation of Austrian tax residency as a deemed disposal of all crypto held, valued at FMV on the date of notification. Taxbit does not currently support this; customers must handle exit-tax obligations for departing Austrian tax residents entirely outside Taxbit until this ships.

NFTs Are Not Supported

Taxbit's Austria implementation does not support NFTs on either side of any transaction. A crypto-to-NFT swap should be expected to behave per the non-qualifying-asset carve-out (a taxable disposal of the crypto leg), not as an NFT acquisition with any particular cost-basis tracking.