What is an accounting diary entry?

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' 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:

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

Estimate

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.

Final

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

 

ReOpenPeriods()

 

20240630

20240731

 

ReOpenPeriods()

20240630

 

20240630

20240731

 

ReOpenPeriods("20240630")

 

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

 

DeleteValuationPoint("30June2024-5pm")

 

30June2024-5pm

31July2024-5pm

 

DeleteValuationPoint("31July2024-5pm")

30June2024-5pm

 

30June2024-5pm

31July2024-5pm

 

DeleteValuationPoint("30June2024-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.