An accounting diary entry is a point in time at a particular location, for example Tuesday 30 June 2024 5pm UTC.
A diary entry belongs to an ABOR and must have a unique code, for example 30June2024-5pm
.
There are different types of diary entry in LUSID, each with its own creation mechanism, behaviour and implications.
Using diary entries in operations
You can use a diary entry to mark the start and/or end of a particular operation, for example generating a trial balance or valuing a fund. See the sections below for which type of diary entry can perform which operations.
For example, when you value a fund using the GetValuationPointData API you can set the end.diaryEntry
field to the diary entry code of a ValuationPoint
:
curl -X POST 'https://<your-domain>.lusid.com/api/api/funds/Abor/Growth/valuationpoints'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"end": {
"diaryEntry": "30June2024-5pm"
}
}'
You can value a fund without a diary entry by setting the end.Date
field to a valid LUSID datetime instead, but note LUSID behaves differently:
curl -X POST 'https://<your-domain>.lusid.com/api/api/funds/Abor/Growth/valuationpoints'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"end": {
"date": "2024-06-30T17:00:00Z"
}
}'
Understanding effective and as at datetimes
Since LUSID is bitemporal, a diary entry has two datetimes:
The
effectiveAt
field represents the point in time at which you want to perform an operation, for example valuing a fund.The
queryAsAt
field can be set to the same datetime, but typically represents a subsequent time to allow for late-entered data, or changes and corrections to existing data.
For example, you might specify an effectiveAt
of 5pm to value a fund using all the data in LUSID effective-dated up to 5pm, but a queryAsAt
time of 7pm to allow two hours for all such data to flow in.
You can omit either field to use the current system datetime.
Auditing diary entries
You can:
Call the ListDiaryEntries API to retrieve diary entries for a particular ABOR, perhaps with a filter to retrieve just entries of a particular type, for example
type eq 'PeriodBoundary'
ortype neq 'Other'
.Navigate to the Financial Reporting > Accounting Diary dashboard in the LUSID web app to retrieve diary entries for a particular ABOR.
If you have a Luminesce license, write a SQL query using the Lusid.AccountingDiary provider. This mechanism allows you to retrieve diary entries for every ABOR.
Period boundary diary entries
A diary entry with a type of PeriodBoundary
signifies a closed or locked accounting period. When you close or lock a period (there is no functional difference between these two operations), LUSID persists the underlying data so the result is always reproducible. More information.
You can specify a PeriodBoundary
diary entry as the end date when you call the:
GetTrialBalance API to generate a trial balance.
GetJournalEntryLines API to audit journal entry lines.
LUSID incorporates all economic activity since the preceding PeriodBoundary
, or since portfolio inception if this is the first closed/locked period.
The implication of specifying a PeriodBoundary
for either API is that any retrospective changes or corrections made to underlying data are incorporated in the next period. Data in a closed or locked period is never changed.
LUSID creates a PeriodBoundary
diary entry for you when you call the ClosePeriod API. You do not explicitly create one yourself. You can either nominate a diary entry code or have LUSID generate one for you using the date of the API request (so for example 20240630
for a period you close on 30 June 2024).
A PeriodBoundary
diary entry has a status of either Estimate
or Final
:
Status | Status set by… | Behaviour |
| ClosePeriod API | There is no functional difference between these two statuses. However, it is expected that you would assign different permissions to these APIs, so that only a privileged user could lock a period. |
| LockPeriod API |
Working with multiple periods
A period must be closed before it can be locked. The next period cannot be closed if the preceding period is still open.
Scenarios | June | July | Rest of year → | Explanation |
Possible | Open | No closed periods | ||
Closed | Open | One closed period | ||
Locked | Open | One locked period | ||
Closed | Closed | Open | Multiple closed periods | |
Locked | Locked | Open | Multiple locked periods | |
Locked | Closed | Open | Mix of locked/closed periods (providing closed follows locked) | |
Not possible | Open | Closed | Open | Closed period must follow closed or locked |
Closed | Locked | Open | Locked period must follow locked |
Re-opening periods
You cannot explicitly delete a PeriodBoundary
diary entry. Instead, you call the ReOpenPeriods API to re-open one or more closed or locked periods:
If you specify a diary entry code, that period (whether closed or locked) and any subsequent periods are re-opened.
If you do not specify a diary entry code, the most recent period (whether closed or locked) is re-opened.
For example:
Before | Action | After | ||||
June | July | Rest of year → | June | July | Rest of year → | |
20240630 |
|
|
| |||
20240630 | 20240731 |
|
| 20240630 |
| |
20240630 | 20240731 |
|
|
|
Valuation point diary entries
A diary entry with a type of ValuationPoint
is used to value a fund. Note although a ValuationPoint
belongs to the underlying ABOR, it can be operated on via the parent fund.
Publishing a fund valuation is a workflow with checks and balances. You call the UpsertDiaryEntryTypeValuationPoint API (or the Lusid.Fund.ValuationPoint.Writer provider if you have a Luminese license) to explicitly create a ValuationPoint
diary entry, specifying a unique diary entry code such as 30June2024-5pm
. LUSID assigns an initial status of Estimate
.
You then call the GetValuationPointData API (or the Lusid.Fund.ValuationPointData provider) with the diary entry code as the end date to calculate an estimate of fund GAV, NAV and other pricing data. LUSID incorporates all economic activity since the preceding ValuationPoint
, or since fund inception if this is the first valuation.
You then call the AcceptEstimateValuationPoint API to accept the estimate (this operation cannot be performed using Luminesce). If no retrospective changes or corrections have been made to underlying data in the meantime, LUSID automatically sets the status to Final
and:
Persists the data, so the result is always reproducible.
Generates accrual and payment transactions to record any fees added to the fund.
However, if LUSID detects changes, the status is set to Candidate
instead, enabling you to check the result again. More information.
Working with multiple valuations
The preceding valuation must be finalised before the next valuation can begin.
Scenarios | June | July | Rest of year → | Explanation |
Possible |
| No valuations | ||
Estimate |
| One estimate valuation | ||
Final |
| One finalised valuation | ||
Final | Estimate |
| Mix of estimate/finalised (providing estimate follows finalised) | |
Final | Final |
| Multiple finalised valuations | |
Not possible |
| Estimate |
| Estimate cannot follow no valuation |
Estimate | Estimate |
| Estimate cannot follow estimate | |
Estimate | Final |
| Finalised must follow finalised |
Deleting a diary entry
You can delete a ValuationPoint
diary entry using the DeleteValuationPoint API (or the Lusid.Fund.ValuationPoint.Writer provider):
If you specify the diary entry code of the most recent
ValuationPoint
(whatever its status), just that diary entry is deleted.If you specify the diary entry code of an earlier
ValuationPoint
, that diary entry and all subsequent entries are deleted (whatever their status).
For example:
Before | Action | After | ||||
June | July | Rest of year → | June | July | Rest of year → | |
30June2024-5pm |
|
|
| |||
30June2024-5pm | 31July2024-5pm |
|
| 30June2024-5pm |
| |
30June2024-5pm | 31July2024-5pm |
|
|
|
Other diary entries
A diary entry of type Other
has no special behaviour in LUSID. It can simply be used as a convenient way of referencing a particular datetime.
For example, you could call the AddDiaryEntry API (or the Lusid.AccountingDiary.Writer provider if you have a Luminese license) for a particular ABOR to create a diary entry representing Tuesday 30 June 2024 5pm UTC, specifying a unique diary entry code in the URL:
curl -X POST 'https://<your-domain>.lusid.com/api/api/abor/Abor/Growth/accountingdiary/30June2024-5pm'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"effectiveAt": "2024-06-30T17:00:00Z",
"queryAsAt": "2024-06-30T17:00:00Z"
}'
In the response, LUSID confirms the type is Other
and the status is Undefined
:
{
"aborId": {
"scope": "Abor",
"code": "Growth"
},
"diaryEntryCode": "30June2024-5pm",
"type": "Other",
"status": "Undefined",
"effectiveAt": "2024-06-30T17:00:00.0000000+00:00",
"queryAsAt": "2024-06-30T17:00:00.0000000+00:00",
"previousEntryTime": "0001-01-01T00:00:00.0000000+00:00",
...
}
You can then call the GetValuationPointData
, GetTrialBalance
or GetJournalEntryLines
API with an end.diaryEntry
of 30June2024-5pm
to generate an ad hoc result, without data persistence or any other implication.
Note you cannot currently delete a diary entry of type Other
.