A NAV notice arrives for a fund with a 10% one-month decline trigger. Two people in the same team read it. One says the trigger has fired. The other says it has not. Both are right, and neither has noticed that they are answering different questions.
This is the most common disagreement we see in fund monitoring, and it is invisible until a breach is disputed. The clause says "Net Asset Value declines by 10% or more over any one-month period". The notice contains several numbers that could reasonably be called the net asset value. Which one you pick decides the answer.
One notice, four answers
Take a simple month. The fund started at USD 500m total NAV with a NAV per share of 10.00. During the month investors redeemed USD 40m. At month-end the notice shows total NAV of USD 440m and a NAV per share of 9.80.
| Basis | Calculation | Move | 10% trigger |
|---|---|---|---|
| Headline total | 440 against 500 | −12.0% | Fired |
| Flow-adjusted total | 440 plus the 40 redeemed, against 500 | −4.0% | Passed |
| Per share | 9.80 against 10.00 | −2.0% | Passed |
| Fund total, not the class you face | The umbrella's total NAV, which the notice also reports | −3.1% | Passed |
The headline answer is what a spreadsheet gives you when someone types the number on the front page into the cell for this month. The flow-adjusted answer is what most schedules actually ask for, because the drafting excludes "subscriptions, redemptions, distributions and other capital transfers". The per-share answer is the cleanest measure of performance, and it is what you fall back to when the flows for the window are not disclosed. The fourth answer is the one you get when the counterparty is a sub-fund or a share class and the notice leads with the umbrella.
Notice that flow-adjusted and per-share do not agree either. They differ by the price at which the redemptions left. Add back USD 40m at nominal and you get one number. Track the unit price and you get another. Neither is wrong. They are different measures, and a clause that names one is not satisfied by the other.
The basis has to be a stored choice
The fix is not to argue about which basis is best. It is to make the basis an explicit field on the test, decided once when the agreement is read, cited to the clause that decided it, and stored with every result.
In our register each test carries its measurement convention: any reported NAV in a rolling window, or month-end to month-end, or per-share proxy. It carries its basis: flow-adjusted, per share, headline. When the test runs, the result records the value used, the basis used, and whether a fallback was applied. If flows for the window were unknown and the engine tested per share instead, the result says so, and the flag stays on the result for anyone who looks at it later.
Two people can disagree about a fund. They should never disagree about what the test was run against.
Why this is the hard part
Extracting the threshold from a schedule is easy. Extracting the basis is where the reading has to be careful, because it is spread across a definition on page 3, a carve-out on page 11 and a side letter. The measurement convention matters just as much: a clause that tests "any reported NAV against the NAV 30 days earlier" fires on intra-month figures a month-end clause never sees.
We built the test runner to hold all of these as data rather than as code paths, so a fund with a bespoke basis is a row with different values, not a special case someone has to remember. The worked example above is the one we use to check every release: four answers from one notice, each traceable to a basis, and the basis traceable to a page.