Responsibility Matrix
The table below defines the boundary between what Taxbit handles and what the integrating customer is responsible for.
| Area | Taxbit | Customer |
|---|---|---|
| Transaction ingestion | Receives and processes transaction data via the Transactions API | Constructs and submits transaction payloads with correct FMV, timestamps, account IDs, and a supported transaction type/subtype |
| FMV / pricing data | Not provided | Must supply EUR FMV for every asset at the time of each transaction |
| Account / Inventory tracking | Maintains per-user inventory lots across all four pools (Old Stock, Known, User-Basis, Missing Basis) | Identifies account-to-user mapping. Sets disposition_method to AUSTRIA |
| Gain/loss calculation | Calculates net realised gain or loss per disposal event per pool; returns pool-tagged gain_type rows | Queries the Gains and Withholding APIs at the time of each disposal to retrieve calculated amounts |
| KESt withholding amount | Returns the calculated withholding amount (year-to-date target and per-transaction delta) via the dedicated Withholding API | Polls the Withholding API; reconciles its own actual withheld balance against summary.year_to_date_balance |
| Old Stock identification and calculation | Fully automated: identifies Old Stock by acquisition date, disposes FIFO, excludes from withholding, still reports gain for record-keeping | Must supply accurate acquisition dates |
| Missing cost basis handling | Applies the 50% rule automatically; tracks separately | Should prompt users to supply missing acquisition data before disposal, where possible |
| User-provided cost basis | Accepts and stores user-entered acquisition data in a dedicated pool | Provides UI/UX for users to enter historical acquisition information; submits via Taxbit's API |
| Loss-compensation regime | Compensated (individual) and non-compensated (joint/business/trust) formula logic is live for all accounts | Provide the correct account_owner_type when setting up user accounts |
| Current-income (lending, DeFi liquidity mining, mining, or staking-to-validate) withholding | Not implemented | Must not submit these as Austria income transactions expecting inflow withholding; handle any such income's withholding obligation outside Taxbit until this ships |
| Internal transfers | Rejects transfer/internal-transfer transaction types for Austria accounts | Defer until supported |
| Disentanglement / exit taxation (Merkposten) | Not implemented | Must handle exit-tax obligations for departing users entirely outside Taxbit |
| Fund diversion (withholding execution) | Not applicable — Taxbit is a calculation engine only | Fully responsible. Must design an execution layer to hold withheld amounts before releasing net proceeds to the user |
| Custody of withheld funds | Not applicable — Taxbit is a calculation engine only | Fully responsible. Must maintain a segregated custody solution for withheld amounts |
| BMF remittance (Form KA1) | Form completion coming soon | Fully responsible for filing Form KA1 via FinanzOnline by February 15 |
| User Tax Report | Provides tax reports (accessible via S3, API, or manual download) | Fully responsible for issuing Tax Reports to users by March 31 |
| User residency identification | Offers a separate Self-Cert SDK to aid residency identification | Fully responsible. Must identify Austrian tax residents via KYC or Self-Cert and apply the Austria configuration only to those accounts |
| Exemption management | Not implemented | Fully responsible for collecting and validating exemption declarations from eligible users |
| Off-platform transfer notifications | Not applicable | Responsible for notifying receiving custodians of acquisition cost and date; filing E27-6 with the tax office where required |
Updated about 1 hour ago