--- title: "What is a transaction type calculation?" slug: "what-is-a-transaction-type-calculation" tags: ["calculation", "ttpr"] updated: 2026-07-07T12:42:43Z published: 2026-07-07T12:42:43Z canonical: "support.lusid.com/what-is-a-transaction-type-calculation" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.lusid.com/llms.txt > Use this file to discover all available pages before exploring further. # What is a transaction type calculation? A *calculation* is an optional component of a [transaction type](/v1/docs/what-is-a-transaction-type) that triggers additional functionality for every transaction belonging to that type. A calculation: - Must have a `type` that triggers a particular LUSID function. - Can have a `side` to pass extra information to the function. - Can have a `formula` that drives the function. Only one instance of any calculation is allowed per transaction type except `Fee`. > **Note**: The result of a calculation can be examined on an [output transaction](/v1/docs/input-and-output-transactions). ## `Fee` calculation - Requires `side`: NO - Requires `formula`: NO Calculates a particular transaction fee amount (for example, an exchange fee) according to a formula, and determines whether it is [capitalised or expensed](/v1/docs/transaction-fees-and-capitalisation). You can add as many `Fee` calculations to a transaction type as there are transaction fees to calculate. For each: - The `transactionFeeId` must reference the scope and code of an existing [transaction fee type](/v1/docs/how-do-i-create-a-transaction-fee-type). - `transactionFeeCapitalisation.capitalisation` must be either `Capitalised`, `NonCapitalised` or `Conditional`. - If `Conditional`, you must specify a `transactionFeeCapitalisation.capitalisedCondition` that capitalises the fee if the expression evaluates to true; otherwise, it is expensed. You can use LUSID [filter syntax](https://support.lusid.com/v1/docs/filtering-information-retrieved-from-lusid) to include any field or property from a portfolio or transaction in the condition, including the transaction’s underlying instrument type. You can optionally chain expressions using the `and` and `or` operators if desired. | **Example** | **Fee is capitalised for…** | | --- | --- | | `capitalisedCondition = "Transaction.Instrument.InstrumentDefinition.InstrumentType eq 'Equity'"` | Transactions in equities | | `capitalisedCondition = "Transaction.totalConsideration.amount gt 2000"` | Transactions with a total consideration of more than 2000 | | `capitalisedCondition = "Transaction.units gte 100 and Transaction.Properties[Transaction/Broker/Commission] exists"` | Transactions of 100 units or more where broker commission is recorded | | `capitalisedCondition = "Portfolio.baseCurrency eq 'GBP'"` | Transactions in GBP portfolios | | `capitalisedCondition = "Portfolio.Properties[Portfolio/Manager/Name] in 'John Doe', 'Jane Doe'"` | Transactions in portfolios managed by John Doe or Jane Doe | | `capitalisedCondition = "Transaction.units gt 100 and Portfolio.created gte 2024-01-01"` | Transactions of more than 100 units in 2024+ portfolios | The result is stored in the output property nominated by the transaction fee type, and automatically added to the output transaction. ```json "calculations": [  {    "type": "Fee",    "transactionFeeId": {      "scope": "TradeFees",      "code": "Broker"    },    "transactionFeeCapitalisation": {      "capitalisation": "Capitalised"    }  },  {    "type": "Fee",    "transactionFeeId": {      "scope": "TradeFees",      "code": "Exchange"    },    "transactionFeeCapitalisation": {      "capitalisation": "Conditional",      "capitalisedCondition": "Transaction.units gt 20 or Transaction.transactionCurrency neq 'USD'"    }  } ] ``` ## `TaxAmounts` calculation - Requires `side`: YES - Requires `formula`: NO Calculates tax amounts due. [More information](/v1/docs/tax-calculations). Note the following: - The result is stored in the custom output property nominated by the tax rule set, and automatically added to the output transction. - The side is required to pass information about the underlying instrument to the tax calculation engine. [See an example](/v1/docs/calculating-dividend-tax-and-reporting-it-as-a-separate-cash-balance#creating-a-custom-transaction-type-to-trigger-and-process-tax-calculations). - This calculation is ignored for a particular transaction if no tax rule set can be found to apply. ```json "calculations": [  {    "type": "TaxAmounts",    "side": "Side1"  } ] ``` ## `TransactionSequence` calculation - Requires `side`: NO - Requires `formula`: YES Determines the order in which transactions are processed relative to transactions belonging to other transaction types if all are loaded into LUSID with identical *effective at* datetimes. [More information](/v1/docs/input-and-output-transactions#changing-the-order-in-which-output-transactions-are-generated). The `formula` field must contain, or resolve to, an integer. The lower the number, the higher the priority in the processing queue. A formula can contain the following components: - A constant value, for example `"1"` or `"98765"`. - A transaction field, for example `"Transaction.units"`, or property or derived property, for example `"Properties[Transaction/default/GrossConsideration]"`. - An instrument field, for example `"Instrument.InstrumentDefinition.InstrumentType"`. For example, you could specify a `TransactionSequence` formula of `"2"` for a `Buy` transaction type: ```json "calculations": [  {    "type": "TransactionSequence",    "formula": "2"  } ] ``` …and a `TransactionSequence` formula of `"1"` for a `Sell` transaction type: ```json "calculations": [  {    "type": "TransactionSequence",    "formula": "1"  } ] ``` This means that if a `Buy` transaction and a `Sell` transaction are loaded into LUSID with identical *effective at* datetimes then the `Sell` transaction is processed first, even if it is loaded second in the same request (and therefore has a slightly later *as at* entry datetime). Note you can use [LUSID derived property formula syntax](/v1/docs/derivation-formulas-part-1-operations-and-allowed-values#if-then-else) to create conditional statements, so for example: ```json "calculations": [  {    "type": "TransactionSequence",    "formula": "If(Instrument.InstrumentDefinition.InstrumentType eq 'Equity') Then 2 Else 3"  } ] ``` ## `Txn:TradeToPortfolioRate` calculation - Requires `side`: NO - Requires `formula`: NO Looks up an exchange rate from the transaction to the portfolio currency in the LUSID Quote Store. [More information](/v1/docs/transactions-and-exchange-rates#looking-up-exchange-rates-dynamically-using-a-recipe). Note the following: - The lookup is performed for the transaction date, not the settlement date (if they are different). - The result is stored in the `Transaction/default/TradeToPortfolioRate` system property. - This calculation is ignored if `Transaction/default/TradeToPortfolioRate` is explicitly added to a particular transaction. ```json "calculations": [  {    "type": "Txn:TradeToPortfolioRate"  } ] ``` ## `Txn:ExchangeRate` calculation - Requires `side`: NO - Requires `formula`: NO Looks up an exchange rate from the transaction to the settlement currency in the LUSID Quote Store. [More information](/v1/docs/transactions-and-exchange-rates#looking-up-exchange-rates-dynamically-using-a-recipe). Note the following: - The lookup is performed for the transaction date, not the settlement date (if they are different). - The result is stored in the `exchangeRate` field. - This calculation is ignored if `exchangeRate` is explicitly set on a particular transaction. ```json "calculations": [  {    "type": "Txn:ExchangeRate"  } ] ``` ## `Txn:Netback` calculation - Requires `side`: NO - Requires `formula`: NO Calculates the cost of the unfounded amount for transactions in instruments of type `LoanFacility`. The result is stored in the `Transaction/default/Netback` system property. Please contact [Technical Support](/v1/docs/how-do-i-use-the-support-centre) for more information. ```json "calculations": [  {    "type": "Txn:Netback"  } ] ``` ## `Txn:NotionalAmount` calculation - Requires `side`: NO - Requires `formula`: NO Calculates notional amount for transactions in instruments of type `Future` and `ContractForDifference`. [More information](/v1/docs/transactions-and-manual-vs-automatic-calculation-of-amounts). Note the following: - For most contracts the calculation is `txn price * txn units * (contract size / scale factor)`. - The calculated amount is in transaction currency, not settlement currency (if they are different). - The result is stored in the `Transaction/default/NotionalAmount` system property. [See an example](https://support.lusid.com/docs/modelling-exchange-traded-futures-and-options-in-lusid#booking-a-transaction-to-establish-a-position). - This calculation is ignored if `Transaction/default/NotionalAmount` is explicitly added to a particular transaction. ```json "calculations": [  {    "type": "Txn:NotionalAmount"  } ] ``` ## `Txn:BondInterest` calculation - Requires `side`: NO - Requires `formula`: NO Calculates accrued interest for transactions in instruments of type `Bond`, `ComplexBond`, `InflationLinkedBond`, `CdsIndex` and `CreditDefaultSwap`. [More information](/v1/docs/transactions-and-manual-vs-automatic-calculation-of-amounts). Note the following: - The calculated amount is in transaction currency, not settlement currency (if they are different). - Accrual is calculated up to settlement date, not transaction date (if they are different). - The result is stored in the `Transaction/default/BondInterest` system property. [See an example](https://support.lusid.com/docs/modelling-exchange-traded-futures-and-options-in-lusid#booking-a-transaction-to-establish-a-position). - This calculation is ignored if `Transaction/default/BondInterest` is explicitly added to a particular transaction*.* ```json "calculations": [  {    "type": "Txn:BondInterest"  } ] ``` ## `Txn:GrossConsideration` calculation - Requires `side`: NO - Requires `formula`: NO Calculates gross consideration as an amount including accrued interest but before fees. [More information](/v1/docs/transactions-and-manual-vs-automatic-calculation-of-amounts). Note the following: - The calculated amount is in settlement currency, not transaction currency (if they are different). - The result is stored in the `Transaction/default/GrossConsideration` system property. - This calculation is ignored if `Transaction/default/GrossConsideration` is explicitly added to a particular transaction*.* ```json "calculations": [  {    "type": "Txn:GrossConsideration"  } ] ``` The calculation depends on the instrument type: | Instrument type | Calculation | Notes | | --- | --- | --- | | `Future`, `ContractForDifference` | For transactions that *increase* a position, LUSID sets the gross consideration to `0`. | The sign of the calculated amount determines whether it is a profit (+ve) or a loss (-ve), regardless of the direction of the transaction. So for example, both `Sell` and `CoverShort`-style transactions have a positive gross consideration if there is a receipt of profit, and a negative gross consideration if there is a payment of loss. [See an example](https://support.lusid.com/docs/modelling-exchange-traded-futures-and-options-in-lusid#booking-a-transaction-to-establish-a-position). | | For transactions that *reduce* a position (that is, move in the opposite direction to the current holding), LUSID calculates the realised gain as follows: `notionalAmount - (notionalCost + variationMargin)` | | `Bond`, `ComplexBond`, `InflationLinkedBond` (but not MBS) | The basic calculation is: `txn units * txn price * exchange rate * (contract size / scale factor)` If the transaction price type is `CleanPrice` or `Price`, bond interest is then added (this is the value of the `Transaction/default/BondInterest` system property, or `0` if it is not set). If the type is `DirtyPrice`, bond interest is *not* added. | [See an example](/v1/docs/modelling-fixed-rate-vanilla-bonds-in-lusid#booking-a-transaction-to-establish-a-position). | | MBS (modelled as special kind of `ComplexBond`) | The basic calculation is: `txn price * txn units * exchange rate * current face` If the transaction price type is `CleanPrice` or `Price`, bond interest is then added (the value of the `Transaction/default/BondInterest` system property, or `0` if it is not set). If the type is `DirtyPrice`, bond interest is *not* added. | [See an example](/v1/docs/modelling-mortgage-backed-securities-in-lusid#booking-a-transaction-to-establish-a-position). | | `CdsIndex`, `CreditDefaultSwap` | The calculation is: `(txn price * txn units) + accrual` Accrual is the value of the `Transaction/default/BondInterest` system property, or `0` if it is not set. | [See an example](/v1/docs/modelling-cds-index-instruments-in-lusid). The transaction price type should be `Price` but you can either specify a par-like Markit price of (for example) `102` or `98` or alternatively a rate, for example `-0.02` or `0.02`. LUSID converts par-like prices to rates using `(100 - txn price) / 100`, so for example `(100 - 102) / 100 = -0.02`. | | All other instrument types | The calculation is: `txn price * txn units * exchange rate * (contract size / scale factor)`. | | ## `DeriveTotalConsideration` calculation - Requires `side`: NO - Requires `formula`: YES Calculates total consideration according to a user-specified formula. Note that LUSID typically expects this to be *after* fees, in contrast with gross consideration which is before fees. [More information](/v1/docs/transactions-and-manual-vs-automatic-calculation-of-amounts). > **Note**: The `totalConsideration.amount` field must be set to `0` on an input transaction for this calculation to occur. It cannot be omitted. The `totalConsideration.currency` field can be set as normal. Note the following: - The calculated amount is in settlement currency, not transaction currency (if they are different). - Typically, you should include both [capitalised and expensed](/v1/docs/transaction-fees-and-capitalisation) fees in the formula, since total consideration impacts the cash side of a transaction. (It is LUSID’s automatic calculation of trade amount that only includes capitalised fees, since this impacts an asset’s cost basis.) - The result is stored in the `totalConsideration.amount` field on an output transaction. [See an example](/v1/docs/transactions-and-manual-vs-automatic-calculation-of-amounts). - This calculation is ignored if `totalConsideration.amount` is set to an amount other than `0` on a particular input transaction*.* For example, for transactions that increase a position you might want to calculate total consideration as gross consideration *plus* fees. Note if you include any other calculations in the formula (such as `Txn:GrossConsideration`) then you must also include them in the transaction type: ```json "calculations": [  {    "type": "DeriveTotalConsideration",    "formula": "Txn:GrossConsideration + Txn:TotalFees"  },  {    "type": "Txn:GrossConsideration"  } ] ``` For transactions that reduce a position you might want to calculate total consideration as gross consideration *minus* fees. ```json "calculations": [  {    "type": "DeriveTotalConsideration",    "formula": "Txn:GrossConsideration - Txn:TotalFees"  },  {    "type": "Txn:GrossConsideration"  } ] ``` Specified on the input transaction. Specified on the input transaction. Defaults to 1 if not explicitly specified in the instrument economic definition. By default, no scale factor is applied. For some instruments, you can scale a price down by specifying a factor: 1. On a market price loaded into the Quote Store (applies just to that price). 2. In the instrument economic definition (applies to every price for that instrument). An explicit scale factor on a price overrides the instrument definition. This defaults to 1 if the settlement (total consideration) and transaction currencies are the same. If not, this can be specified on the input transaction to record the rate from the transaction currency to the settlement currency. This is the value of the `Transaction/default/CurrentFace` system property explicitly added to the input transaction.