Closing, locking and re-opening accounting periods

You can close an accounting period, for example a particular month or year. A closed period is a candidate for sign off. You can re-open a closed period if adjustments are required.

You can lock a period that has been signed off. While it is possible to re-open a locked period, this would likely be unusual.

There is no functional difference between closing and locking a period in LUSID. However, it is expected that you would assign different permissions to these operations, so that only a privileged user could lock a period.

Understanding the implications of closing (or locking) a period

Imagine we have a GBP-denominated transaction portfolio holding UK equities. There is just one transaction in January 2024: a purchase of 100 BP shares @ £10 per share = £1,000 on 15 January, trading and settling at the same time for simplicity.

Note: This example uses the GetJournalEntryLines API to demonstrate the impact of period closing but all the information applies equally to the GetTrialBalance API.

31 January 

At EOD on 31 January we call GetJournalEntryLines for the ABOR providing an accounting view of this portfolio between 1 January and 31 January. We see the following two LusidTransaction entries dated 15 January (note LusidValuation entries recording unrealised gain/loss are filtered out for simplicity): the first a debit of £1,000 posted to the 1-Investments account, and the second a reciprocal credit of -£1,000 posted to the 2-Cash account:

1 February

On 1 February, while reviewing the January accounts, we spot a mistake: the number of BP shares purchased on 15 January was 99, not 100. We correct the original transaction in the usual way and call GetJournalEntryLines again; the entries show the change in cost to £990:

3 February

On 3 February we decide to close the January period. To do this, we call the ClosePeriod API, specifying:

  • An effectiveAt closing date of 31 January 2024 at one second to midnight.

  • A queryAsAt date of now, the time at which we decide to close the January period: 3 February at midnight. Since LUSID is a bitemporal system, all data inputs contributing to journal entry lines in January are checkpointed to this exact moment in time. Note you can set effectiveAt and queryAsAt to the same datetime if you wish.

LUSID creates an accounting diary entry for the closed period. We can call the ListDiaryEntries API to examine it:

Note the following:

  • LUSID automatically assigns a unique diaryEntryCode of 20230131 to the diary entry. We can use this code to refer to the closed period in future.

  • The previousEntryTime is the system minimum datetime. This is because January is the first closed period for this ABOR. If a period had been closed before (for example December), this would be the effectiveAt date of that period.

  • The status is Estimate to indicate that the period is closed rather than locked (in which case the status would be Final).

  • The type is PeriodBoundary to indicate that the datetime 2024-01-31 23:59:59 is simultaneously the end of the January period and the start of the February period.

5 February

On 5 February, with January now closed, we spot another mistake: the number of BP shares purchased on 15 January was actually 101, not 99. We re-correct the original transaction and then call GetJournalEntryLines again, this time with the unique code of the diary entry; the entries show the change in cost to £1,010:

However, the January period is closed. This change shouldn't be registered. And it isn't, when GetJournalEntryLines is in AccountingDate mode. By default, GetJournalEntryLines is in ActivityDate mode, as per the picture above, and closed or locked periods are ignored entirely to report the current state of the system.

If we call GetJournalEntryLines with the code of the diary entry in AccountingDate mode instead, the entries show a cost of £990, which reflects the state of the system at the queryAsAt time of the diary entry: 3 February at midnight. In other words, the correction made on 1 February before the close is included, but the re-correction made on 5 February after the close is not:

6 February

On 6 February we call GetJournalEntryLines in AccountingDate mode with just a datetime as the end date (not the code of the diary entry) to see the current state of the system:

Note the following:

  • The activityDate column values are the same, but the accountingDate values differ.

  • Entries 1 and 2 reflect the state of the system at the queryAsAt time of the closed period: 3 February at midnight. The correction made on 1 February is incorporated to show the cost of £990.

  • Entry 3 reverses entry 1 at the period boundary, 2024-01-31 23:59:59. Note due to the way period boundaries work for corrections, these actually occur in the currently-open February period. Likewise, entry 5 reverses entry 2 at the period boundary.

  • Entries 4 and 6 reflect the current state of the system. The re-correction made on 5 February is incorporated at the period boundary to show the current cost of £1,010.

In summary, any corrections you make to a closed (or locked) period are incorporated in the next period. You can audit these corrections by calling GetJournalEntryLines in AccountingDate mode.