From raw accounting data to investor KPIs: our reporting logic explained

Investor reporting should feel simple:

• What is the portfolio doing?
• What changed this month?
• What is the risk (cash, covenants, refinancing, leasing)?
• What returns are we generating-and how confident are we?

But if your portfolio sits across 10/25/100 SPVs, the reality is that the "truth" is fragmented. Each SPV has its own chart of accounts, timing, bank accounts, and edge cases-so creating consistent investor KPIs becomes a monthly rebuild.

This post explains the reporting logic we use to get from raw accounting data to investor-grade KPIs-in a way that is consistent, repeatable, and drillable.

---

Why investor KPIs break in multi-SPV portfolios

Most reporting issues are not "accounting errors." They are meaning errors:

• "Maintenance" means different things across SPVs
• capex vs opex gets coded inconsistently
• cash is reported without splitting restricted/trapped balances
• NOI definitions drift between packs
• portfolio totals are built in spreadsheets, not systems
• operational drivers (occupancy, arrears) live outside the GL

So two problems appear:

1. The numbers are hard to consolidate consistently
2. The commentary is hard to justify confidently

The fix is not "more reporting." It is a standardised reporting logic layer above the raw accounting data.

---

Our core principle: one truth, many views

We start with a simple design goal:

A portfolio KPI should always be traceable back to SPV-level source data-without reinterpreting it every month.

That means our logic separates three things:

1. Source data (what the accounting system says)
2. Reporting meaning (what it means in your portfolio model)
3. Investor outputs (how that meaning is presented: KPIs, packs, commentary)

---

The pipeline: Raw -> Normalise -> Map -> Consolidate -> Calculate -> Explain

Step 1: Ingest the raw SPV accounting data

We begin at SPV level, because that is where legal entities, bank accounts, and debt typically sit.

Inputs we rely on (minimum viable):

• Trial balance (and/or ledger detail) per SPV
• Bank balances (ideally reconciled)
• Debt schedules (balances, rates, maturities; covenant definitions where applicable)
• Optional but high-value operational inputs: occupancy, arrears, capex pipeline

Why this matters: AI, dashboards, and packs are only as trustworthy as the base inputs. If cash is not tied to the bank, your "net debt" and runway story will be wrong.

Step 2: Normalise messy reality without rewriting your bookkeeping

We do not ask teams to rebuild their accounting system to get portfolio reporting.

Instead we normalise:

• naming conventions (so reporting is readable)
• time periods and cutoffs (so comparisons are meaningful)
• key classifications (so NOI and capex do not drift)

This is where you reduce "spreadsheet glue work" that happens every month.

Step 3: Map each SPV chart of accounts into a standard reporting structure

This is the heart of consistent portfolio reporting.

Definition
A mapping links SPV accounts -> standard portfolio reporting lines (for example, "Property Maintenance", "Utilities", "Management Fees", "Financing Costs").

Common mistake
Teams try to standardise every SPV's bookkeeping chart first (slow), or they map "just for this month's pack" (not reusable).

Best-practice reporting

• A stable standard reporting structure
• A mapping table per SPV that can be reused every month
• Version control on mapping changes (so trends do not silently break)

This is how you get apples-to-apples reporting across dozens of entities.

Step 4: Consolidate across SPVs with explicit rules

Once accounts are mapped, we can consolidate reliably.

What consolidation means in management reporting

• Roll up performance across SPVs into portfolio totals
• Support both portfolio-level and SPV-level views
• Handle ownership rules (100% view plus investor share, or pro-rata-defined explicitly)

Common mistakes

• Portfolio "totals" built via manual exports and copy-paste (fragile, non-auditable)
• Mixing entities that are not closed yet with final entities (no completeness visibility)
• Ignoring intercompany, then wondering why balances do not make sense

Best-practice reporting

• A close completeness flag ("which SPVs are final vs estimated")
• Clear ownership basis used consistently
• Intercompany treated explicitly (eliminate when reliable, otherwise isolate transparently)

Step 5: Calculate investor KPIs from the standardised reporting layer

Once the portfolio view is consistent, KPIs become definition-driven instead of "prepared-by" driven.

Below are examples of common investor KPIs and the logic we apply.

---

KPI logic examples

1) NOI

Definition (typical)
NOI = Revenue - Operating Expenses (excluding financing, tax, and usually excluding capex)

Common mistakes

• capex creeping into operating costs (or vice versa)
• one-offs treated inconsistently month to month
• NOI definition changing between internal and investor reporting without a bridge

Best-practice reporting

• A published NOI definition (what is in / what is out)
• A consistent classification rule set enforced via mapping
• Optional "NOI (underlying)" view with one-offs clearly tagged

2) Cash that is actually usable

Definition (minimum viable)
Split cash into:

• Unrestricted cash (usable)
• Restricted cash (DSRA, escrow, tenant deposits, etc.)
• (Often) Trapped cash (technically cash, but not realistically transferable due to covenants/structure)

Common mistakes

• reporting "total cash" as if it is deployable
• subtracting restricted cash when calculating net debt (or worse: ignoring restrictions entirely)

Best-practice reporting

• Portfolio cash always shown with restrictions split
• Cash drill-down: portfolio -> SPV -> bank account (and restrictions label)

3) Net debt and gearing / LTV

Definition (typical)

• Net debt = Total debt - usable cash
• LTV = Debt / Asset value (valuation basis and date must be disclosed)

Common mistakes

• using net debt based on total cash (ignores restrictions)
• presenting LTV without the valuation date (or mixing valuation dates across assets)
• showing only portfolio averages when covenants bite at facility/SPV level

Best-practice reporting

• Net debt uses only usable cash
• LTV always labelled with valuation basis/date
• Covenant ratios/headroom tracked at facility/SPV level first, then rolled up

4) Capex: spent vs committed (the cash-trough predictor)

Definition

• Spent capex = cash outflow already incurred
• Committed capex = approved/contracted pipeline not yet spent

Common mistakes

• reporting only what was spent this month, missing what is contractually coming next
• mixing refurb programmes into OpEx in some SPVs and Capex in others

Best-practice reporting

• Capex dashboard shows spent + committed + remaining budget
• Timing view for the next 4-8 weeks (what hits cash soon)
• Consistent capex vs opex rule set (enforced via mappings)

5) Returns and "% of capital returned"

Definition (example)

• Capital returned % = Cumulative distributions / Initial equity invested
• Or a broader equity bridge: invested -> returned -> remaining invested/NAV

Common mistakes

• mixing realised cash returns and valuation-driven changes without separating them
• presenting return metrics without linking to cash constraints (cash may be trapped in SPVs)

Best-practice reporting

• Clear split between cash returned vs unrealised movement
• Distribution capacity shown alongside liquidity and covenant constraints

---

Step 6: Explain the numbers with controlled, traceable commentary

Once KPIs are grounded in mapped categories and definitions, commentary becomes safer and more useful.

This is where modern finance teams increasingly want AI support-but only in the right place in the stack:

• AI can draft "what changed" and highlight exceptions
• Humans approve
• Each statement should be traceable back to mapped reporting lines and underlying numbers

That is how you get speed without giving up control.

---

The trust layer: what makes the logic audit-friendly and repeatable

The difference between "a KPI" and "an investor KPI" is trust. Our reporting logic is designed to support:

• Drill-down: KPI -> reporting line -> SPV -> account -> source
• Definition clarity: NOI, cash, net debt, LTV, occupancy all explicitly defined
• Change control: mapping and definition changes are tracked (so trends remain meaningful)
• Completeness visibility: which SPVs are included, which are estimated, which are missing

This is also why our foundation is multi-entity consolidation with standardised mapping-because it powers dashboards, packs, forecasting, scenarios, and (when appropriate) AI commentary on top.

---

What this enables beyond reporting

Once the reporting logic is stable, it compounds:

• A one-stop portfolio view across SPVs
• Standardised roll-ups for investor packs
• FP&A: budgets, forecasts, cash planning
• Scenario planning: rates, occupancy shifts, refurb programmes
• Automated narrative generation grounded in your mapped accounts and controls

---

Closing thought: investor KPIs are a logic problem, not a formatting problem

If investor reporting feels painful, it is usually because your portfolio's "meaning layer" is missing:

• mappings to standardise categories
• definitions to stabilise KPIs
• clean inputs and reconciliation discipline to keep the base trustworthy

Get those foundations right, and the path from raw accounting data to investor KPIs becomes repeatable-and scalable.