Home / Wiki / NAV Break
NAV & AccountingReviewed 2026-07-21

NAV Break

A discrepancy between what a fund's books expect an asset or NAV figure to be and what an independent source confirms it actually is.

Definition

A NAV break (or reconciliation break) is a discrepancy between what a fund's ledger expects a position or NAV figure to be and what an independent source — a live exchange balance, a wallet, a custodian statement, or a fund administrator's figure — actually confirms. It's a flagged mismatch for investigation, not automatically an error in either direction; the point of surfacing it is to figure out which side is wrong, or whether both are technically correct but measuring something slightly different, such as a timing difference.

Breaks are typically graded by severity against a defined materiality threshold, so that genuinely immaterial rounding or timing differences don't drown out the handful that represent a real data error worth correcting before NAV is treated as final.

Why it matters

A NAV break caught before publication is a minor operational task; the same break discovered after NAV has already been used to strike a subscription, a redemption, or a fee is far more disruptive to unwind, potentially requiring a correcting entry against an already-settled transaction. Catching breaks early is one of the main reasons funds run shadow accounting or a defined reconciliation process at all.

For LPs, a fund's break-resolution process — how quickly breaks are identified, how they're graded, and how they're documented — is a meaningful proxy for overall operational discipline, even though the breaks themselves are a completely normal part of running any accounting process against live external data.

Common causes and resolution lifecycle

Common causes include an unsettled trade that hasn't yet posted, a duplicated or missed deposit or withdrawal record, a stale or simply wrong price feed, a lag between when an exchange or wallet balance updates and when the ledger reflects it, or a fee or subscription posted to the wrong accounting date.

A typical lifecycle runs: identified (the discrepancy is flagged, usually automatically) → investigated (someone determines the actual cause) → resolved, either with a documented correcting entry — since ledgers in this space are typically append-only, so corrections are new reversing entries, not silent edits to an old one — or explicitly logged as immaterial and ignored with a reason. A break that recurs after being marked resolved or immaterial is generally reopened rather than logged as a fresh, unrelated break, since repetition is itself a signal something systemic is wrong.

Grading breaks by cause and typical severity

CauseTypical severity
Unsettled trade not yet postedLow — usually resolves automatically once settlement completes
Stale or wrong price feedMaterial — directly misstates NAV until corrected
Duplicated or missed deposit/withdrawalMaterial — directly misstates a cash or asset balance
Sub-cent rounding or timing lagImmaterial — typically logged and closed without a correcting entry

Common mistakes

  • Setting materiality tolerance too tight, so every sub-cent rounding or timing difference registers as a break and buries the small number of genuinely material ones.

  • Setting materiality tolerance too loose, letting a real data error slip through as 'immaterial' when it would actually misstate a subscription or redemption price.

  • Resolving a break by silently adjusting a balance rather than posting a documented correcting or reversing entry, which destroys the audit trail of what actually happened.

  • Treating every break as an error rather than distinguishing a genuine data mistake from a timing difference that simply hasn't settled yet.

In practice

Crypto reconciliation has failure modes traditional fund accounting rarely sees at the same frequency — a wallet balance that lags an on-chain transaction by a block or two, a price feed that's genuinely correct on one venue but stale relative to where the fund actually executed, or an exchange API that reports a balance net of an in-flight withdrawal differently than the ledger expects. A materiality floor calibrated for these near-constant small timing differences, rather than one borrowed unmodified from traditional finance, keeps the break queue focused on what actually needs attention.

Run your own period-end numbers through the free NAV Validator to see whether the roll-forward, fee math, and optional per-LP figures tie out the way a reconciliation process would check them.

Check your own roll-forward and fee arithmetic for the kind of discrepancy a NAV break process is designed to catch.

Try it free →

Questions, answered

What is a NAV break?

A NAV break is a discrepancy between what a fund's ledger expects a position or NAV figure to be and what an independent source — an exchange, wallet, custodian, or administrator — actually confirms. It's flagged for investigation rather than assumed to be an error on either side.

What typically causes a NAV break?

Common causes include an unsettled trade, a duplicated or missed deposit or withdrawal record, a stale or wrong price feed, a lag between an external balance updating and the ledger reflecting it, or a fee posted to the wrong date.

How are NAV breaks graded?

Breaks are typically graded by severity against a defined materiality threshold, so immaterial rounding or timing differences are distinguished from genuinely material errors that need a correcting entry before NAV is treated as final.

How is a NAV break actually fixed?

Through a documented correcting or reversing entry, not a silent balance adjustment — since fund ledgers are typically append-only, a correction is a new entry that offsets the error, preserving a full audit trail of what happened.

Related terms
/wiki/shadow-accounting
Shadow Accounting
/wiki/net-asset-value
Net Asset Value
/wiki/fund-administrator
Fund Administrator

Your next LP report,
on autopilot.

Get Started →Book a 20-min Call →

From $2,500/month · Everything included · Book a call

Related guides
Shadow NAV and Continuous Reconciliation for Emerging Crypto Funds: The Complete Guide

What a shadow NAV is, how double-entry reconciliation catches administrator errors, defensible tolerance gates, and the real cost vs. manual LP reporting.

What Is a Shadow NAV? Definition, Purpose, and How It Works

A shadow NAV is an independent parallel valuation crypto fund managers run alongside their administrator. Learn how it works, why it matters, and what it costs.

Shadow Accounting for Fund Managers: Why Run a Parallel Book

Shadow accounting means running a double-entry ledger independent of your administrator. See how typed breaks and deterministic NAV catch errors early.

Real-Time NAV vs. Monthly NAV: The Operational Risk Comparison

Monthly NAV can hide a stale price or sync failure for up to 30 days. Compare the operational risks of monthly vs. real-time crypto fund NAV.

Multi-Venue Reconciliation for Crypto Funds: Real Failure Modes

Quiet exchange API failures, wallet sync gaps, and venue collisions are the real risks in crypto fund reconciliation. See the failure modes and how to catch them.

How to Reconcile Exchange and Wallet Positions Against Your Fund Administrator

Step-by-step process to reconcile exchange and wallet positions against your fund administrator: pull, diff, grade materiality, investigate, and tie out.

NAV Discrepancy Tolerance Gates: How Much NAV Variance Is Acceptable?

NAV discrepancy tolerance for a crypto fund: four gates for completeness, ledger accuracy (5bps GAV), per-investor allocation, and pricing methodology.

Spreadsheets vs Shadow NAV Software: Why Excel Fails Emerging Funds

The real incumbent for emerging crypto funds is Excel, not a vendor. See the specific failure modes of spreadsheet NAV and how shadow NAV software closes them.