When you create a fund using the LUSID web app you can choose to designate trade expenses as either Capital or Expense:
Imagine a simple scenario in which we purchase one BP share for £100 and pay broker commission of £5, for a total consideration of £105:
If we choose Capital, the cost of our BP position is £105 and so (ignoring all other factors) P&L is -£5.
If we choose Expense, the cost is £100 and P&L is £0.
Setting up LUSID for different expense treatments
There is no built-in functionality in LUSID for distinguishing between different trade expense treatments. Getting the end result you want is a product of booking transactions that incur expenses in a certain way and applying a specialised transaction type.
Booking a purchase transaction
We can call the BatchUpsertTransactions API to book the example trade for one BP share above as follows:
curl -X POST 'https://<your-domain>.lusid.com/api/api/transactionportfolios/MyScope/MyCode/transactions/$batchUpsert?successMode=Partial'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"transactionRequest-1": {
"transactionId": "Txn-001",
"type": "BuyTradeExpenses",
"instrumentIdentifiers": {"Instrument/default/Figi": "BBG000C05BD1"},
"transactionDate": "2024-10-01T00:00:00.0000000+00:00",
"settlementDate": "2023-10-03T00:00:00.0000000+00:00",
"units": 1,
"transactionPrice": {"price": 100, "type": "Price"},
"totalConsideration": {"amount": 105, "currency": "GBP"},
"properties": {
"Transaction/MyProperties/BrokerCommission": {
"key": "Transaction/MyProperties/BrokerCommission",
"value": {
"metricValue": {
"value": 5, "unit": ""
}
}
}
}
}'
Note the following:
The transaction
type
isBuyTradeExpenses
; see this section below.The number of
units
is 1.The
transactionPrice.price
is 100. LUSID uses this field to automatically calculate gross consideration as total consideration before fees.The
totalConsideration.amount
is the cost with fees included: £105.A
Transaction/MyProperties/BrokerCommission
custom property is added to the transaction to record the cost of fees: £5.
We can call the CreatePropertyDefinition API to pre-define the Transaction/MyProperties/BrokerCommission
custom property as follows:
curl -X POST 'https://<your-domain>.lusid.com/api/api/propertydefinitions'
-H 'Authorization: Bearer <your-API-access-token>'
-H 'Content-Type: application/json-patch+json'
-d '{
"domain": "Transaction",
"scope": "MyProperties",
"code": "BrokerCommission",
"displayName": "Broker commission",
"dataTypeId": {"scope": "system", "code": "number"},
"lifeTime": "Perpetual",
"constraintStyle": "Property",
"propertyDescription": "Recording broker commission for transactions"
}'
Creating a specialised transaction type
When we create a fund, LUSID stores our choice of Trade expenses using the Portfolio/default/ExpenseTreatment
system property:
If we choose Capital, LUSID sets the value of the system property to
Capitalised
.If we choose Expense, LUSID sets the value to
NonCapitalised
.
If we choose neither, LUSID does not set the system property (that is, does not add it to the portfolio).
We can use this information to create a conditional transaction type that applies different movements and thus confers a different economic impact on transactions belonging to the type:
Value of system property | Movements to apply | Explanation of movements |
---|---|---|
|
|
|
|
|
We can call the SetTransactionType API to create a conditional BuyTradeExpenses
transaction type in the default
scope and source as follows:
curl -X PUT 'https://<your-domain>.lusid.com/api/api/transactionconfiguration/types/default/BuyTradeExpenses?scope=default'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"aliases": [
{
"type": "BuyTradeExpenses",
"description": "Conditional transaction type for different trade expense treatments",
"transactionClass": "Longer",
"transactionRoles": "AllRoles",
"isDefault": false
}
],
"movements": [
{
"name": "Movement1",
"condition": "Portfolio.Properties[Portfolio/default/ExpenseTreatment] eq 'Capitalised' or Portfolio.Properties[Portfolio/default/ExpenseTreatment] not exists",
"movementTypes": "StockMovement",
"side": "Side1",
"direction": 1
},
{
"name": "Movement2",
"condition": "Portfolio.Properties[Portfolio/default/ExpenseTreatment] eq 'NonCapitalised'",
"movementTypes": "StockMovement",
"side": "Side1NonCapitalised",
"direction": 1
},
{
"name": "Movement3",
"condition": "Portfolio.Properties[Portfolio/default/ExpenseTreatment] eq 'NonCapitalised'",
"movementTypes": "Carry",
"side": "Side1BrokerCommission",
"direction": -1
},
{
"name": "Movement4",
"movementTypes": "CashCommitment",
"side": "Side2",
"direction": -1
},
],
"calculations": [
{
"type": "Txn:GrossConsideration"
}
]
}'
Note the following:
Movement1
,Movement2
andMovement3
have acondition
statement and so only apply to matching transactions.Movement4
has nocondition
and so applies to every transaction belonging to the type.Movement1
andMovement4
use the built-in sidesSide1
andSide2
.Movement2
andMovement3
use custom sides which must be pre-defined; see below.The
Txn:GrossConsideration
calculation automatically calculates gross consideration as total consideration before fees.
Creating custom sides
We can call the SetSideDefinition API to create the custom Side1NonCapitalised
and Side1BrokerCommission
sides in the same default
scope as the BuyTradeExpenses
transaction type. Note both sides must exist before the transaction type itself is created.
|
|
---|---|
|
|
This is the same as | This is the same as |
Comparing the impact of different expense treatments
In the examples below, we assume no price movement has occurred and the value of one BP share is still £100. We also assume the transaction, settlement and portfolio currencies are all GBP, so there is no FX gain/loss.
On holdings
Note the different cost.amount for BP:
On valuation
Note the different PnL:
On A2B reports
Note one treatment has CapGains while the other has Carry:
On journal entry lines
One treatment includes journal entry lines with a sourceType of LusidValuation
while the other just has LusidTransaction
:
On trial balance
Both ledgers balance but the DR and CR amounts differ: