Accounting Foundations (ASC 946 / ASC 820)

Because a venture fund is an investment company under US GAAP, it accounts under ASC 946: investments are carried at fair value, and each period’s change in fair value is recognized as unrealized appreciation/depreciation flowing through the statement of operations and into each partner’s capital account. Fair value itself is measured and disclosed under ASC 820, which defines the three-level input hierarchy and requires level disclosures, transfer tracking, and a Level 3 rollforward.

OpsDNA committed to this framework as an architectural foundation (docs/adrs/0005-asc-946-820-fair-value-accounting.md) rather than bolting fair value on later. That decision shapes the ledger, PCAP, and statements layers in concrete ways described below.

Marks are first-class GL entries — never side data

When a position is re-marked, the system does not stash a number in a valuations table off to the side. It produces a fair_value_adjustment journal entry through the same source→ledger pipeline everything else uses:

Dr/Cr  investment (asset)        → to the new fair value
   Cr/Dr  unrealized_gain_loss   → the offset

In the ledger catalog the asset leg posts to a dedicated canonical account kind, so the mark never mixes with cost basis:

// packages/ledger/src/kernel.ts — seeded catalog
{
  accountId: "account:1450-investment-fair-value-adjustment",
  code: "1101",
  name: "Investment - Unrealized Gain/Loss",
  accountType: "asset",
  normalBalance: "debit",
  statementSection: "assets",
  // ADR-0017 Phase 0: the fair_value_adjustment posting kind carries a
  // kernel leg-shape expectation keyed on canonical kinds.
  canonicalAccountKind: "investment_fair_value_adjustment",
}

(investment_fair_value_adjustment was added by migration 0204, OPS-102, so fair-value marks post their asset leg to 1450 while 1100 Investment at Cost keeps the cost basis — see packages/ledger/src/account-selector.ts.)

That posting projects into per-LP unrealized_gain_loss component balances, the “Net unrealized gain” PCAP cell, and the Schedule of Investments (SOI) fair-value line. Because the mark is a GL entry, the statements can never disagree with the valuation register — they are derived from the same rows.

Every mark carries:

• the methodology used,
• the ASC 820 level — a property of the measurement (the lowest level of input significant to it), not of any single document, and it can migrate over time (a fresh priced round ages into a model-driven Level 3 mark),
• references to the supporting evidence (a priced-round SPA, an observable secondary, a comp analysis, a 409A).

The ASC 820 level framework (ratified 2026-06-03)

The level-assignment policy was ratified with the fund’s auditor basis (Frank Rimerman) and accounting authority (Gagan) — see ADR-0005:

The evidence-sufficiency control: an OpsDNA-suggested mark inherits its level from the evidence already on file; a user-initiated mark must supply corroborating evidence of the proper document type or it defaults conservatively to Level III. The evidence→level mapping and sufficiency thresholds are configurable policy (accounting governance, OPS-100), not hard-coded — refinements edit the policy config, not the schema.

Because the level is tracked per mark, the required ASC 820 disclosures — level classification, transfers between levels, the Level 3 rollforward — are derivable from the marking register rather than reconstructed by hand. The implementations live in packages/ledger/src/: asc-820-level-classification.ts, asc-820-transfers-between-levels.ts, asc-820-level-3-rollforward.ts, nav-practical-expedient.ts.

Realized vs. unrealized reconcile by construction

On realization, accumulated unrealized appreciation reverses and the realized gain books. The SOI and PCAP therefore carry both a “Net realized gain” and a “Net unrealized gain” row, and they reconcile — the interplay is modeled explicitly, not left to a report-time subtraction.

The venture economics invariants (ADR-0011)

The fee/carry engines implement the domain ruling recorded in docs/adrs/0011-venture-waterfall-fee-and-carry-economics.md. The invariants (true for essentially every venture fund) are built as fixed behavior; the per-LPA variability is built as configuration (see Policy IR):

• Management fee base = committed capital. Always. Never invested, NAV, or cost; a committed-but-unfunded LP is charged fees. Step-downs after the investment period are near-universal and configurable.
• No preferred return and no hurdle — ever, in venture. The engines refuse pref/catch-up-shaped tiers under the venture profile (ADR-0019 §6).
• Carry accrues on marks every period, as a GP↔LP reallocation in the partners’-capital subledger, off the P&L (ADR-0009). Markdowns floor the accrual at zero — never negative.
• Clawback: 100%, always. Carry accrues but is not distributed until the fund has returned 1× of LP capital including management fees — a return-of-capital gate, not a preferred return.
• Carry computes per partner_account, then sums. Each account runs the cascade on its own pro-rata slice at its own terms; fund total = Σ per-account. Exemption is a 0% partner_class — economics are read from partner_class, never partner_role. (Computing a fund-level carry and then allocating it pro-rata double-counts a carry-free partner’s slice — the OPS-251 bug.)
• Stepped (“escalating”) carry computes marginally (2026-06-30 amendment): gain up to the return-multiple threshold at the lower rate, gain above at the higher rate — not one rate applied to the whole base.

Read docs/adrs/0005-asc-946-820-fair-value-accounting.md before touching valuation, marks, unrealized gains, or the Schedule of Investments — the repo’s CLAUDE.md makes this mandatory.

Next: how calculation decisions become durable, hashable records — Canonical Application Records.