You can strike a NAV at any time. This means selecting a fund and a particular NAV type, and creating a valuation point (VP) with cut offs to determine the data to include. LUSID then:
Calculates GAV as dealing (subscriptions and redemptions) plus P&L since the previous VP (or from fund inception if this is the first VP).
Calculates NAV as GAV minus accrued fund fees.
Closes the period and pesists associated data so reports are always reproducible.
Note you can strike an ad-hoc NAV without closing a period using a bookmark instead of a VP.
See a list of other financial reports.
Creating a valuation point with a closure date and cut offs
You must create a valuation point that specifies both a closure date and cut offs for the data to include in a NAV calculation.
Note: A new VP always has a status of
Estimate. LUSID does not actually close the period and persist data until you explicitly approve the calculation by setting the status toFinal. See how to do this.
Because LUSID is bitemporal, every data point has two timestamps: an effectiveAt that specifies when it becomes relevant from a business perspective, and an asAt that records when it entered the system.
A valuation point must specify at least two timestamps:
An
effectiveAtthat determines when the period closes, for example just before midnight on 31 January 2024. TheeffectiveAtof every data point you wish to include in the NAV calculation must be prior to this timestamp.A
queryAsAtthat determines a cut off for data entering the system. This can be the same aseffectiveAtor before or after it, but it cannot be in the future (that is, later than the current real-world datetime when the VP is created).
You have the option to exert fine-grained control by additionally specifying the following as at timestamps:
A
holdingsAsAtOverridethat determines a cut off for data impacting holdings in underlying portfolios. This includes changes to instrument definitions, all transactions (whether manually input or automatically generated by LUSID in response to instrument events), settlement instructions for those transactions, and FX rates in the LUSID Quote Store used to calculate holding cost (that is, exchange rates from transaction to settlement and portfolio currencies).A
valuationsAsAtOverridethat determines a cut off for data impacting valuation results for underlying portfolios. This is primarily market data (either prices and FX rates stored in the LUSID Quote Store, or curves and discount factors stored in the LUSID Complex Market Data Store), but can also be custom valuation results stored in the LUSID Structured Result Store.
If you:
Do specify these overrides then
queryAsAtretains control over the cut off for changes to fund settings, such as to the CoA, posting rules, recipes and so on.Do not specify these overrides then LUSID sets them to the same as
queryAsAt, which means all data and settings share the same cut off.
For example, you could call the UpsertDiaryEntryTypeValuationPoint API to create a VP for a fund’s OFFICIAL NAV type as follows:
curl -X POST 'https://<your-domain>.lusid.com/api/api/funds/MyFunds/Growth/valuationpoints?navTypeCode=OFFICIAL'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"diaryEntryCode": "VP-31Jan2024",
"diaryEntryVariant": "Variant1",
"name": "End January 2024",
"effectiveAt": "2024-01-31T23:59:59.999Z",
"holdingsAsAtOverride": "2024-01-31T18:00:00Z",
"valuationsAsAtOverride": "2024-02-01T18:00:00Z",
"queryAsAt": "2024-02-02T18:00:00Z",
}'Note the following:
The
effectiveAtis a millisecond before midnight on 31 January 2024.The
holdingsAsAtOverrideis EOD 31 January (before theeffectiveAt) to reflect the time at which the trades team complete their checks. No trade entered into the system after this time is included, even if it is effective-dated before midnight 31 January.The
valuationsAsAtOverrideis EOD 1 February to allow extra time for market data to flow into LUSID.The
queryAsAtis EOD 2 February to allow extra time for the fund accounting team to make changes to posting rules.The
diaryEntryVariantfield is optional but naming each variant is useful should you create more than one (see below).
Call the ListValuationPointsOverview API to preview the NAV calculation using the data included by the various as at timestamps. Note the status is set to Estimate (here the API response is transformed to a table for clarity):

Creating multiple variants of the same estimate
You have the option to create variants of an Estimate valuation point with different as at timestamps.
Note: You can make any of the as at timestamps different, but all variants must share the same
effectiveAt.
You can then compare variant NAV calculations and decide which one to finalise.
To create a variant of an existing VP, call the UpsertDiaryEntryTypeValuationPoint API and specify the same diaryCode but a different diaryEntryVariant.
For example, you could create three variants with different queryAsAt, holdingsAsAtOverride and valuationsAsAtOverride timestamps, and call the ListValuationPointsOverview API to compare the NAV calculations:

Breaking down the NAV calculation
The easiest way to see a breakdown of the NAV calculation is to navigate to Fund Accounting > Fund Grid in the LUSID web app.
Note: Alternatively, call the GetValuationPointData API, or write a SQL query using the Lusid.Fund.ValuationPointData provider.

Adjusting the NAV calculation by promoting additional activity
You can explicitly promote discrete items of economic activity into an Estimate VP that failed to make the cut offs but you wish to include anyway. These can be new or updated:
Transactions (these have an activity adjustment type of
PortfolioTransaction)Quotes (coming soon)
Instrument definitions (coming soon)
Settlement instructions (coming soon).
To do this, call the UpsertNavActivityAdjustments API with a list of adjustments, for example:
curl -X POST 'https://<your-domain>.lusid.com/api/api/funds/MyFunds/Growth/navAdjustment?valuationPointCode=31Jan2024&navTypeCode=Daily&valuationPointCodeVariant=Variant2'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '[
{
"navActivityAdjustmentType": "PortfolioTransaction"
"asAt": "2024-02-03",
"portfolioScope": "MyPortfolioScope",
"portfolioCode": "MyPortfolioCode",
"transactionId": "Txn05",
}
]'fund_api = lusid_api_factory.build(lusid.api.CheckDefinitionsApi)
activity_adjustment_request = [
lm.PortfolioTransaction(
navActivityAdjustmentType="PortfolioTransaction",
asAt="2024-02-03",
portfolioScope = "MyPortfolioScope",
portfolioCode = "MyPortfolioCode",
transactionId = "Txn05"
)
]
try:
activity_adjustment_response = fund_api.upsert_nav_activity_adjustments(
scope = "MyFunds",
code = "Growth",
nav_type_code="Daily",
valuation_point_code = "31Jan2026",
valuation_point_code_variant = "Variant2",
nav_activity_adjustment = activity_adjustment_request
)
except lusid.ApiException as e:
print(e)Note here the asAt date must be on or after the entry date of the transaction into LUSID. It is required to distinguish between multiple updates to the same transaction (if any), so in this example if Txn05 has been updated twice, on 1 February and 2 February, then specifying 3 February as the asAt date causes LUSID to select the most recent change.
Finalising an estimate to officially close a period and persist data
To close a period and persist associated data, call the AcceptEstimateValuationPoint API and specify the diaryEntryCode of an Estimate VP.
If you have multiple variants, make sure to specify the diaryEntryVariant of the one to finalise; all other variants are destroyed. For example:
curl -X POST 'https://<your-domain>.lusid.com/api/api/funds/MyFunds/Growth/valuationpoints/$acceptestimate'
-H 'Content-Type: application/json-patch+json'
-H 'Authorization: Bearer <your-API-access-token>'
-d '{
"diaryEntryCode": "VP-31Jan2024",
"diaryEntryVariant": "Variant1"
}'Call the ListValuationPointsOverview API to check the status is set to Final:

LUSID persists the following data in dedicated stores:
All the data associated with the NAV calculation, so the fund grid is always reproducible.
All the journal entry lines generated in response to economic activity in underlying portfolios, so other financial reports such as the trial balance are always reproducible.
In summary: You can always recreate a report based on a closed period. This persistence mechanism is future-proof against code changes in LUSID itself.
Re-opening a period
You can call the RevertValuationPointToEstimate API to revert a Final VP to a status of Estimate. You may want to do this in order to promote additional activity.
Call the DeleteValuationPoint API to delete a VP (of any status) and start over.