Asset ManagementCap TableFund OperationsPortfolio Analytics

The 2026 Cap Table & Portfolio Operations Playbook

Seven workflows where Finpy Asset Manager handles the cap table mechanics, deal pipeline, fund admin, and LP-side view on a single data model. Cross-org entities, double-entry security transactions, on-the-fly IRR and MOIC, audit ledger by default, and a Model Context Protocol layer that no other platform ships.

Finpy Team · June 22, 2026

Key takeaways

  • 1.The wedge. Cap table mechanics, deal pipeline, fund admin, and LP view sit on the same entity graph. No bolted-on integrations between four tools.
  • 2.Dual perspective. The cap table view (issuer side) and the position view (stakeholder side) read the same rows from opposite ends. Cross-org access is first-class.
  • 3.Per-entity pricing. Your first entity is free. Each additional entity is $6 per month. No per-seat charge for stakeholders or LPs.
  • 4.MCP-native. Connect Claude Desktop to mcp.finpy.tech/mcp and query your cap table in conversation. No competitor ships an MCP server.

Competitive map

Six tools cover slices of the workflow well. Each breaks somewhere important. The final row is what Finpy Asset Manager does about it.

ToolStrong onWhere it breaks
CartaCap table for single-entity startups; secondaries marketplace.Pricing scales with stakeholders, not entities. Each entity siloed. Weak portfolio analytics for VCs running many cap tables.
PulleyCap table UX; modern interface.Same per-seat trap as Carta. No cross-org stakeholder model. Single-entity focus.
AngelList StackRoll-up vehicles, fund admin combo for new managers.Closed ecosystem. You do not own the data layer. Outside syndicate members cannot join your vehicle.
eFront / AllvueEnterprise fund admin; deep institutional features.Six-figure price floor. Multi-month implementations. Wrong product for emerging managers and family offices.
Juniper SquareLP portal and investor reporting.Investor-relations first. Cap table mechanics are a second-class concept.
Visible.vc / AffinityPortfolio reporting and deal CRM.No cap table, no audit ledger, no double-entry. Adjacent stack components, not a unified platform.
Finpy Asset ManagerUnified data model: cap table mechanics, deals, fund admin, LP view on one entity graph. MCP-native.Pricing scales linearly with entities (acceptable up to ~100 portcos). Risks section below has the full list.

Why a fund operations team is the one writing this

Every workflow below ties back to a single data model. Cross-org entities, double-entry security transactions, on-the-fly performance computation. That is the engine we run at Finpy Asset Manager, the platform behind this analysis. Open the live dashboard and the same workflows are one click away.

Open the live dashboard

Three workflow threads

Seven case studies grouped by what they exercise. Fundraising mechanics, portfolio operations, and an AI-native workflow that no competitor matches.

Fundraising mechanics

Cross-org Seed raises, multi-tranche Series B deals, and syndicate workflows. The data model treats the cap table as a double-entry ledger and lets stakeholders own their own accounts.

Portfolio operations

Fund-level performance computation across many portfolio companies. Look-through ownership for fund-of-funds. Structured financial data per portco rolling up to fund-level NAV.

AI-native workflows

Agentic AI access to fund data through the Model Context Protocol. The cap table, the deal pipeline, the income statements all become first-class context for Claude, Cursor, and any other MCP-aware client.

What Finpy Asset Manager delivers

Dual-perspective cap table. Every entity carries both the issuer view (this is my cap table) and the stakeholder view (these are my positions). Cross-org access is a first-class concept, not a workaround. A founder, a fund, and an LP all see the same transaction from their own angle.

Double-entry security ledger. Every transaction records the debit side and the credit side, in both units and dollars. The cap table is reconstructed by adding up the transactions, not by snapshotting and diffing. Partial transfers, complex conversions, and warrant exercises all express cleanly.

Per-entity pricing. First entity free; each additional entity $6 per month. No per-stakeholder surcharge. A fund running 20 portfolio companies pays $114 per month including the fund entity itself. Pricing does not penalize fundraising.

Fundraising · Case 1 of 7vs Carta per-seat

The cross-org Seed raise

A startup raises Seed without paying a per-stakeholder surcharge for each investor on the cap table.

Entity
Startup Inc.
free first entity
launches
Deal
Seed round
active
invites
Stakeholders
5 investors
own their accounts
maintain
Positions
Dual view
issuer + LP
Cost to issuer
$0
Stakeholders per round
5
Account model
Self-owned

Each stakeholder on the cap table points back to a separate Finpy account owned by the investor. The issuer pays nothing extra for adding stakeholders. Every LP signs up on their own free entity and sees their positions from their side. The same cap table row renders differently depending on who is reading it.

Finpy

  • Per-entity pricing leaves stakeholder count unconstrained
  • LPs maintain their own accounts at no cost to the issuer
  • Dual-perspective view: issuer reads the cap table, LP reads positions, both reference the same rows
  • Cross-org access controlled per role: Owner, Admin, Editor, Viewer

Typical competitor

  • Carta typically charges per stakeholder for active cap tables
  • Per-seat models punish founders for fundraising success
  • Closed platforms make LPs subordinate accounts of the issuer
Cross-org invitations
Invite an outside organization or request access to theirs. Same data layer underneath.
Role-based access
Four roles enforced at the data layer per org-entity pair.
Audit trail per row
Every cap table change recorded with before/after snapshots.
Verdict

The pricing wedge is real and the dual-perspective model is the structural reason it works.

Fundraising · Case 2 of 7vs single-security rounds

Series B with five tranches

One funding round issues five distinct securities, each with its own terms. The cap table reconciles by double-entry, not snapshot diff.

Deal
Series B
multi-tranche terms
executes to
Funding Round
B-2026
on execute
issues
Securities
5 distinct
per-tranche terms
records
Transactions
Debit / credit
one per investor
Securities per round
Unlimited
Ledger model
Double-entry
Cap table source
Aggregation

Asset Manager handles every security type on one unified schema. A multi-tranche Series B issues five distinct securities (Series B-1 Preferred at $20 with 1x liquidation, Series B-2 with 1.5x participation, Series B-3 convertible, and two warrant tranches). Each security gets its own transactions with debit and credit recorded in both units and dollars. The cap table is the running total of these transactions at a point in time.

Finpy

  • Seven security types on one schema: common, preferred, convertible, SAFE, warrant, option, bond
  • Every transaction records both sides of the trade in units and in dollars
  • Securities tie back to the funding round that issued them; deleting the round is blocked while transactions exist
  • Cap table view computed on demand from transactions, not stored as a snapshot

Typical competitor

  • Most cap table tools collapse a multi-tranche round into one security row with notes
  • Snapshot-based platforms cannot express partial transfers or staged conversions cleanly
  • Single-security-per-round assumption fails on real venture rounds
Seven security types
common, preferred, convertible, SAFE, warrant, option, bond.
Double-entry ledger
Every transaction records the debit side and the credit side, in both units and dollars.
Point-in-time snapshots
Optional historical captures for audit and reporting reads.
Verdict

The double-entry ledger is the reason cap table mechanics survive contact with messy round structures.

Fundraising · Case 3 of 7vs closed RUV ecosystems

The syndicate with cross-org members

A syndicate vehicle has members from five different organizations. Each member sees the syndicate positions; the carry waterfall splits on the stakeholder distribution tiers configured at setup.

Entity
Syndicate
set up as a fund
admits
Members
5 outside orgs
each owns their org
configures
Carry
Distribution tiers
waterfall split
enforces
Reporting
Per-member view
isolated by role
Member orgs
5
Carry mechanism
Native
Data ownership
Per-member

A syndicate is just an entity set up as a fund. Its members reference outside Finpy accounts; each member retains full ownership of their own organization. The carry waterfall is built in: ordered distribution tiers, carried interest percentages, and catch-up rates are all native fields on each stakeholder. Members can leave; the syndicate continues; the data does not move.

Finpy

  • Members bring their own accounts; the syndicate cannot lock them in
  • Carry waterfall is native: ordered distribution tiers split distributions automatically
  • Cross-org membership controls access without merging organizations
  • Cap table view per member shows only what their role permits

Typical competitor

  • AngelList Stack runs a closed roll-up vehicle ecosystem
  • Closed platforms make member exit difficult and data export limited
  • Outside syndicate members cannot bring their existing accounts
Cross-org membership
A role-based link from any organization to any entity, spanning org boundaries.
Native carry waterfall
Distribution tiers, carried interest, and catch-up rates live on each stakeholder.
Granular role gates
Owner, Admin, Editor, and Viewer roles enforced per organization-entity pair.
Verdict

Open data ownership is the difference between a platform and a closed network.

Portfolio ops · Case 4 of 7vs overnight batch

Fund with 20 portfolio companies, IRR computed live

Each portfolio company is a tracked Entity. Performance metrics (IRR, MOIC, TVPI, DPI) compute on demand from the same data the cap table runs on.

Fund
Fund I
parent entity
holds
Holdings
20 portcos
tracked Entities
records
Cash flows
Investments & distributions
debit / credit
computes
Performance
IRR / MOIC / TVPI
on-the-fly
Portcos tracked
20
Refresh cadence
Query-time
Metrics surfaced
IRR · MOIC · TVPI · DPI

Each portfolio company is a holding linked back to a target entity and a parent fund. Investments and distributions record with full debit and credit semantics. IRR, MOIC, TVPI, and DPI compute at the moment of the query, not in a nightly batch. A new mark-to-market triggers fresh performance immediately.

Finpy

  • Performance computation runs on the same data the cap table reads
  • No overnight batch; the dashboard reflects the latest fair value as soon as it lands
  • Each cash flow carries a flag for whether it belongs in the IRR calculation
  • Optional point-in-time performance snapshots when needed for audit

Typical competitor

  • Enterprise fund admin platforms typically batch IRR overnight
  • Reconciliation between cap table system and fund admin system is the standard pain
  • Portfolio companies as PDF uploads rather than structured entities
Finpy On-the-Fly Performance
IRR / MOIC / TVPI / DPI computed at query time.
Unified Holding model
Investment positions and business lines on one schema.
Performance snapshots
Optional point-in-time captures for audit and reporting.
Verdict

The same data drives the cap table and the IRR. The reconciliation problem dissolves.

Portfolio ops · Case 5 of 7vs single-level cap tables

Fund-of-funds look-through

Fund A holds Fund B; Fund B holds four portcos. The look-through query traverses both levels and surfaces underlying exposure to a specific company.

Fund A
Top fund
investor in Fund B
holds
Holding
Fund B
as a portfolio position
has
Fund B
Sub fund
4 portco holdings
resolves to
Exposure
Underlying portco X
computed share
Levels traversed
2
Portcos visible
4
Ownership math
Computed

Fund A is a stakeholder on Fund B cap table. Fund A also has a holding pointing at Fund B as a position. Fund B in turn holds four portfolio companies. The look-through query walks Fund A holdings, identifies the ones whose target is itself a fund, and resolves to the underlying portco set with computed ownership percentages.

Finpy

  • Entities can reference each other as parents, modeling multi-level fund structures natively
  • A holding link preserves the relationship even if the sub-fund later leaves the platform
  • Look-through is a property of the data model, not a bolted-on report
  • Family offices and fund-of-funds get the same traversal as primary funds

Typical competitor

  • Single-entity cap table tools cannot represent multi-level fund structures
  • Investor-relations platforms treat sub-fund relationships as PDF attachments
  • Reporting tools that pull from accounting systems lose the entity graph
Self-referencing entities
Entities can be parents of other entities; holdings can target funds. The graph is native.
Multi-level traversal
Holdings of holdings resolve recursively.
Family office support
Same traversal works for any multi-fund structure.
Verdict

Look-through ownership only works if the data model is a graph. Most competitors model it as a list.

Portfolio ops · Case 6 of 7vs PDF financials

Portfolio financial drill-down

Each portfolio company files an income statement, a balance sheet, and a cash flow statement every quarter. Custom KPIs (ARR growth, gross margin, burn) roll up to fund-level valuations.

Portco
Company entity
tracked Entity
files
Statements
IS · BS · CF
structured rows
tracks
KPIs
Custom metrics
per period
feeds
Rollup
Fund Valuation
updated NAV
Statement types
4
KPI definitions
Custom
Rollup target
Fund NAV

Financials enter as structured rows per portfolio company per period: income statement, balance sheet, cash flow statement, and a derived metrics layer. KPIs are defined once and tracked quarter over quarter. Updated valuations attach to the holding; the fund-level NAV reads the aggregated valuations across the portfolio.

Finpy

  • Four financial statement types fully structured (income, balance, cash flow, metrics)
  • Custom KPIs let each portfolio company report what matters in its business model
  • Each KPI value carries a scenario tag: actual, forecast, or budget
  • Updated valuations feed both the cap table and the fund NAV

Typical competitor

  • Most fund admin platforms accept financials as PDF uploads
  • PDF financials cannot be queried, compared, or aggregated
  • Portfolio reporting tools treat KPIs as static dashboard widgets
Structured financials
Income statement, balance sheet, cash flow statement, and a derived metrics layer.
Custom KPIs
Define a metric once, track it every quarter with actual, forecast, and budget scenarios.
Updated valuations
Mark-to-market entries feed the fund NAV computation directly.
Verdict

Structured rows beat PDFs. The fund admin platforms that treat financials as documents lose the analytics layer.

AI-native · Case 7 of 7vs no MCP server

Show me my cap table (Claude + MCP)

A user opens Claude Desktop, connects mcp.finpy.tech/mcp, and types "show me my Series B cap table". The agent calls the right tool and renders the result.

User
Claude Desktop
or Cursor / Code
talks to
Protocol
MCP
mcp.finpy.tech/mcp
queries
Engine
Finpy backend
authenticated
returns
Response
Cap table rows
structured
Tool count
67+
Auth model
OAuth device flow
Competitors with MCP
0

The MCP server is a first-class surface on the same data the dashboard reads. It exposes 67 tools covering create, read, and update across every Finpy Asset Manager entity. The user types a natural question; Claude selects the tool; the answer is the structured data, not an opinion. The same server handles "create a stakeholder John Doe", "set the fair value of Acme Corp to $10M", and "show me Q4 revenue across all portcos".

Finpy

  • OAuth device flow for clean authentication from Claude / Cursor / Code
  • 67+ tools cover the full CRUD surface across cap table, deals, holdings, financials
  • Same data model as the dashboard; no separate AI export pipeline
  • Tool selection driven by the agent; the user does not memorize API endpoints

Typical competitor

  • No competitor ships an MCP server today
  • Carta has an API but no agentic interface
  • Most fund admin platforms only expose data via PDF reports or CSV exports
finpy-mcp PyPI package
Open source, version pinned, installable via pip or uvx.
OAuth device flow
Clean per-user authentication into your Finpy data.
Agentic conversation
The cap table becomes context for any MCP-aware AI client.
Verdict

The MCP wedge will not be a wedge forever, but as of June 2026 no other platform ships it.

What links these seven

Seven workflows. One data model. Same Entity graph underneath every case.

  • ·Entity graph. Funds, companies, individuals, and syndicates all live on one shared schema, with parent-child relationships built in. Fund-of-funds and family office structures are first-class, not edge cases.
  • ·Double-entry ledger. Security transactions and portfolio cash flows share the same debit and credit convention. The cap table and the fund performance read the same data.
  • ·Cross-org access. Memberships and invitations span organizations natively. Stakeholders own their own accounts as a structural property of the platform, not as a workaround.
  • ·Audit by default. Every record carries timestamps and tracks who created, updated, or deleted it. The audit log captures before-and-after snapshots of every change. The compliance team does not need a separate tool.

Try it yourself

Open the live dashboard, create your first entity (free), and run any of the seven workflows above. For the AI-native one, connect Claude Desktop to the Finpy MCP server and type the question you would ask your fund analyst.

Open the live AssetManager dashboard

The MCP server is at mcp.finpy.tech/mcp. Connect from Claude Desktop, Cursor, or any MCP-aware client. The companion Factor Markets engine is on the 2026 Value Landscape article.

How the data model works

Every record on the platform carries the same five things: a created timestamp, an updated timestamp, an optional deletion timestamp, plus the user identifiers of whoever created, updated, or deleted it. Deletions are soft by default; the application layer never hard-deletes. Ownership relationships cascade when the parent goes away; financially critical relationships (funding rounds, securities) refuse to delete while transactions depend on them; audit-preserving relationships keep the record alive even after the target it pointed to leaves the platform.

The cap table is reconstructed by adding up the security transactions for an entity at a point in time. The fund performance is computed by aggregating the cash flows for a fund through a chosen report date. Optional point-in-time snapshots exist for audit and reporting; the live view does not depend on them. KPI values store quarterly metrics with full scenario support (actual, forecast, budget) so the same number can carry three readings. The MCP server is a thin layer on the same backend endpoints the dashboard uses; no separate AI pipeline.

What could go wrong

  • ·Linear pricing. $6 per entity per month adds up. A fund with 100 portfolio companies pays around $600 monthly. That is still well below enterprise fund admin pricing, but the per-entity model is not free.
  • ·Not a substitute for an audit firm. The audit ledger helps reconcile and trace changes; it does not produce a regulator-signed opinion. Year-end audit still happens with a CPA firm.
  • ·MCP integration is new. The protocol itself is months old. Tooling matures monthly; some clients have rough edges. The dashboard remains the primary surface for users who prefer a UI.

Built by a team that runs the platform every day

Finpy Asset Manager unifies cap table mechanics, deal pipeline, fund admin, and the LP-side view on one entity graph. Per-entity pricing, no per-seat ceiling. First entity free. Built for emerging managers and multi-fund family offices, opened to anyone who wants the same workflow without the legacy fund admin price tag.

Explore Finpy Asset Manager

Author positioning

Finpy Team. Finpy Asset Manager is a paid product from Finpy Tech. The dashboard view shown in the examples is the same view paying customers use. Pricing is per-entity (first entity free, $6 per additional entity per month). Competitor claims sourced from public product pages and review sites as of June 22, 2026.

Nothing on this page is legal, tax, or investment advice. The data model details described above are accurate to the platform as of the publish date and will evolve. The MCP integration is in active development. Workflow descriptions are not promises of future features. Talk to your own fund admin, tax, and legal advisors before relying on any platform for fund operations.