An accounting diary entry is a point in time at a 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' or type 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:

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.

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:

Valuation point diary entries

A diary entry with a type of ValuationPoint is used to value a fund. Note that 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.

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:

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.