NAV cycles rarely slow down in the calculation itself. They slow down in the work around it: chasing inputs from custodians, administrators and pricing vendors, reconciling positions and prices, resolving breaks, and then evidencing that a qualified second person reviewed and approved the result. In most fund administrators that work happens in spreadsheets, shared inboxes and chat, which is why a cycle that should take hours takes days, and why the audit trail has to be reassembled after the fact.
Next Matter runs NAV production and oversight as one governed, orchestrated process. Inputs are pulled from your source systems through native connectors and a typed API on a schedule, tolerance and completeness checks run automatically, exceptions and reconciliation breaks are raised as structured items and routed to the reviewer who owns that fund or asset class with the full context attached, and the NAV approval step enforces maker-checker (four-eyes) control: the person who prepared or last edited the NAV cannot be the person who signs it off. Every stage writes to a timestamped, immutable audit trail.
Nothing is replaced. Your fund accounting system stays the book of record and your pricing vendors stay the price source. Next Matter is the orchestration layer above them that sequences the cycle, holds the state, enforces the controls and produces the evidence pack. Ocorian runs global fund and investor operations on this model with 300+ specialists.
Mechanics
How a NAV cycle is orchestrated, stage by stage
Each stage below is a step in a single workflow instance. The instance holds the state of the NAV cycle, so at any moment an operations lead can see which inputs have landed, which checks passed, which breaks are open, who owns them, and whether the NAV is with the maker or the checker.
Pull inputs from ledgers, custodians and pricing feeds
The cycle starts on a schedule (daily, weekly, month-end) rather than on someone remembering. Next Matter calls your fund accounting or ledger system, custodian and administrator files, and pricing and FX feeds through native connectors and a typed REST API; file-based sources land through a monitored SFTP or secure upload step. Each pull is recorded with the endpoint or file name, the request parameters, the response payload, a UTC timestamp and the system identity that made the call. A source that does not respond, returns partial data or delivers a stale as-of date does not silently pass: it raises a structured exception at this stage, before valuation work begins.
Automated completeness and tolerance checks
Before anything reaches a human, the workflow runs the deterministic checks a NAV controller would otherwise run by hand: position counts and holdings reconciled between ledger and custodian, every security priced with a price of the correct as-of date, price movement inside a configured tolerance band against the prior valuation point, cash reconciled to custodian statements, accruals and fee calculations present, and the total NAV and NAV per unit movement inside its tolerance versus the prior cycle. Checks that pass are recorded as passed, with their inputs, so the review is evidenced rather than assumed.
Breaks go to the right reviewer, with context attached
A failed check becomes a structured exception, not an email. It is routed by rule to the accountable owner (by fund, asset class, jurisdiction or materiality) and lands in that person's queue with the evidence already assembled: the two values that disagree, both source records, the tolerance that was breached, the history of the same break on prior cycles, and the deadline it must clear to keep the cycle on schedule. The reviewer resolves it in place, with a mandatory categorisation and free-text reason, or escalates it. Escalation and time-based SLA breaches route upward automatically. The NAV cannot progress to sign-off while a material exception is open, and the resolution, the resolver's identity and the timestamps stay attached to the cycle.
Four-eyes NAV approval, enforced by the platform
NAV approval is where maker-checker (also called four-eyes) is enforced in software rather than trusted to process discipline.
- The maker is the NAV preparer or fund accountant who assembled the pack, cleared the exceptions and submitted the NAV. Their identity, the version they submitted and the submission timestamp are recorded.
- The checker is a NAV reviewer, oversight manager or valuation committee member holding the approver role for that fund. The platform blocks the maker and the checker from being the same identity, and blocks anyone without the role from approving.
- If the check fails, the checker rejects with a mandatory reason. The workflow returns to the maker with the rejection reason attached, the maker re-works and resubmits, and the second submission starts a fresh approval. Both the rejected and approved versions remain in the record.
- If it is escalated, for example a material valuation judgement or a tolerance override, the workflow routes to a further approver (head of valuations, valuation committee, or a second checker) before release. Escalation thresholds are configured per fund.
- Overrides are never silent. Approving over an open tolerance breach requires an explicit override with a written justification, and is flagged in the evidence pack rather than buried in a log.
Distribution and an audit trail that is already complete
On approval the workflow writes the NAV back to the systems that need it, publishes the investor-facing statements or files, and notifies the depositary, transfer agent and downstream reporting processes. Because the audit trail was captured as the work happened, the evidence pack for that cycle exists at the moment of release. There is no reconstruction exercise later, and no one, including administrators, can retroactively edit the recorded history of the cycle.
Evidence
What the audit trail captures at each stage
Worked example
One month-end NAV cycle, with a break caught in flight
A closed-ended fund with listed and unlisted holdings strikes a month-end NAV. The example below is a typical shape of a governed cycle, not a guaranteed timeline.
- 1The scheduled trigger fires after the valuation point. Next Matter pulls trial balance and positions from the fund accounting system, the custodian position and cash file, vendor prices and FX rates, and the latest unlisted valuations from the data room.
- 2Validation runs. Positions and cash reconcile, all listed securities are priced with the correct as-of date, but one holding moved 11 percent against a configured 5 percent tolerance, and one unlisted position has no refreshed valuation for the quarter.
- 3Two exceptions are raised and routed. The price break goes to the fund accountant who owns that portfolio, with both prices, the vendor record and the prior three valuation points attached. The stale unlisted valuation escalates straight to the valuation oversight manager.
- 4The accountant identifies a corporate action the vendor applied a day late, resolves the break by taking the corrected price, and records the category and reason. The oversight manager attaches the signed valuation memo for the unlisted holding. Both resolutions are timestamped against the cycle.
- 5With no material exception open, the accountant (the maker) submits the NAV pack. The NAV reviewer (the checker) opens it, sees the two exceptions and their resolutions in line, queries one, receives an answer in the same thread, and approves. The platform would have refused the approval had the maker attempted it.
- 6On approval the NAV is written back, investor statements are generated, and the depositary and transfer agent are notified. The evidence pack for the cycle, every input, check, break, resolution, identity and approval, is complete at the moment of release.
Where the time goes
What "compressing the cycle" actually removes
The saving is not a faster calculation. It is the removal of specific manual steps that sit between calculation and sign-off.
Keep reading