Accounting is a primary function of BFS and can be configured in a dynamic way to support internal accounting standards. The transaction dimension called Accounting Transactions exist in the same way as Trade Transactions and Settlement Transactions.
A default chart of accounts could look like this.
Chart of accounts
16 - Short term receivables
1601 - Receivables on customers
1602 - Receivables on counterparty ExecutionPartner1
1603 - Open trades for own book with ExecutionPartner1
1604 - Receivables on counterparty FundMarketplace1
1605 - Open trades with FundMarketplace1
1650 - Cash receivables from client deposits
19 - Cash at bank
1930 - Company business account (BANK1-8700)
1940 - Client cash account with ExecutionPartner1
1941 - Account with FundMarketplace1 (FM1-8732)
1942 - Segregated Account with Bank1 (BANK1-8742)
1943 - Segregated Account with Bank1 (BANK1-8743)
1944 - Non Segregated Accoount with Bank1 (BANK1-8744)
24 - Short term liabilities
2401 - Liabilities to customers from sales made at ExecutionPartner1
2402 - Liabilities to customers regarding FundMarketplace1
2450 - Counterparty liabilities (Liabilities to ExecutionPartner1)
2451 - Cash liabilities for account holders (customers)
2460 - Liabilities to counterparty FundMarketplace1
2461 - Cash liabilities from client withdrawals
25 - Tax liabilities
2520 - Tax liabilities on behalf of clients
30 - Income
3030 - General commission
40 - Costs
4030 - Transaction costs
EP1-8722 - The account for the house at ExecutionParnter1
FM1-8732 - The account for the house at FundMarketplace1
BANK1-8700 - The business account of the company
BANK1-8742 - The segregated bank account used for client assets
BANK1-8743 - The segregated bank account used for reserved tax liabilities
BANK1-8744 - The non segregated bank account used for client assets
BANK2-9000 - The bank account used for the house to manage result
The XML-configuration below shows the MoneyTransfer settings as an example.
<BusinessTransactionMappingRule transactionType="MoneyTransfer"> <Filter>
<PropertyValue property="AmountAsset1" operator="GreaterThan" value="0"/>
<AccountTransaction dimension="T" amountType="AmountAsset1" assetType="Asset1" factor="1" transactionDate="TradeDate" xsi:type="AccountDefault" />
<AccountTransaction dimension="A" amountType="AmountAsset1" assetType="Asset1" factor="-1" transactionDate="TradeDate" xsi:type="AccountSelection" accountTypeKey="AccountingAccount" accountNo="2451" />
<AccountTransaction dimension="A" amountType="AmountAsset1" assetType="Asset1" factor="1" transactionDate="TradeDate" xsi:type="AccountSelection" accountTypeKey="AccountingAccount" accountNo="1650" />
The accounting transactions are defined by the setting dimension="A", which means the accounting dimension. The next property is amountType. An account transaction can be comprised of two assets, in the configuration file these are named Asset1 and Asset2 with corresponding AmountAsset1 and AmountAsset2. For the sake of this example the term Leg1 and Leg2 are going to be used to define the two sides of the transaction.
If one asset is of the type Cash this asset will exist as the first Leg. In case of a deposit of funds there will only be one Leg of the transaction and Leg2 will be empty (NULL). If both Legs of the transaction is comprised of Cash then the first Leg will be the asset that is being reduced (FromAsset). If the transaction only consists of one Leg and that Leg is not a Cash-asset then Leg1 will be empty.
The next property is the factor that is widely used for the accounting transaction configuration. In the XML-example above AmountAsset1 is a positive number and in the accounting transaction there should be a negative value applied to accounting account 2451. To acheive this the factor is set to -1 and AmountAsset1 is then multiplied with this factor. The factor can be used to multiply any value for the account transactions, for example if fees should be split 50 % each to two accounts the factor could be set to 0.5.
Next up is transactionDate that determines the date that should be used for the account transaction. The available options are:
If TradeDate, SettlementDate or ValueDate is used the accounting transaction will obtain the same date as the corresponding setting for the BusinessTransaction.
The CurrentAccountingDate would be used if batched accounting is being used where all accounting transactions are qued during a certain day and then processed as a batch at midnight resulting in aggregation of accounting account transactions. In the XML-example above there will, by default, be created two account transactions in the accounting account 1650. With batched accounting however there would be only 1 transaction made or 0 transactions if the first accounting transaction had the same amount as the second. This would in turn reduce the loan on any external accounting systems where accounting files (SIE-files in Sweden) are exported.
The property type defines which account selection should occur for the account transaction. Two properties can be selected:
If AccountDefault is selected the account transaction will be applied to the account that was used in the BusinessTransaction. This will usually equal to the SystemAccount being used. If AccountSelection is selected the properties accountTypeKey and accountNo is required.
The accountTypeKey can be any of the account types defined in the BFS instance like the ones listed below.
The accountNo is the identifier of the account and depending on the account type rules it does not have to be a number but can instead be a text string.