--- title: "Striking a NAV and closing a period" slug: "striking-a-nav" updated: 2026-03-10T09:17:22Z published: 2026-03-10T09:17:22Z canonical: "support.lusid.com/striking-a-nav" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.lusid.com/llms.txt > Use this file to discover all available pages before exploring further. # Striking a NAV and closing a period You can strike a NAV at any time. This means selecting a fund and a particular [NAV type](/v1/docs/how-do-i-create-a-fund#understanding-nav-types), and creating a *valuation point* (VP) with a closure date and one or more cut offs to determine which data to include. LUSID then: 1. Calculates GAV as dealing (subscriptions and redemptions) plus P&L since the previous VP (or from fund inception if this is the first VP). 2. Calculates NAV as GAV minus accrued fund fees. 3. Closes the period and persists associated data so reports are always reproducible. Note you can strike an ad-hoc NAV without closing a period using a [bookmark](/v1/docs/how-do-i-create-a-bookmark) instead of a VP. [See a list of other financial reports](/v1/docs/generating-fund-reports). ## Creating a valuation point with a closure date and cut offs You must [create a valuation point](/v1/docs/how-do-i-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 to `Final`. [See how to do this](/v1/docs/striking-a-nav#finalising-an-estimate-to-officially-close-a-period-and-persist-data). Because LUSID is [bitemporal](/v1/docs/what-is-bitemporal-data), 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 `effectiveAt` that determines when the period closes, for example just before midnight on 31 January 2024. The `effectiveAt` of every data point you wish to include in the NAV calculation must be prior to this timestamp. - A `queryAsAt` that determines a cut off for data entering the system. This can be the same as `effectiveAt` or 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 more fine-grained control by additionally specifying the following cut offs: - A `holdingsAsAtOverride` that 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 `valuationsAsAtOverride` that 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 `queryAsAt` retains 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](https://www.lusid.com/docs/api/lusid/endpoints/funds/UpsertDiaryEntryTypeValuationPoint) API to create a VP for a fund’s `OFFICIAL` NAV type as follows: ```json curl -X POST 'https://.lusid.com/api/api/funds/MyFunds/Growth/valuationpoints?navTypeCode=OFFICIAL'  -H 'Content-Type: application/json-patch+json'  -H 'Authorization: Bearer '  -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 `effectiveAt` is a millisecond before midnight on 31 January 2024. - The `holdingsAsAtOverride` is EOD 31 January (before the `effectiveAt`) 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 `valuationsAsAtOverride` is EOD 1 February (after the `effectiveAt`) to allow extra time for market data to flow into LUSID. - The `queryAsAt` is EOD 2 February to allow extra time for the fund accounting team to make changes to posting rules. - The `diaryEntryVariant` field is optional but naming each variant is useful if you want to create more than one (see below). Call the [ListValuationPointsOverview](https://www.lusid.com/docs/api/lusid/endpoints/funds/ListValuationPointOverview) API to preview the NAV calculation using the data included by the various cut offs. Note the status is set to `Estimate` (here the API response is transformed to a table for clarity): ![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-V1W96YU0.png) ## Creating multiple variants of the same estimate You have the option to create variants of an `Estimate` valuation point with different cut offs. > **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](https://www.lusid.com/docs/api/lusid/endpoints/funds/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](https://www.lusid.com/docs/api/lusid/endpoints/funds/ListValuationPointOverview) API to compare the NAV calculations: ![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-8MNI8XJ2.png) ## 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](https://www.lusid.com/docs/api/lusid/endpoints/funds/GetValuationPointData) API, or write a SQL query using the [Lusid.Fund.ValuationPointData](/v1/docs/lusidfundvaluationpointdata) provider. ![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-V9DC1U51.png) ## 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 off but that you wish to include anyway. These can be new or updated: - Transactions (with an activity adjustment type of `PortfolioTransaction`) - Quotes (coming soon) - Instrument definitions (coming soon) - Settlement instructions (coming soon). To do this, call the [UpsertNavActivityAdjustments](https://www.lusid.com/docs/api/lusid/endpoints/funds/UpsertNavActivityAdjustments) API with a list of adjustments, for example: REST APIPython SDK ```bash curl -X POST 'https://.lusid.com/api/api/funds/MyFunds/Growth/navAdjustment?valuationPointCode=31Jan2024&navTypeCode=Daily&valuationPointCodeVariant=Variant2'  -H 'Content-Type: application/json-patch+json'  -H 'Authorization: Bearer '  -d '[  {    "navActivityAdjustmentType": "PortfolioTransaction"    "asAt": "2024-02-03",    "portfolioScope": "MyPortfolioScope",    "portfolioCode": "MyPortfolioCode",    "transactionId": "Txn05",  } ]' ``` ```python fund_api = lusid_api_factory.build(lusid.api.FundsApi) 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 you must specify an `asAt` date that is on or after the entry date of the economic item into LUSID. So in this example, if transaction `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 record. You could promote the original record instead by specifying an `asAt` date of 1 February. ## Finalising an estimate to officially close a period and persist data To close a period and persist associated data, call the [AcceptEstimateValuationPoint](https://www.lusid.com/docs/api/lusid/endpoints/funds/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: ```json curl -X POST 'https://.lusid.com/api/api/funds/MyFunds/Growth/valuationpoints/$acceptestimate'  -H 'Content-Type: application/json-patch+json'  -H 'Authorization: Bearer '  -d '{  "diaryEntryCode": "VP-31Jan2024",  "diaryEntryVariant": "Variant1" }' ``` Call the [ListValuationPointsOverview](https://www.lusid.com/docs/api/lusid/endpoints/funds/ListValuationPointOverview) API to check the status is set to `Final`: ![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-CUMZUU2V.png) LUSID now 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](/v1/docs/how-does-lusid-generate-journal-entry-lines-from-economic-activity) 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](https://www.lusid.com/docs/api/lusid/endpoints/funds/RevertValuationPointToEstimate) API to revert a `Final` VP to a status of `Estimate`. You may want to do this in order to [promote additional activity](/v1/docs/striking-a-nav#adjusting-the-nav-calculation-by-promoting-additional-activity). Call the [DeleteValuationPoint](https://www.lusid.com/docs/api/lusid/endpoints/funds/DeleteValuationPoint) API to delete a VP (of any status) and start over.