A NAV report is the packaged output of a NAV close. It is not only “the NAV number.” It is the set of schedules, tie-outs, and explanations that show how the fund arrived at net asset value for a period, and that support investor reporting, client communication, and audit readiness.
NAV reporting is the process behind that output. It covers how inputs are collected, how the draft NAV is built, how reviews and quality control (QC) are performed, how approvals happen, and how the final reporting pack is distributed and archived.
For fund administrators and PE ops teams, most NAV reporting problems do not come from the formula. They come from missing or misaligned inputs, weak reconciliation to the general ledger, unclear versions, and investor allocations that do not tie back to the fund-level NAV.
Note: this is general information. Fund documents, valuation policy, and your reporting basis govern the final structure and terminology of your NAV report.
Key takeaways
- A NAV report is a controlled reporting pack, not a single metric. It should include rollforwards, schedules, and tie-outs that make the NAV explainable and defensible.
- NAV reporting succeeds or fails on tie-outs. Your QC should connect the report back to the trial balance, reconciliations, and valuation support, not just internal worksheets.
- Investor statements are downstream of fund NAV. If investor allocations do not tie back to the fund totals, you do not have a releasable pack.
- Version control is real control. A clean approval and distribution workflow prevents “two finals” and reduces audit and client friction.
One source of truth for NAV reporting
Unified accounting and investor reporting for fund administrators.
What a NAV report is, and what it is not
A NAV report (sometimes called a net asset value report or “NAV pack”) is the final deliverable that summarizes the fund’s NAV for a period and provides the supporting schedules needed to explain and validate it. The audience can include the GP finance team, the fund administrator, operations, investor relations, auditors, and sometimes LPs (depending on what is included and how it is distributed).
A helpful way to think about it is this: a NAV report should let a reviewer answer three questions without hunting through systems:
- What is the fund’s NAV as of the valuation date?
- What changed since the last period, and why?
- Do the numbers tie back to accounting records and supporting evidence?
A NAV report is not the same as a marketing performance deck. It is also not the audited financial statements (even though it should support them). And it is not only an investor statement, although investor statements often come out of the same NAV reporting process.
Fund-level NAV vs investor-level reporting
Fund-level NAV is the total net value of the fund as of a date. Investor statements and capital account reporting show each investor’s allocated share of that fund NAV and the rollforward components. ILPA’s Reporting Template definitions, for example, describe “NAV Reconciliation” as an LP’s allocation of total fund balances representing that investor’s interest in the total private fund.
That distinction is operationally important. You can have a fund-level NAV that is correct while investor-level allocations are wrong, or vice versa. Your NAV reporting QC needs to cover both.
What a NAV report includes
A strong NAV report is consistent period to period. You can make it more detailed for complex funds, but the core sections should not change every close. The table below is a practical template that covers what most fund admin and PE ops teams need, along with where the data should come from and how it should be checked.
NAV report sections and source of truth
| Section of NAV pack | What it shows | Primary source | Key QC check | Typical owner |
| Executive NAV summary | Fund NAV, period change, key drivers | Reporting layer (built from below sections) | Numbers match the rollforward and the balance sheet summary | Fund accounting/reporting |
| NAV rollforward | Beginning NAV to ending NAV with drivers (calls, dists, P&L, fees, expenses) | Investor ledger + GL + valuation | Rollforward ties to ending NAV and investor totals | Fund accounting/investor services |
| Statement of assets and liabilities (summary) | Assets, liabilities, and net assets as of the date | Trial balance / GL | Totals tie to TB and reconciliations | Fund accounting |
| Investments schedule | Holdings by deal or asset, cost, fair value, change | Portfolio accounting + valuation outputs | Completeness vs holdings record, valuation support exists | Valuation + accounting |
| Pricing and valuation summary | Methodologies used, major valuation changes, exceptions | Valuation memos + pricing files | Exceptions resolved or documented | Valuation/controller |
| Cash and activity summary | Cash balances and movements, timing items | Bank / custodian + GL | Cash reconciled, timing items logged | Fund accounting |
| Fees and expenses schedule | Management fees, performance fee or carry presentation if used, fund expenses | GL + fee models + invoices | Accrual logic matches terms and prior period patterns | Fund accounting/controller |
| Financing schedule (if applicable) | Subscription line, NAV facility, interest accruals | Debt statements + GL | Balances and interest tie to lender support and TB | Fund accounting |
| Capital activity summary | Calls, dists, transfers, subscriptions, redemptions | Investor ledger + bank activity | Capital activity ties to cash movements and notices | Investor services |
| Investor allocation summary and tie-out | Investor totals, class totals, tie to fund | Investor ledger + allocation engine | Sum of investors equals fund totals; exceptions investigated | Investor services/accounting |
| Notes and methodology highlights | FX source, cut-off policy, valuation policy references, and assumptions | Close methodology docs | Consistent language, matches what was actually done | Controller/reporting |
A few practical points that reduce confusion:
- Keep the order stable. Reviewers build muscle memory around where to find things.
- Label drafts clearly. “Preliminary” and “Final” should be unambiguous.
- Keep one version as the official release. If you rerun, treat it as a new version with an approval trail.
NAV reporting process: from inputs to distribution
NAV reporting is a workflow with dependencies. When teams struggle, it is usually because the workflow is implicit rather than explicit. Making it explicit reduces reruns and makes the review faster.
1) Input collection and readiness gate
This stage is about making sure you have the minimum viable inputs to start a close. In practice, that means confirming you have the trial balance or GL extract, bank and custodian data, capital activity information, and valuation inputs, or at least a clear plan for them.
Teams often get stuck here when inputs arrive on different timelines (for example, bank cash is available dail,y but valuation memos are not). The fix is to define what “ready to draft” means for your fund type and stick to it. If valuations are not ready, decide whether you will run a clearly labeled preliminary pack or wait.
A good readiness gate produces a short tracker: what is received, what is missing, and who owns each missing item.
2) Draft NAV build
This is where the fund-level NAV is assembled from assets and liabilities, and the first draft of the report pack is produced. The draft should be anchored in the GL and trial balance for liabilities and accruals, and anchored in valuation support for investments.
Teams get stuck here when they build “reporting NAV” outside the accounting system, then later have to reconcile back to the books. The fix is to decide what is the anchor and keep it consistent. For most fund admin contexts, the GL is the anchor for liabilities, and the valuation process is the anchor for investment fair value.
The output of this stage should be a draft pack and a list of open items. It should not be a “final” pack waiting for someone to notice that something is missing.
3) QC and tie-outs
QC should be treated as a structured review, not as “looking at the numbers.” The goal is to prove that the pack is complete, that it reconciles back to records, and that material movements have explanations.
Teams get stuck here when QC is performed too late, or when the QC reviewer does not have access to the underlying support. A practical fix is to build QC into the pack itself, such as a tie-out page and a checklist page, and require that it is completed before the pack moves to approval.
4) Review and approvals
This is where governance matters. Most NAV packs need at least one independent reviewer, often a controller, senior accountant, or client-facing reviewer. For some funds, there is also a formal valuation approval step.
Teams get stuck here when approvals are informal, or when the client asks questions that require rebuilding support from scratch. A practical fix is to define an approval matrix and ensure the pack includes the supporting schedules that answer the usual questions (big movements, fees, valuation changes, and cash timing).
5) Finalization and distribution
Finalization means locking the numbers, locking the version, and producing the final PDFs and data extracts that will be delivered. Distribution should be controlled, because errors here are reputational.
Teams get stuck here when they distribute from email chains and file shares, because that creates “multiple finals.” A controlled distribution method, plus a clear archive, reduces confusion.
6) Archive and evidence retention (post-close)
The close is not finished when the pack is sent. Evidence must be retained in a consistent way so the team can answer questions later and support audits. This includes reconciliation workpapers, valuation support, and the final approved pack.
Teams get stuck when evidence is spread across inboxes and spreadsheets. A simple solution is a standardized evidence folder structure and a clear rule: the evidence pack is not complete until all tie-outs and approvals are stored in one place.
Quality control framework: the checks that catch real errors
QC needs to connect across systems. The NAV report is the end product of multiple sources: GL, bank and custodian data, valuations, and investor ledgers. A QC checklist that only checks internal worksheets will miss the highest risk issues, because most close errors are cross-system.
A useful QC framework has five themes.
Completeness
You want to know that all relevant activity is included for the period. This includes cash movements, capital activity, expenses, and valuation updates. Completeness issues are often the root cause of late reruns.
Accuracy
Accuracy is the math and logic. It includes whether fee accrual formulas are correct, whether FX rates match the chosen source, and whether totals tie properly.
Cut-off and timing
Cut-off issues are inevitable. The control is not to eliminate them, it is to identify them, treat them consistently, and document them. Timing items are where “why did NAV move?” questions often begin.
Consistency and policy adherence
This is where NAV reporting meets process governance. Did you apply the valuation policy the same way as last period? Did you use the same FX source? Did you apply the same fee-based definitions as your terms require?
Approvals and evidence trail
This is the difference between “we think it is right” and “we can prove it.” Approvals should be recorded, and the support should be retrievable without detective work.
QC checklist (reusable)
Use this as a standard QC page in your NAV report. It is designed to be operational, not theoretical.
| QC check | What it should tie to | What to do if it breaks |
| Fund NAV ties to statement of assets and liabilities | Balance sheet style NAV summary | Stop and resolve the mapping or classification difference before moving forward |
| Assets and liabilities in the NAV pack tie to the trial balance | TB extract, same date | Confirm you are using the same version of the TB and the same cut-off, then fix the mapping |
| Cash is reconciled, or timing items are documented and owned | Bank or custodian statements | Do not release if unreconciled items exceed your threshold, assign owners for timing items |
| Investment schedule is complete | Holdings record or portfolio accounting extract | Investigate missing positions, duplicated positions, or stale holdings feeds |
| Valuation support exists for material marks | Valuation memos, approvals, pricing files | Escalate missing support before release, document exception handling if unavoidable |
| Pricing and FX source is consistent across the pack | FX rate table and pricing source list | Lock the period rates and correct the pack so all components use the same source |
| Fee accruals align to fund terms and expected patterns | Fee model, prior period schedule | Recalculate with the correct base or rate, document any judgment changes |
| Expense accruals are complete and reasonable | Invoice log, accrual schedule | Add missing accruals, reclass if needed, document large estimates |
| Financing balances and interest accruals tie | Lender statements, GL accounts | Reconcile principal movements and interest calculations, update the schedule |
| Capital activity ties to cash movements | Bank activity, notices, investor ledger | Identify missing notices or mispostings, correct investor mapping |
| Investor totals tie to fund totals | Allocation tie-out page | Investigate class mappings, transfer effective dates, equalization logic, rerun allocations if needed |
| Material variances are explained in plain language | Variance commentary page | Identify the driver (valuation, flows, fees, FX), then document the explanation in the pack |
| Version control is clean, only one final | Release log or tracker | Stop distribution until the pack is locked and the approval version is labeled clearly |
Stop-the-line criteria (when not to release)
Instead of debating at the end, define conditions where the team pauses release. The exact thresholds depend on fund size and investor expectations, but the categories below are widely applicable.
| Stop-the-line condition | Why it matters |
| Unreconciled cash or positions above your materiality | It undermines the foundation of the NAV and often indicates missing activity |
| Missing valuation support or approvals for material investments | You cannot defend the NAV change or explain the valuation basis |
| Fund-level totals do not tie to the trial balance | The pack is not anchored to accounting records |
| Investor totals do not tie to fund totals | Investor statements and allocations are not reliable |
| Known fee-based or rate misapplication | It can cause systematic errors across all investors and periods |
| Conflicting “final” versions in circulation | It creates reputational and audit risk immediately |
How NAV reporting ties to NAV accounting
NAV reporting is the presentation layer. NAV accounting is the set of accounting records and processes that produce the underlying balances, classifications, and allocations.
In practice, NAV reporting ties to NAV accounting in three ways:
- The GL and trial balance anchor liabilities and accruals. A NAV report that cannot tie to the TB is fragile. Liabilities are where many NAV differences hide: payables, accrued expenses, fee accruals, financing, and timing items.
- Allocations translate fund-level results to investor-level outcomes. Investor statements and capital account rollforwards are downstream of the fund-level NAV and its drivers. ILPA’s NAV reconciliation framing is useful here because it makes the goal explicit: the investor view is an allocation of total fund balances.
- Audit support is built from the same evidence. Auditors and reviewers care that the NAV report is consistent with the books, that valuation judgments are documented, and that the workflow is repeatable.
Mini example: how a late expense changes both accounting and the NAV report
Assume a fund has a draft quarter-end NAV pack that shows an ending NAV of 200,000,000. After draft review, a 250,000 legal invoice related to the quarter is received and should be accrued.
If you accrue it, you change the accounting records and the NAV report.
| Item | Before accrual | After accrual | Where it shows up in the NAV report |
| Accrued expenses (liability) | 1,200,000 | 1,450,000 | Statement of assets and liabilities, expenses schedule |
| Fund NAV | 200,000,000 | 199,750,000 | Executive summary, rollforward, NAV per investor |
| Investor allocations | Based on 200,000,000 | Based on 199,750,000 | Capital account statements, investor tie-out |
Operationally, this is why NAV reporting cannot be separated from NAV accounting. A late accrual is not only an accounting entry. It changes the report pack, the rollforward, the investor allocations, and the explanation of period movements. The QC checklist should catch this by testing expense completeness and by requiring the NAV pack to tie to the TB.
Common NAV reporting breakpoints and how to avoid them
Late valuation marks or revised prices
This often presents as a clean draft pack that becomes unstable because valuations change after allocations have run. It happens because valuation timelines are different from accounting timelines. The prevention is a valuation readiness gate and a clear rule about when investor allocations may run, plus labeling of preliminary versus final marks.
Unreconciled cash timing items that keep rolling forward
Cash breaks rarely fix themselves. They roll forward and compound. The symptom is that the pack always includes “timing items,” but no one can explain whether they are clearing. The prevention is a timing items log with owners and due dates, and a rule that aged items are escalated.
Fee base misinterpretation
Management fee bases vary widely across funds. The symptom is that fees drift unexpectedly, and true-ups become routine. The prevention is a controlled fee terms schedule that is reviewed, versioned, and validated during QC against terms and prior period behavior.
Expenses posted in the wrong period
This shows up as unexplained variance in expenses, or a mismatch between invoices received and accruals booked. The prevention is a structured expense review during QC, focused on large expenses, new vendors, and cut-off items.
Capital calls or distributions posted late, or posted to the wrong investor
The symptom is investor statements that do not match notices or cash movements. The prevention is to tie capital activity to cash movements and to have a second-person review for investor mapping changes and transfers.
Investor transfer or class mapping errors
This shows up as one investor being overstated and another understated, while the fund total still ties. The prevention is an allocation tie-out that flags unusual movements at the investor level, and a controlled process for applying transfer effective dates and class mappings.
FX inconsistency across systems
Multi-currency funds often have mismatches between FX sources used in valuations, the GL, and reporting. The symptom is a NAV pack that does not tie cleanly, and performance that looks inconsistent. The prevention is a single FX source per period, locked rates, and a QC check that confirms consistency.
Reruns and conflicting “final” versions
The symptom is multiple “final” packs in circulation, and stakeholders asking which one is correct. The prevention is to treat reruns as new versions, record approvals for the final version only, and distribute from a controlled channel.
Weak tie to the trial balance
This is the root cause of many recurring issues. The symptom is a NAV report that is built from spreadsheets and cannot be reconciled cleanly to the books. The prevention is to anchor the pack to the TB, maintain a mapping, and treat the TB tie-out as a mandatory QC step.
NAV report templates: what to standardize
Standardization is not about making every fund identical. It is about making your process repeatable. Two templates are usually enough: an internal operational pack and an LP-facing pack.
Template A: Internal NAV pack (operational)
This version is built for reviewers. It should make it easy to see what moved, what is broken, and what needs approval.
| Component | Include | Why |
| Tie-out page | TB tie, cash rec status, investor tie-out | Makes QC visible and reduces hunting |
| Exceptions log | Pricing exceptions, missing support, timing items | Tracks unresolved issues and prevents repeats |
| Variance commentary | Top drivers and explanations | Enables faster review and client discussion |
| Version and approval page | Draft number, approvers, date/time | Prevents multiple finals and confusion |
What to keep out: overly formatted charts that slow production without improving control.
Template B: LP-facing reporting pack
This version is built for clarity and consistency. It should show investors what they care about and provide enough detail to reduce questions, without exposing internal exception logs.
| Component | Include | Why |
| NAV and rollforward | Beginning NAV, calls, dists, net change, ending NAV | Matches common investor expectations and standard reporting structures |
| Capital account statement | Investor-level allocations and balances | Shows the investor’s ownership and activity |
| Fees and expenses summary | High-level totals and explanations | Reduces recurring questions, supports transparency goals |
| Notes and methodology | Valuation date, FX source, material assumptions | Sets expectations and improves trust |
What to keep out: internal tie-out pages, unresolved exception logs, and working drafts. Those are for internal governance and audit support.
For both templates, standardize who approves, where evidence lives, and what “final” means.
How FundCount supports NAV reporting
A reliable NAV reporting process depends on consistent accounting data, repeatable reporting outputs, controlled approvals, and a distribution method that reduces version confusion. FundCount positions its platform around integrated accounting and reporting, with reporting features and distribution options that can support a NAV reporting workflow.
One platform for fund accounting and investor reporting
Keep NAV, fees, allocations, and statements tied to the same source of truth for cleaner closes.
- Standardized reporting output can reduce manual pack building. FundCount describes configurable out-of-the-box reporting with over 70 built-in reports, along with Power BI integration and custom reporting options using Excel and data extracts.
- Partnership accounting functions can support NAV reporting inputs. FundCount’s partnership accounting solution highlights support for calculating NAV, handling contributions and distributions, and managing series of shares and multi-class partnerships, which are common inputs to investor-level NAV reporting.
- A report archive and templates can help with consistency. FundCount’s reporting solution describes an “extensive Report Encyclopedia” and templates, which can help teams keep NAV report structures consistent period to period.
- Controlled distribution can reduce “multiple finals.” FundCount’s investor portal highlights batch statement delivery and an optional approval workflow for compliance sign-off, which can support controlled release of NAV statements and related documents.
- Secure access and layered approvals support governance. FundCount’s reporting pages describe sharing through email or a secure portal with encryption and layered approvals, aligning with the governance needs of NAV reporting distribution.
Conclusion
NAV reporting is the operational bridge between valuations, accounting records, and investor communication. A strong NAV report is consistent, reconcilable, and supported with evidence, so reviewers can approve it confidently and stakeholders can understand what changed. If you want to reduce reruns and “endless questions,” standardize the pack, formalize QC tie-outs to the trial balance and reconciliations, and treat version control and distribution as real controls.
FAQ
What is a NAV report?
A NAV report is a reporting pack that presents a fund’s net asset value as of a date and includes the supporting schedules needed to explain and validate it. It typically includes a rollforward, balance sheet style summaries, investment schedules, and investor-level tie-outs.
What should a NAV report include for private funds?
At a minimum, it should include fund NAV, a rollforward, a statement of assets and liabilities, an investment schedule, fee and expense schedules, capital activity summaries, and investor allocation tie-outs. Many teams also include valuation summaries and pricing exceptions.
What is the difference between NAV reporting and NAV accounting?
NAV accounting is the underlying accounting process and records (GL, trial balance, accruals, allocations). NAV reporting is the structured output and workflow that turns those records into a controlled reporting pack and investor deliverables.
How do you QC a NAV report?
QC should tie the NAV pack back to the trial balance, cash reconciliations, valuation support, and investor ledger totals. It should also include variance explanation and version control checks, not just internal worksheet checks.
Why does investor NAV not tie even if the fund NAV is correct?
Because investor NAV is the allocated share of fund totals. Transfers, class mapping, equalization, side letter terms, or late-posted capital activity can cause investor totals to drift even when the fund-level NAV appears correct.
How often should NAV reports be produced?
Many funds produce quarterly NAV reports for LP reporting. Some also produce monthly NAV packs for internal management reporting and controls. Frequency depends on fund terms, investor expectations, and the practicality of valuation updates.
Who should approve the NAV report?
Typically, preparation is done by fund accounting and investor services, and approval is done by an independent reviewer, such as a controller or senior reviewer. Complex funds may also require valuation approvals before final release.
