Integration Flow

The following steps describe the end-to-end flow for a disposal event that generates a KESt withholding obligation.

Step 1 – Configure the Account

Austria's cost-basis pooling and withholding behavior is driven by the account's disposition method. An account must be configured with the disposition method before you send any transactions for it. For Austria, this must be configured to:

"disposition_method": "AUSTRIA"

This instructs Taxbit to apply the Austrian disposition method and withholding calculations. The disposition method is set at account creation and cannot be switched afterwards. See Create an Account in the API Reference for the full request schema.

Step 2 – Ingest the Transaction

When a taxable disposal event occurs on the platform, submit the transaction to Taxbit immediately.

• transaction_type: e.g., SALE
• asset, quantity: the disposed asset and amount
• proceeds_fmv_eur: EUR value of the disposal proceeds (customer-supplied)
• timestamp: exact UTC time of the disposal
• account_id: user's Taxbit account identifier (must be configured with disposition_method AUSTRIA)

{
  "account_id": "user-12345",
  "timestamp": "2026-04-12T14:32:00Z",
  "transaction_type": "SALE",
  "asset_identifier": { "symbol": "BTC" },
  "quantity": "0.5",
  "proceeds_fmv": { "amount": "18500.00", "currency": "EUR" }
}

Step 3 – Poll the Withholding Endpoint

After submitting the transaction, poll GET /v1/inventory/withholding/austria?account_id={account_id}&transaction_id={external_id} until the transaction block in the response is non-null. Do not release net proceeds to the user until you receive a non-null transaction block.

The response will indicate:

• transaction.change_in_balance — this disposal's signed contribution to the account's year-to-date withholding target. A positive value means additional withholding is owed; a negative value means a credit is due.
• summary.year_to_date_balance — the account's cumulative withholding target for the current Austrian tax year, which the customer reconciles against its own actual withheld balance.

Step 4 – Apply Withholding and Divert Funds

Once transaction.change_in_balance is known for this disposal, the customer's execution layer holds back that amount before releasing net proceeds to the user.

• Net proceeds released to user = gross proceeds − transaction.change_in_balance (when positive)
• Withheld funds must be moved to a segregated custody account.
• A zero or negative change_in_balance means no additional withholding is owed for this transaction (see Step 5 for negative values).

Step 5 – Handle Loss Compensation Credits

When a disposal from the Known Cost Basis pool results in a net loss that reduces the account's year-to-date compensable position, transaction.change_in_balance will be negative. If KESt was withheld on prior gains in the same account this tax year, the CASP must credit back the corresponding amount to the user.

• Credit for this transaction = |transaction.change_in_balance|, when negative.
• Reconcile the customer's actual withheld balance against the updated summary.year_to_date_balance after each transaction; the two should track once credits are applied promptly.

❗️

Important

If cumulative losses result in negative KESt exceeding all prior withholding this tax year, the excess cannot be refunded by the service provider — the user must claim it in their individual tax return. Loss compensation does not carry forward across tax years; the running total resets every January 1 (Europe/Vienna).

Step 6 – Annual Reporting

At year-end, the customer must aggregate all gain, loss, and withholding data to produce Form KA1 for the BMF and individual Tax Reports for users.

• Filing deadline (KA1 + tax deposit): February 15 of the following year.
• User Tax Report issuance deadline: March 31 of the following year.

Taxbit's form-generation tooling is coming soon, and will be documented separately when available.