NAV Oversight and Shadow Fund Accounting Software: How Do You Verify the Administrator Before the Strike Goes Out?

The window is the whole problem

The administrator sends the preliminary NAV package at 4:40pm. The fund has to strike by 6pm because Rule 22c-1 forward pricing means the day's subscriptions and redemptions transact at that price and it goes out to investors and to the pricing services. In eighty minutes someone has to answer: are the positions right, are the prices right, are the accruals right, did the capital activity land in the correct series, and is the cash break explained. The tool is a workbook. The evidence is a saved copy of that workbook with a filename ending in FINAL_v3.

This is a control function, not a convenience. If the strike is wrong, the manager compensates investors who transacted at the wrong price, restates, and explains it to the board and the regulator. Nobody signs off on shadow accounting because it is efficient. They fund it because a wrong NAV is a reportable, chequebook event.

The oversight team is usually two to four people who know exactly what they are doing and are limited entirely by tooling. In our delivery experience the recurring pattern is six to twelve hours a week of senior time spent on mechanical reconciliation, and a review that gets shallower on the days it matters most, which are the volatile ones where prices move and capital activity spikes.

What the incumbents do, and where the gap sits

SS&C Geneva and SimCorp Dimension are strong general ledgers for investment books of record. BNY Eagle is a solid accounting and data management platform. Milestone Group pControl is purpose built for NAV oversight and is genuinely the closest thing to a packaged answer. FIS Investran is the standard in private capital. None of these are bad products, and if your operating model matches theirs, use them.

The gap is specific. These platforms are built around their own model of a fund, a fee, a share class and a valuation policy. Your oversight rules are not a fund model, they are your model: the tolerance you apply to a level two bond price versus a level one equity, the fact that you accept a five basis point difference on the emerging market sleeve and zero on the money market fund, the escalation path that says a break over a threshold goes to the CIO and not to the analyst, and the fact that your Cayman feeder has an equalisation method your Luxembourg vehicle does not. Configuring that into a packaged platform is a multi year implementation with a consultant, and at the end you own a configuration you cannot read.

The other gap is file reality. Every administrator sends a different package. Some send a clean daily extract. Some send a workbook with merged cells and a tab per share class. Some send a PDF. Changing administrator means redoing the ingestion, and no packaged tool absorbs that gracefully.

Problem one: reconciliation is not comparison

Pasting two position files side by side and running a difference finds the easy breaks. It misses the ones that matter. A position can agree in quantity and disagree in cost basis. A bond can agree at the security level and disagree because the administrator applied a factor update you did not. A swap can net to the same exposure with a different sign convention. A corporate action can be booked as a cash dividend on one side and a stock dividend on the other, and the difference only shows in the accrual.

A real build normalises both sides into one instrument and event model first, then reconciles at the level where breaks actually live: quantity, cost, accrued income, and market value separately, with a rule that knows why each may legitimately differ. It carries breaks forward with aging, so a two cent difference that has been there for nine days gets escalated rather than dismissed daily.

Problem two: price challenge is where the money is

The valuation decisions are where a NAV goes badly wrong, not the arithmetic. Under Rule 2a-5 the board or its designee owns fair value determination, and the evidence for it has to exist. In practice, the manager holds views the administrator does not: a stale price on a thin corporate bond, a broker quote that has not moved in four days, a private position marked at last round while a subsequent transaction is known internally.

What a build must include is a price challenge workflow that is a first class object, not an email. Every price gets a source, a timestamp, a staleness measure and a tolerance band derived from the security type and liquidity. Prices outside the band raise a challenge with the alternative source attached. The challenge, the administrator's response and the final applied price are recorded together, and that record becomes the valuation committee pack automatically. Managers who build this stop preparing the committee pack by hand, which is often several days a month by itself.

Problem three: fees and expenses are the quiet errors

Management fees on a tiered scale with a breakpoint, performance fees with a high water mark per series, an expense cap with a recoupment window, a distribution fee that differs by share class, and an accrual that has to unwind at period end. Every one of these is arithmetic that any competent system can do and almost nobody independently checks daily, because checking it means reimplementing the fee schedule from the offering document.

That is exactly what a custom build should do: encode the fee terms from your own documents as executable rules, recompute the accrual independently, and compare to the administrator's number. In our experience this is the single feature that finds real money. Fee errors do not self correct, they compound quietly across a period and then get discovered during the audit, when fixing them is expensive and embarrassing.

Problem four: series, share class and equalisation

If your funds use series accounting or an equalisation method, the allocation of performance fees across investors who subscribed on different dates is genuinely difficult, and it is where oversight most often stops at the fund level and never gets to the investor level. The administrator's number for the fund can be right while an individual investor's allocation is wrong.

A build that models series and equalisation explicitly can recompute the allocation and reconcile the sum back to the fund. That is not a nice to have for a manager whose offering documents promise a specific method. It is the difference between saying you have oversight and having it.

What a first release should contain

• Ingestion for every administrator file you receive, including the ugly ones, with schema validation and a clear failure mode when a file arrives late or malformed.
• An instrument and event model that both sides normalise into, rather than a column by column file diff.
• Tolerance rules by security type, liquidity and fund, with aging and automatic escalation paths that match your own governance.
• Price challenge as a workflow object with sources, staleness, evidence and outcome.
• Independent recomputation of management fees, performance fees, expense caps and accruals from the terms in your documents.
• Capital activity checks tying subscriptions and redemptions to dealing deadlines, the correct NAV and the fund bank account.
• An evidence pack generated on demand for the valuation committee, the board and the auditor, with a full immutable history of who approved what and when.

Cost, timeline and what moves the number

A first release with ingestion, reconciliation, tolerances and the exception queue runs $80,000 to $180,000 over 12 to 18 weeks. Adding fee recomputation, capital activity, series and equalisation, and the evidence pack takes it to $200,000 to $500,000 over 6 to 12 months.

What pushes the number up: instrument complexity above all. A long only equity book is straightforward. Add over the counter derivatives with collateral and variation margin, structured credit with factors and paydowns, private positions with capital calls, or anything requiring look through into underlying funds, and each adds real weeks because each needs its own event model. Multiple administrators multiply the ingestion work rather than adding to it. Multiple jurisdictions add valuation policy variation. Same day rather than next day oversight tightens every engineering choice.

What holds it down: starting with your largest fund and your noisiest break class. In our experience the top two break classes usually account for most of the manual time, and proving the model there de risks everything after.

Build, buy, or accept the workbook

Buy pControl or use your existing SS&C or SimCorp footprint if your fund range is conventional, your fee terms are standard, and your administrator relationship is stable. That is a real answer and we give it regularly.

Build when two or more of these are true. Your fee and expense terms are negotiated per mandate and cannot be expressed in a vendor's configuration. You run series accounting or equalisation and your oversight currently stops at the fund level. You use more than one administrator, or you expect to change one. Your tolerance and escalation policy is a document nobody has ever automated. Or your oversight quality visibly degrades on volatile days, which is the day it is supposed to work.

Accept the workbook if you run one fund with one share class and a liquid book. Oversight at that scale is a person with a checklist, and a build would be theatre.

Choosing a developer

Ask them to model a security master before they model a screen. If they start with the dashboard, they have built a reporting tool before and will build you another one. The instrument and event model is the project.

Ask how they would handle a performance fee with a high water mark and an equalisation method. If the answer is that the administrator handles it, they have missed the entire point of oversight, which is to check the administrator.

Ask what they have ingested. A pControl extract, a Geneva report, a custodian SWIFT MT535 statement and an administrator's merged cell workbook are four different problems. Ask for the specific file and the specific administrator.

Ask about immutability and evidence retention, because your auditor will. Append only history with independent verification is the right answer. And settle code ownership before kickoff: you should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and in a control function you should not accept less.