Key points
- Your administrator calculates NAV. The manager reviews and records it.
- Each figure needs its value per share, its date, and who recorded and approved it.
- Check each new figure against the last one and the administrator's report before it prices any trade.
- A worked example and a sample NAV log show what one wrong figure costs and how a flag catches it.
The administrator's March report has just landed, and a subscription and a redemption are waiting on the new value per share. Someone opens the report and types the figure into the fund's records. It takes a minute. One slip here quietly prices every trade that follows.
Who does what
Before the figure prices a trade, it passes through two hands and three steps.
- The administrator calculates NAV. It works from the fund's accounts and produces the figure on its schedule.
- The manager reviews it. The manager checks that the number makes sense next to the last one and what the fund holds.
- The manager records it. The manager enters the approved value per share in the fund's NAV records.
- 1 Calculate The administrator works out NAV from the fund's accounts.
- 2 Review The manager checks it against the last figure and the fund's holdings.
- 3 Record The manager enters the approved value per share.
What to record
A record has to make sense months later, when nobody remembers typing it. For each period, that means the value per share at the precision your administrator reports, the date it applies to, and who recorded and approved it.
If investors see share prices in a portal, those should come from the same records, so everyone sees the same numbers.
A corrected record keeps the old figure, the new figure, the date and the reason, so the history shows what changed and why.
Check against the administrator
A record is only useful if it matches its source. The simplest test is to export the NAV history after each period and compare it line by line with the administrator's reports. A mismatch points to the period that needs a look.
Where mistakes happen
Most errors are copying slips, not judgment calls:
- A decimal point in the wrong place.
- A figure typed from the wrong date's report.
- A value entered for the wrong fund.
- A correction that reached the administrator but not the manager's records.
Each can look reasonable on screen. The trouble starts when one gets through.
What a wrong NAV leads to
A NAV error found later reaches past that one number. Investors who joined when it was too high paid too much per share. Investors who redeemed when it was too low received too little. Either group may be owed compensation. Who bears that cost is a question for your fund terms.
NAV-based fees need to be rerun. Some funds set a materiality level, for example 0.5 or 1 percent, to decide when to correct. That level comes from market practice and fund contracts, not from regulation, so check your own documents.
Example (hypothetical numbers). Say a fund's value per share was $10.00 on February 28. The correct figure for March 31 is also $10.00. The manager records $10.20, typed from another fund's report. That is 2 percent too high.
- Investor A subscribes $102,000 at $10.20 and receives 10,000 shares. At $10.00, the same money buys 10,200 shares. Investor A is 200 shares short, worth $2,000.
- Investor B redeems 5,000 shares at $10.20 and receives $51,000. At $10.00, the correct payment is $50,000. The fund paid Investor B $1,000 too much.
The move from $10.00 to $10.20 looked plausible, so it passed the review. The export check against the administrator's report found it on April 15, after both trades went through. Checking the entry against the report before pricing would have caught it first. At 2 percent, the error is above both example materiality levels, so a fund using either one would correct it. The $2,000 Investor A overpaid went to the investors who stayed. The $1,000 overpaid to Investor B came out of them. Each error affects different investors, so netting one against the other fixes neither.
Two checkpoints
The example points to two checkpoints: before a figure prices any trade, and after each period closes. At the first, the manager compares the new figure with the last one, then checks the entry against the administrator's report before it prices any subscription or redemption. A move above a threshold set in advance gets a second person's look. At the second, the manager exports the history and compares it with the administrator's report. An error goes to the administrator first, then the fund's written error policy decides the rest.
Sample NAV log (hypothetical). This log flags any move above 1 percent for a second look. With this log in place, the example's March 31 entry would have been held before it priced any trade. The same columns work for your own records.
| Date applies to | Value per share | Change from last | Recorded / approved | Status |
|---|---|---|---|---|
| Jan 31 | $10.00 | n/a | R.T. / L.M. | Checked against the administrator's report |
| Feb 28 | $10.00 | 0.00% | R.T. / L.M. | Checked against the administrator's report |
| Mar 31 | $10.20 | +2.00% | R.T. / not yet | Held. Above 1%. Second look against the administrator's report |
The second look finds the figure came from another fund's report. The manager replaces $10.20 with $10.00 and logs the old figure, the date and the reason.
Back to that March report. Typing the figure takes a minute. Checking it against the report before the waiting trades price takes one more, and that minute keeps one wrong number away from investors.
Where Tahoe fits
Whatever system holds the record, the March figure still comes from your administrator. Tahoe never calculates NAV. Of the three steps above, Tahoe sits at step 3: the record of the approved figure.
We are building Tahoe so that:
- The manager enters the value per share from the administrator's NAV in a Record NAV form, with the date and who recorded it.
- The NAV history shows as a chart and a table, and exports as a CSV file to compare with the administrator's reports.
- Investors see share price history in a portal in your fund's brand.