Scalable Unit of Impact — A Framework for Climate Finance

• Chapter 1: Introduction
• What is a Scalable Unit of Impact?
• The Valuation Gap in Climate Finance
• How SUI Solves the Cost of Capital Trap
• Chapter 2: The SUI Framework
• The Five Criteria of a SUI
• Comparison with Existing Impact Frameworks
• The Parameterized SUI Protocol
• Chapter 3: The SSOT Architecture
• What is a Single Source of Truth (SSOT)?
• The Three-Tier Validation Pipeline
• The Digital Twin for Impact Verification
• Chapter 4: Financial Mechanisms
• How SUI Reduces WACC
• The Greenium and Verified Impact
• Blended Finance and First-Loss Guarantees
• MDB Taxonomy Alignment
• Chapter 5: Case Studies
• Becaps (Argentina) — Chemical Displacement per Hectare
• MubOn (Colombia) — kWh Delivered per Charging Point
• Applying SUI Across Sectors
• Chapter 6: The CTH VRF Integration
• SUI in the Venture Readiness Framework
• Scoring Rubric for SUI Assessment
• Implementation Guide for CTH Startups
• Chapter 7: Course — SUI Fundamentals
• Module 1: Impact Measurement Foundations
• Module 2: Defining Your SUI
• Module 3: Building Your SSOT
• Module 4: Connecting Impact to Finance
• Module 5: Verification and Audit

Chapter 1: Introduction

What is a Scalable Unit of Impact?

What is a Scalable Unit of Impact?

Why "Unit"?

Impact measurement has long operated at the portfolio or programme level — reporting aggregate tonnes of CO₂ avoided, number of beneficiaries reached, or hectares restored. This aggregate view serves narrative purposes but fails investors who need to price risk at the asset level. The SUI concept borrows from the logic of the unit of account in accounting and the unit test in software engineering: before you can trust the aggregate, you must be able to verify the smallest repeatable element.

A SUI is, in essence, the atomic unit of an enterprise's impact claim. If the SUI is well-defined, the enterprise's total impact claim is simply the count of successful SUI applications multiplied by the per-application magnitude — an equation any investor or auditor can verify.

Why "Scalable"?

The word "scalable" does two things in this definition:

1. Replicability: The same unit — defined with the same parameters and verified against the same baseline — must be producible in application 1 and application 1,000,000. If the unit changes materially as the enterprise scales, it is not a SUI; it is a project-specific estimate.
2. Financial leverage: A verified, replicable unit of impact is the building block for financial instruments — green bonds, blended finance tranches, results-based payments — that reward scale. The SUI is scalable not just operationally but financially.

What a SUI Is Not

Concept	What it measures	Why it is not a SUI
ESG Score	Portfolio-level rating	No attribution to a single product application; not verifiable at unit level
Carbon Credit	Verified tonne of CO₂e avoided or removed	Closest analogue, but credits are typically aggregated project-level, not per-application
SDG Alignment	Goal-level contribution claim	No quantitative unit; does not support financial instrument design
KPI / Output Metric	Activity measure (units sold, sessions held)	Outputs, not outcomes; no baseline or counterfactual
IRIS+ Metric	Standardised indicator (e.g., PI7685)	Defines what to measure but not the per-application verification protocol

The SUI in One Sentence

If a company can say: "Every time a farmer applies one dose of our biostimulant to one hectare, we displace 102.4 kg CO₂e of synthetic fertiliser — verified against a documented counterfactual by an independent third party, recorded in our Single Source of Truth system, and accumulated into an auditable impact ledger" — that company has a SUI.

Historical Context

The SUI concept emerges from the convergence of three trends that matured between 2018 and 2025:

1. Impact measurement standardisation — IRIS+ 5.x, TNFD, IFVI, and AIMM created common taxonomies that made cross-company comparison possible for the first time.
2. Blended finance structuring — Results-based finance instruments (Development Impact Bonds, Green Outcome Bonds) demonstrated that verified impact units could trigger financial flows, creating demand for reliable unit-level verification.
3. Climate startup ecosystems — Accelerators like ClimateLaunchpad and MassChallenge began encountering hundreds of startups making impact claims that investors could not price. The SUI emerged as a practical answer to the question: "What is the smallest verifiable thing your product does?"

The Valuation Gap in Climate Finance

The Valuation Gap in Climate Finance

The Asymmetric Information Problem

Classical finance theory (Akerlof, 1970; Myers & Majluf, 1984) tells us that information asymmetry between founders and investors raises the cost of capital. When an investor cannot independently verify a startup's core value claim, they apply a risk premium that reflects this uncertainty. For technology startups, the core value claim is usually a product or market thesis that can be tested with pilots and revenue data. For climate startups, the core value claim is an impact thesis — and that is vastly harder to verify.

The result: two startups with identical financial profiles but different impact verification capabilities will receive different valuations. The one with verified, auditable impact units receives a lower risk premium. The one whose impact is asserted but not verified pays a cost-of-capital penalty that compounds over every subsequent financing round.

Scale of the Problem

Convergence Finance (2024) tracked 1,123 blended finance transactions totalling $213 billion since 2010. Yet demand for climate finance is estimated at $4–7 trillion annually through 2030 (IPCC AR6). The gap is not a supply problem — institutional capital has declared commitments of trillions — it is a deployment problem. Capital cannot flow at speed to assets it cannot price.

• Only 2% of total climate finance has reached Least Developed Countries (LDCs) despite their outsized vulnerability
• Early-stage climate startups (pre-Series A) represent less than 8% of climate finance flows despite producing the majority of innovative solutions
• The average time from climate startup founding to first institutional impact investment is 6.2 years (Pitchbook, 2024) — a pipeline drying period where many startups pivot to conventional markets or collapse

Three Layers of the Valuation Gap

Layer 1: The Communication Gap

Startups use inconsistent vocabularies to describe impact. One company calls its product "carbon-neutral"; another claims "net-zero supply chain"; a third reports "avoided emissions." These terms are not interchangeable, do not map to a common taxonomy, and cannot be aggregated by a portfolio manager. Investors cannot compare, so they discount all equally.

Layer 2: The Verification Gap

Even when startups use standard terms (e.g., IRIS+ indicators), the underlying data is typically self-reported without third-party verification. The impact number in a pitch deck is almost never auditable against a documented methodology, a baseline, and a counterfactual. Without this, the investor's legal department cannot include impact claims in fund documentation — so impact does not affect pricing.

Layer 3: The Instrument Design Gap

Impact-linked financial instruments (Green Bonds, Social Impact Bonds, Results-Based Finance) exist and are growing. But they require pre-agreed, verifiable metrics as trigger conditions. A startup without a defined SUI cannot access these instruments, even if its underlying impact is substantial. It is locked out of the fastest-growing segment of impact capital because it cannot speak the instrument's language.

The Cost: A Back-of-Envelope Calculation

Consider a climate startup that raises a $5M Series A at a 25% equity dilution. If verified impact reduced investor uncertainty and brought dilution to 20% — a conservative greenium estimate — the founder retains an additional 5% of the company. At a $50M exit, that is $2.5M in value destroyed purely by the verification gap. Across a portfolio of 100 such startups, the aggregate value destruction exceeds $250M — none of it inevitable.

How SUI Addresses Each Layer

Gap Layer	SUI Response
Communication Gap	SUI forces mapping to an established taxonomy (IRIS+, TNFD, AIMM) at definition time, creating a common language
Verification Gap	SUI requires third-party validation against a Single Source of Truth (SSOT) — the impact claim is auditable by design
Instrument Design Gap	A verified SUI is a ready-made trigger metric for results-based financial instruments; the startup can engage instrument designers immediately

---

Next: How SUI Solves the Cost of Capital Trap — the SUI-WACC hypothesis explained.

How SUI Solves the Cost of Capital Trap

How SUI Solves the Cost of Capital Trap

Understanding WACC for Climate Startups

The Weighted Average Cost of Capital is the blended rate a company must return to its capital providers — equity holders and debt holders — weighted by their respective shares of the capital structure. For a climate startup:

WACC = (E/V) × Re + (D/V) × Rd × (1 - Tc)

Where:
  E = Equity value
  D = Debt value
  V = E + D (total capital)
  Re = Cost of equity (investor required return)
  Rd = Cost of debt (interest rate)
  Tc = Corporate tax rate

For early-stage climate startups, the cost of equity (Re) dominates because debt is rarely available. Re is largely determined by perceived risk. The SUI framework targets Re directly by reducing informational uncertainty — the single largest component of risk premium for impact enterprises.

The Five Mechanisms of WACC Reduction

Mechanism 1: Greenium Access

Studies of the green bond market document a "greenium" — a yield discount (i.e., lower borrowing cost) for bonds that meet verified green criteria. The evidence is consistent across markets:

• Zerbib (2019): 2 bps average greenium across 135 matched pairs of green and conventional bonds
• EU Green Bond Standard impact assessments: 3–18 bps for bonds with robust third-party verification
• IFC/World Bank analysis: up to 40 bps for sovereign green bonds with strong disclosure regimes
• Critical addition: third-party verification alone adds approximately 7.5 bps to the greenium (Kapraun et al., 2021)

A startup whose SUI is independently verified can access green bond financing that a startup with unverified impact cannot. At $10M in debt financing, a 15 bps reduction in interest rate saves $150,000 annually — compounding into material WACC reduction.

Mechanism 2: Blended Finance First-Loss Layers

Blended finance structures use concessional capital (grants or subordinated debt from DFIs, foundations, or governments) to de-risk commercial investment. The first-loss layer absorbs initial losses, allowing commercial investors to participate at lower required returns. To trigger first-loss provision, a startup must demonstrate verified impact milestones. The SUI is the milestone definition mechanism.

Example: A startup with a verified SUI of "102.4 kg CO₂e per hectare treated" can contractually agree: "When we reach 5,000 hectares treated and verified, the first-loss guarantee converts to equity at pre-agreed terms." This clarity makes DFIs willing to provide first-loss capital they would never offer to an unverified impact claim.

Mechanism 3: MDB Co-investment Eligibility

Multilateral Development Banks (IFC, IDB Invest, AIIB, ADB) have explicit taxonomy alignment requirements for co-investment. The EU Taxonomy, the Climate Bonds Initiative taxonomy, and IFC's EDGE standard all require demonstrable, measurable environmental outcomes. A startup with a SUI aligned to these taxonomies is immediately eligible for MDB co-investment pipelines — which typically offer below-market rates and long tenors that commercial investors cannot match.

Mechanism 4: Reduced Due Diligence Cost

Impact due diligence is expensive — a standard ESG/impact assessment costs $15,000–$75,000 per transaction. Investors conducting multiple rounds of due diligence on the same startup multiply these costs. A startup with a pre-verified, auditable SSOT system reduces due diligence cost for every future investor — and part of that saving can be captured as a higher pre-money valuation (lower effective equity cost).

Mechanism 5: Narrative Premium with Institutional LPs

Venture capital funds with impact mandates face pressure from their Limited Partners (LPs — pension funds, endowments, family offices) to demonstrate portfolio-level impact. A startup with a verified SUI improves the fund's impact reporting quality, which matters for LP retention and follow-on fundraising. Funds that can demonstrate high-quality portfolio impact are increasingly able to raise at better terms — and some of that LP value translates back to portfolio companies as more patient capital and lower dilution requirements.

The Compounding Effect

These five mechanisms do not operate independently. A startup that achieves verified SUI status gains access to blended finance (Mechanism 2), which brings MDB co-investors (Mechanism 3), which signals credibility to commercial investors who reduce their required return (Mechanism 1 via reputation), which reduces due diligence costs for each subsequent round (Mechanism 4), which improves the fund's LP story (Mechanism 5). The WACC impact compounds across the startup's lifecycle.

Conservative modelling suggests a climate startup with a verified SUI framework — all else equal — could reduce its Series A WACC by 300–500 basis points relative to an equivalent startup without verification. Over a 7-year venture lifecycle, this difference translates to a substantially larger equity value at exit.

---

Continue to Chapter 2: The SUI Framework — the five criteria in detail.

Chapter 2: The SUI Framework

The Five Criteria of a SUI

The Five Criteria of a SUI

A valid Scalable Unit of Impact must satisfy all five criteria simultaneously. Partial compliance — three criteria met, two not — does not produce a SUI. It produces an impact aspiration. The criteria are adapted from the IMP Five Dimensions of Impact (Impact Management Project, now Impact Frontiers) but operationalised at the per-application unit level rather than the portfolio level.

Criterion 1: Specificity (What)

Specificity requires three nested choices:

1. Domain selection: Which system is being changed? (Climate, Biodiversity, Water, Social equity, etc.)
2. Indicator selection: Which standardised indicator tracks the change? (IRIS+ code, TNFD metric, GRI indicator, or AIMM dimension)
3. Granularity selection: At what level of aggregation does the unit apply? (Per dose, per hectare, per session, per kWh, per tonne)

Test: Can you complete this sentence unambiguously? "One application of [product] produces [N] [units] of [IRIS+/TNFD indicator] in [defined system]."

Examples:

• PASS: "One hectare treated with Becaps biostimulant displaces 102.4 kg CO₂e of synthetic nitrogen fertiliser (IRIS+ PI5765 — GHG emissions avoided)"
• FAIL: "Our product helps farmers reduce their environmental footprint" (no taxonomy, no unit, no domain)

Criterion 2: Attribution (Contribution)

Attribution is the most technically demanding criterion and the most commonly ignored. It requires:

1. Counterfactual baseline: What outcome would occur in the absence of the product? (Business-as-usual scenario)
2. Attribution boundary: Which portion of the observed outcome change is caused by the enterprise versus other concurrent factors?
3. Temporal boundary: Over what time period is the attributed impact counted?

Common attribution errors:

• Gross vs. net reporting: Claiming 500 tonnes CO₂e avoided when the counterfactual would have avoided 200 tonnes anyway — the net is 300 tonnes
• Selection bias: Measuring impact only among customers who adopted the product successfully, ignoring drop-outs or partial adopters
• Displacement: An activity that reduces emissions in one location but increases them elsewhere (leakage) must account for the leakage in its SUI

Criterion 3: Quantifiability (How Much)

Quantifiability requires:

1. A numeric value with unit (e.g., 102.4 kg CO₂e, 47.3 kWh, 2.1 m³ water)
2. A measurement protocol specifying who measures, with what instrument, at what frequency
3. An uncertainty range or confidence interval — all physical measurements have uncertainty; hiding it is a red flag

The choice between physical and monetary units matters:

• Physical units (kg CO₂e, kWh, m³) are more verifiable and less subject to monetisation assumptions
• Monetary units (USD impact-weighted revenue per application) allow direct comparison with financial metrics but require additional assumptions about social cost of carbon or impact valuations
• Best practice: define the SUI in physical units; provide a monetary translation as supplementary information

Criterion 4: Verifiability

Verifiability has three components:

1. Independence: The verifier has no financial interest in the outcome they are verifying. Self-certification is not verification.
2. Evidence trail: The verifier can trace from the SUI claim back to the raw data source — sensor readings, satellite imagery, lab results, customer records — without relying on the enterprise's summaries.
3. Reproducibility: A second independent verifier, given access to the same SSOT, would reach the same conclusion within the stated uncertainty range.

The SSOT system that enables verifiability is described in detail in Chapter 3. In practice, verifiability is achieved through a three-tier pipeline: Ingest → Digital Twin → Conversion.

Criterion 5: Scalability

Scalability tests:

• Does the SUI definition change when the product is deployed in a new geography? (If yes, you may need geography-specific SUI variants — acceptable, but must be documented)
• Does the measurement cost per SUI decrease as volume grows? (Should be yes — a scalable SUI benefits from measurement infrastructure amortisation)
• Can the SSOT system handle N × volume without architectural changes? (A scalable SUI requires a scalable data infrastructure)

The Five-Criteria Matrix

Criterion	Key Question	Evidence Required	Failure Mode
Specificity	What changes?	Taxonomy link, unit definition	Vague outcome language
Attribution	Because of us?	Baseline, counterfactual methodology	Gross impact reporting
Quantifiability	How much?	Measurement protocol, uncertainty range	Directional claims without numbers
Verifiability	Can anyone check?	Independent auditor access, SSOT system	Self-certified data
Scalability	Works at scale?	Protocol stability, infrastructure plan	Pilot-only methodology

---

Next: Comparison with Existing Impact Frameworks — how SUI relates to IRIS+, AIMM, IMP, and others.

Comparison with Existing Impact Frameworks

Comparison with Existing Impact Frameworks

The SUI framework does not replace existing impact measurement standards — it operationalises them at the per-application unit level. Understanding how SUI relates to the major frameworks helps practitioners choose which standards to cite in their SUI definition and which verification protocols are compatible.

The Landscape of Impact Standards

Standard	Owner	Primary Use	Granularity	Verification Requirement
IRIS+ 5.3b	GIIN	Impact indicator selection	Portfolio/fund	None mandated
IMP Five Dimensions	Impact Frontiers	Impact conceptualisation	Programme	None mandated
IFVI / Capitals Coalition	IFVI	Impact-weighted accounts	Enterprise	Recommended
IFC AIMM	IFC	MDB investment scoring	Project	IFC internal
EU Taxonomy	European Commission	Regulatory do-no-harm	Activity	Mandatory (DNSH)
TNFD	TNFD Secretariat	Nature-related disclosure	Enterprise/site	Recommended
60 Decibels	60dB	Beneficiary perception	Beneficiary	Independent (60dB team)
GRI Standards	GRI	Sustainability reporting	Enterprise	Recommended
SUI (CTH Framework)	CleantechHUB	Per-application unit definition and verification	Application	Mandatory (SSOT-backed)

SUI vs. IRIS+ (GIIN)

IRIS+ is the most widely used impact measurement framework globally, with over 10,000 indicators organised into sector-specific metric sets. IRIS+ tells you what to measure; SUI tells you how to verify it at the unit level.

Complementarity: Every SUI should reference an IRIS+ indicator (or TNFD/GRI equivalent) in its Specificity criterion. IRIS+ provides the taxonomy; SUI provides the per-application protocol.

Key gap SUI fills: IRIS+ 5.3b includes sector metric bundles (agriculture, energy, housing) but has no concept of a "per-application standard." A company using IRIS+ PI5765 (GHG emissions avoided) can report any number of tonnes avoided with no protocol for verifying the per-dose or per-hectare calculation. SUI closes this gap.

SUI vs. IMP Five Dimensions (Impact Frontiers)

The Impact Management Project's Five Dimensions — What, Who, How Much, Contribution, Risk — are the closest conceptual antecedent to the SUI criteria. The SUI framework directly adapts them:

IMP Dimension	SUI Criterion	SUI Addition
What	Specificity	Requires taxonomy link at application level
Who	(Embedded in Specificity)	SUI focuses on environmental outcomes; social "who" is contextual
How Much	Quantifiability	Requires per-application unit, not programme total
Contribution	Attribution	Requires documented counterfactual, not just claim
Risk	(Embedded in Verifiability)	SSOT system reduces impact risk by making claims auditable

IMP operates at the programme or portfolio level; SUI operates at the product application level. SUI is, in a sense, IMP operationalised for startup product teams.

SUI vs. IFC AIMM

The IFC's Anticipated Impact Measurement and Monitoring (AIMM) system scores investments on a 100-point scale across 29 sectors. It is the standard used by IFC and increasingly by other MDBs for investment decision-making.

Why SUI alignment with AIMM matters: A startup seeking IFC co-investment or IFC-backed blended finance must score above threshold on AIMM. AIMM's "Market Creation" and "Effects on People and Planet" components reward verifiable, sector-aligned impact measurement. A startup with a well-defined SUI can self-score on AIMM with significantly higher confidence — and can present the SSOT evidence trail to IFC reviewers.

SUI vs. EU Taxonomy

The EU Taxonomy Regulation defines environmentally sustainable economic activities and requires companies to demonstrate "substantial contribution" to one of six environmental objectives while meeting "Do No Significant Harm" (DNSH) criteria. Taxonomy alignment is increasingly a condition for accessing EU green finance instruments.

SUI as EU Taxonomy enabler: The EU Taxonomy requires quantitative, measurable environmental contributions — precisely what the SUI provides. A SUI aligned to EU Taxonomy criteria (e.g., climate change mitigation, circular economy) gives a startup a credible claim to Taxonomy-aligned revenue, unlocking access to EU Green Bond instruments and SFDR Article 9 fund investment.

SUI vs. TNFD

The Taskforce on Nature-related Financial Disclosures (TNFD) had 733+ adopters representing $22T AUM as of 2025. TNFD focuses on nature-related risks and dependencies, not just climate. The SUI framework is extensible to biodiversity and water outcomes using TNFD metrics (e.g., habitat restored per application, water quality index per treatment).

Where SUI Is Genuinely Novel

No existing framework combines all four of these properties simultaneously:

1. Per-application granularity (not programme or portfolio level)
2. Mandatory independent verification against a defined SSOT
3. Explicit financial instrument design interface (SUI as trigger metric)
4. Startup-native operationalisation (designed for companies with limited measurement infrastructure)

IRIS+ covers #1 in principle but not #2, #3, or #4. The EU Taxonomy covers #2 and #3 but operates at the activity level, not the product application level. SUI fills the gap between these frameworks and the financial instruments that want to use their outputs.

---

Next: The Parameterized SUI Protocol — how to formally specify and document a SUI.

The Parameterized SUI Protocol

The Parameterized SUI Protocol

A SUI is not fully defined until its parameters are documented. The Parameterized SUI Protocol is a structured specification format that captures everything needed to (a) communicate the SUI unambiguously, (b) instruct a verification auditor, and (c) design a financial instrument around it.

The SUI Parameter Set

Every SUI must specify the following eight parameters:

#	Parameter	Description	Example (Becaps)
1	SUI Name	A plain-language name that identifies the unit	Chemical Displacement per Hectare
2	Outcome Domain	The system being changed (taxonomy-linked)	Climate — GHG Emissions Avoided (IRIS+ PI5765)
3	Application Event	The specific company action that triggers one SUI	Application of 1 kg Becaps biostimulant to 1 hectare of cultivated land
4	Baseline Value	Counterfactual outcome in the absence of the intervention	220 kg N/ha synthetic fertiliser application (regional average, DANE 2023)
5	Observed Value	Measured outcome with the intervention	85 kg N/ha (average across 120 trial plots, 2023–2024)
6	SUI Magnitude	Net impact = Baseline − Observed, converted to outcome unit	135 kg N/ha displacement × 0.758 CO₂e/kg N = 102.4 kg CO₂e/ha
7	Uncertainty Range	95% confidence interval on the SUI magnitude	±12.3 kg CO₂e/ha (±12%)
8	Verification Protocol	How, when, and by whom the SUI is verified	Annual third-party LCA audit by certified GHG verifier; SSOT ingest from production batch records + soil lab reports

The SUI Specification Document

A complete SUI specification document contains the parameter set above plus the following supporting sections:

Section A: Taxonomy Mapping

Map the SUI to every relevant standard:

• IRIS+ indicator code(s) and description
• SDG target(s) (e.g., SDG 2.4, SDG 13.1)
• EU Taxonomy objective and activity code (if applicable)
• TNFD indicator (if nature-related)
• AIMM sector and dimension (if MDB investment is planned)

Section B: Baseline Documentation

For every SUI, the baseline must be documented with:

• Source of baseline data (peer-reviewed study, government statistics, industry survey)
• Year of baseline data and update frequency
• Geographic scope and representativeness
• Baseline degradation plan (what happens if the baseline changes — e.g., if synthetic fertiliser use declines nationally)

Section C: SSOT Architecture Summary

A brief description of the Single Source of Truth system that will hold the underlying data:

• Data sources feeding the SSOT (ERP records, IoT sensors, lab reports, satellite data)
• Data governance: who can write, who can read, what is immutable
• Audit trail: how a verifier accesses historical records
• Verification interface: the data export format provided to third-party auditors

Section D: Aggregation Rules

How individual SUI events are summed to produce period totals:

• Temporal aggregation (annual, quarterly, rolling 12-month)
• Geographic aggregation (by country, region, or global)
• Double-counting prevention (if a product is applied and then re-applied to the same area in the same period)
• Boundary conditions (minimum threshold for counting one SUI event)

The SUI Specification Template

SUI SPECIFICATION DOCUMENT
Version: 1.0
Company: [Name]
Date: [YYYY-MM-DD]
Author: [Name, Role]
Verifier (pending): [Name of planned third-party auditor]

═══════════════════════════════════════════
PARAMETER SET
═══════════════════════════════════════════

1. SUI Name: ___________________________________
2. Outcome Domain: _____________________________ 
   IRIS+ Code: ________________________________
   SDG Target: ________________________________
3. Application Event: __________________________
   Trigger condition: _________________________
   Unit of application: _______________________
4. Baseline Value: ____________________________ 
   Baseline source: ___________________________
   Baseline year: _____________________________
5. Observed Value: ____________________________
   Measurement method: ________________________
   Sample size / coverage: ____________________
6. SUI Magnitude: _____________________________
   Calculation: (Baseline - Observed) × [conversion factor]
7. Uncertainty Range: _________________________
   Confidence level: __________________________
8. Verification Protocol: ______________________
   Verifier type: _____________________________
   Verification frequency: ____________________
   SSOT access method: ________________________

═══════════════════════════════════════════
TAXONOMY MAPPING
═══════════════════════════════════════════
IRIS+:       [ ] PI5765  [ ] PI7685  [ ] Other: ______
EU Taxonomy: [ ] Mitigation  [ ] Adaptation  [ ] N/A
TNFD:        [ ] Yes (metric: _________)  [ ] N/A
AIMM:        [ ] Sector: _______  [ ] N/A

═══════════════════════════════════════════
VALIDATION SIGN-OFF
═══════════════════════════════════════════
Internal review by: ____________________
Date: __________________________________
External verification by: ______________
Date: __________________________________
Verification standard used: ____________

Living Document Protocol

The SUI specification is a living document that must be updated under the following conditions:

• When the product formulation or delivery mechanism changes materially
• When the baseline data source is updated (triggers recalculation of all prior SUI magnitudes, with appropriate notes)
• When the company expands to a new geography with a materially different baseline
• When the verification protocol changes (e.g., new verifier, new standard)
• At minimum annually, as part of the impact reporting cycle

---

Continue to Chapter 3: The SSOT Architecture — building the data infrastructure that makes SUI verification possible.

Chapter 3: The SSOT Architecture

What is a Single Source of Truth (SSOT)?

What is a Single Source of Truth (SSOT)?

Why "Single Source"?

Most early-stage companies manage their data across a fragmented set of tools: spreadsheets emailed between team members, production records in an ERP system, customer data in a CRM, lab results in PDFs stored in Dropbox, and impact metrics calculated in a separate Excel model. Each of these is a source of data — but none is authoritative. When an investor asks "show me how you calculated 102.4 kg CO₂e per hectare," the answer cannot be found in any single place.

An SSOT eliminates this fragmentation. It does not necessarily mean one database — it means one canonical layer through which all relevant data flows, where every claim is traceable to its source, and where the chain of custody is documented.

What the SSOT Must Contain

For SUI verification purposes, the SSOT must hold:

1. Input records: Evidence of each product application event (batch production records, delivery confirmations, IoT sensor readings, GPS coordinates of deployment)
2. Baseline data: The counterfactual reference data, with source documentation and version history
3. Calculation engine outputs: The intermediate steps in converting input records to SUI magnitudes (the Digital Twin layer)
4. Outcome data: Third-party measurement results (lab analyses, satellite observations, auditor field reports)
5. Aggregated SUI ledger: A time-series of verified SUI events, each linked back to its source input record and outcome measurement
6. Version history: All changes to the above, with timestamps and the identity of who made each change

SSOT vs. Data Warehouse vs. ERP

System Type	Purpose	Audit-Ready?	Role in SUI Pipeline
ERP (SAP, Odoo, QuickBooks)	Business operations records	Partially	Source of input data (production, sales)
Data Warehouse (Snowflake, BigQuery)	Analytics and reporting	No (mutable)	Intermediate processing layer
BI Tool (Tableau, Metabase)	Visualisation	No	Output layer for stakeholder dashboards
SSOT (SUI Architecture)	Impact claim verification	Yes (immutable audit trail)	Canonical record of all SUI events

The Four Properties of a SUI-Grade SSOT

Property 1: Immutability

Once a SUI event is recorded and verified, it cannot be modified without creating a new, linked record that documents the correction. This is achieved through append-only data structures, cryptographic hashing of records, or blockchain anchoring (for the highest assurance levels). The principle: you can correct errors, but the original record and the correction are both permanently visible.

Property 2: Traceability

Every SUI magnitude in the impact ledger must be traceable back to its source input records. A verifier must be able to ask: "Show me the raw data behind SUI event #4,721" and receive a complete chain: batch record → production quantity → application event → calculation log → outcome measurement → verified SUI value.

Property 3: Access Control with Audit Logging

The SSOT must implement role-based access control: company staff can write new records; investors can read aggregated data; independent verifiers can access underlying records during audit windows. Every access event is logged — who accessed what, when, and what they downloaded.

Property 4: Structured for External Consumption

The SSOT must be able to produce a standardised data export in a format specified by the relevant verification standard (e.g., ISAE 3000, ISO 14064-3, or the auditor's own format). This is not a spreadsheet dump — it is a structured, machine-readable dataset that maps to the SUI parameter specification.

SSOT Maturity Levels

Not every startup needs a full enterprise SSOT from day one. CTH recognises four maturity levels:

Level	Name	Description	Typical Stage
0	Fragmented	Data in multiple disconnected tools; no single version of truth	Pre-seed, < 12 months
1	Consolidated	Data centralised in one tool (even a well-structured spreadsheet); no automation	Seed, pilot phase
2	Automated	Data flows automatically from source systems to a central repository; version control in place	Series A, growth phase
3	Audit-Ready	Full immutability, access control, traceability, and structured export; third-party verified	Series B+, pre-MDB engagement

A startup at SSOT Level 1 can still define and communicate a SUI — the specification document is the foundation. Verification becomes possible at Level 2 and full financial instrument eligibility at Level 3.

---

Next: The Three-Tier Validation Pipeline — how data flows from raw inputs to verified SUI events.

The Three-Tier Validation Pipeline

The Three-Tier Validation Pipeline

The Three-Tier Validation Pipeline is the data architecture that converts raw operational records into verified SUI events. It is named for its three sequential layers: Ingest, Digital Twin, and Conversion. Each tier has a defined responsibility, a defined data format, and a defined handoff protocol to the next tier.

Pipeline Overview

┌─────────────────────────────────────────────────────────────────┐
│                    THREE-TIER VALIDATION PIPELINE                │
├─────────────────┬───────────────────────┬───────────────────────┤
│   TIER 1        │      TIER 2           │      TIER 3           │
│   INGEST        │   DIGITAL TWIN        │   CONVERSION          │
│                 │                       │                       │
│ Raw operational │ LCA simulation &      │ MDB-ready metrics &   │
│ data from all   │ counterfactual        │ financial instrument   │
│ source systems  │ modelling engine      │ trigger outputs       │
│                 │                       │                       │
│ ERP records     │ Emission factors      │ IRIS+ mapped values   │
│ IoT sensors     │ Baseline comparison   │ EU Taxonomy aligned   │
│ Lab results     │ Uncertainty calc.     │ Auditor export pkg.   │
│ GPS/satellite   │ Version-locked params │ SUI Ledger entry      │
└─────────────────┴───────────────────────┴───────────────────────┘

Tier 1: Ingest

Purpose

Capture all raw evidence of product application events in structured, timestamped form. The Ingest tier is the intake valve of the SSOT — every piece of data relevant to a SUI claim must enter through it.

Data Sources by Sector

Sector	Typical Ingest Sources
AgTech / Bio-inputs	Batch production records (ERP), field application GPS logs, customer delivery confirmations, soil lab analysis PDFs
Clean Energy / EV	IoT charging session data (kWh, duration, vehicle ID), grid connection records, utility meter readings
Water Treatment	Flow meter readings, water quality sensors (turbidity, pH, pathogen count), treatment plant operational logs
Circular Economy	Material inflow/outflow manifests, weight measurements, recycler receipts, chain-of-custody certificates
Built Environment	BMS (Building Management System) data, energy audit reports, occupancy sensors, utility bills

Ingest Requirements

• Timestamp: Every record carries a machine-generated UTC timestamp, not a manually entered date
• Source ID: Every record carries the identifier of the system or device that generated it
• Immutability flag: Once ingested, records are locked; corrections create new records with a "supersedes" link to the original
• Schema validation: Records are validated against a defined schema on ingest; malformed records are quarantined, not silently dropped

Tier 2: Digital Twin

Purpose

Apply the SUI calculation logic to the ingested records — comparing observed outcomes to the counterfactual baseline, applying emission factors, calculating uncertainty, and producing a per-application SUI magnitude.

What "Digital Twin" Means Here

In this context, "Digital Twin" refers to a computational model of the enterprise's impact mechanism — not a real-time operational simulation. The Digital Twin encodes:

• The Life Cycle Assessment (LCA) model for the product's impact pathway
• The baseline values (counterfactual scenario) and their uncertainty ranges
• The emission factors or conversion coefficients (e.g., IPCC AR6 values for N₂O emission from synthetic nitrogen)
• The aggregation rules (how individual application events are summed to period totals)

Version Control for Model Parameters

Every change to the Digital Twin model — a new emission factor, an updated baseline, a revised LCA boundary — must be version-controlled. Each SUI event in the ledger is tagged with the model version that produced it. This allows historical SUI calculations to be reproduced exactly, even after model updates.

Digital Twin Outputs

For each ingested application event, the Digital Twin produces:

• SUI magnitude (central estimate)
• Uncertainty range (±N%, at 95% confidence)
• Model version tag
• Calculation audit log (step-by-step computation)
• Data quality flag (complete data vs. estimated vs. proxy)

Tier 3: Conversion

Purpose

Transform the Digital Twin outputs into the formats required by different stakeholders — investors, MDBs, auditors, regulators, and the SUI Ledger itself.

Output Formats

Output	Format	Audience
SUI Ledger Entry	Structured JSON record in the SSOT	SSOT system, auditors
IRIS+ Report	Indicator values mapped to IRIS+ codes	Impact investors, GIIN reporting
EU Taxonomy Contribution Statement	% revenue / capex / opex aligned	European institutional investors
MDB Project Brief	AIMM-compatible impact narrative + data table	IFC, IDB Invest, ADB co-investors
Auditor Export Package	CSV + methodology PDF + raw data links	Third-party verifiers (ISAE 3000)
Investor Dashboard	Aggregated charts + drill-down to unit level	Board, VCs, DFI monitors

Conversion Layer Controls

The Conversion tier must enforce several data integrity controls:

• No manual overrides: Conversion outputs are computed, not manually adjusted. Any "rounding" or "presentation formatting" must be documented and must not change material values.
• Uncertainty propagation: Uncertainty from the Digital Twin is carried through to all Conversion outputs, not dropped at the reporting layer.
• Audit trail linkage: Every Conversion output includes a reference back to the Tier 2 records that produced it, and through those, to the Tier 1 raw inputs.

The Pipeline in Practice: Becaps Example

1. Ingest: Becaps ERP records batch #BC-2024-0441: 500 kg product shipped to cooperative Finca Verde, La Calera, Colombia. GPS delivery confirmed. Cooperative confirms application to 500 ha (1 kg/ha). Soil lab reports uploaded: pre/post nitrogen content for 12 sample plots.
2. Digital Twin: Model applies: Baseline = 220 kg N/ha (DANE 2023 Colombian synthetic fertiliser use). Observed = 85 kg N/ha (lab-confirmed). Net displacement = 135 kg N/ha. IPCC AR6 conversion: 135 kg N × 0.758 CO₂e/kg N = 102.3 kg CO₂e/ha. Uncertainty: ±12.3 kg CO₂e (±12%). Model version: DT-Becaps-v2.1.
3. Conversion: 500 SUI events recorded in ledger (one per hectare). IRIS+ PI5765 report: 51,150 kg CO₂e avoided this batch. Auditor export package generated. MDB project brief updated with cumulative totals.

---

Next: The Digital Twin for Impact Verification — building and validating the computational model.

The Digital Twin for Impact Verification

The Digital Twin for Impact Verification

The Digital Twin is the computational core of the SUI verification system. It is a version-controlled, auditable model that takes raw operational data as input and produces per-application SUI magnitudes as output. This page describes how to build, validate, and maintain a Digital Twin suitable for third-party impact verification.

What Goes Into the Digital Twin Model

1. The Impact Pathway Model

The impact pathway describes the causal chain from product application to environmental outcome. It answers the question: "Through what mechanism does one application of our product produce the claimed SUI magnitude?"

For a biostimulant company like Becaps:

Product application (1 kg biostimulant / ha)
    → Microbial inoculation (≥10¹¹ CFU/g colonise root zone)
    → Biological nitrogen fixation (BNF increases N availability)
    → Reduced synthetic N application requirement (−135 kg N/ha)
    → Avoided N₂O emissions from synthetic fertiliser production (×0.758 CO₂e/kg N)
    → Avoided N₂O emissions from soil application of synthetic N (×0.01 kg N₂O/kg N)
    → Total GHG displacement: 102.4 kg CO₂e/ha

Each arrow in this chain must be supported by either (a) peer-reviewed scientific literature, (b) field trial data from the company's own operations, or (c) certified emission factors from recognised sources (IPCC, EPA, DEFRA).

2. Emission Factors and Conversion Coefficients

The Digital Twin relies on external data — emission factors, conversion ratios, global warming potential values — that are updated periodically by standard-setting bodies. The model must:

• Specify the exact source and version for every external coefficient (e.g., "IPCC AR6 WGI Table 7.SM.7, GWP100 value for N₂O: 273 CO₂e")
• Implement version locking — historical SUI events use the factor version in effect at the time of calculation
• Trigger recalculation reviews when major updates are released (e.g., when IPCC publishes a new Assessment Report)

3. Baseline Model

The counterfactual baseline is a model in its own right. It specifies:

• The reference activity that would occur without the enterprise's product (e.g., "conventional synthetic nitrogen application at regional average rates")
• The data source and geographic scope of the baseline (e.g., DANE 2023 Colombia agricultural census)
• The temporal validity of the baseline (baselines degrade as markets change — a 2019 baseline for synthetic fertiliser use in a region that has since adopted sustainable agriculture practices will overstate impact)
• Baseline update triggers: conditions under which the baseline must be recalculated (e.g., if market penetration of competing biostimulants exceeds 20% in the region)

4. Uncertainty Model

Impact uncertainty has multiple sources, each of which must be quantified:

• Measurement uncertainty: Variability in field measurements (soil nitrogen content measured in 12 plots out of 500 ha — sampling error)
• Model uncertainty: Uncertainty in the emission factor values (IPCC provides ranges, not point estimates)
• Baseline uncertainty: The baseline is an average — individual farms may deviate significantly from the average
• Attribution uncertainty: The portion of observed N reduction attributable specifically to the biostimulant (vs. weather, management changes, etc.)

The Digital Twin propagates these uncertainties using Monte Carlo simulation or analytical uncertainty propagation and reports the combined 95% confidence interval on every SUI magnitude output.

Building the Digital Twin: Minimum Viable Version

For a pre-Series A startup, the minimum viable Digital Twin can be a well-structured, version-controlled Excel or Python model. The key requirements are:

1. Documented inputs: Every input cell or variable has a source citation
2. Auditable calculations: No black boxes — every formula is visible and reviewable
3. Version control: The model is stored in a git repository or equivalent with change history
4. Reproducibility: Given the same inputs, a second analyst running the model independently produces the same outputs within rounding error
5. Sensitivity analysis: The model includes a sensitivity analysis showing which inputs have the largest impact on the SUI magnitude

Digital Twin Validation

Before the Digital Twin is used for investor reporting or financial instrument design, it must be validated by an independent third party. Validation means:

1. Model review: The validator reviews the impact pathway logic, the source citations for all emission factors, and the baseline methodology
2. Calculation audit: The validator independently recalculates a sample of SUI events using the model and confirms they match the company's reported values
3. Field data audit: The validator reviews the raw field data (lab reports, IoT records) and confirms they match what was ingested into the model
4. Written validation statement: The validator issues a written statement (following ISAE 3000 or equivalent) confirming the model is fit for purpose

Scaling the Digital Twin

As the company scales, the Digital Twin must evolve from a spreadsheet model to a software system. Key milestones:

Scale Milestone	Digital Twin Requirement
< 1,000 SUI events/year	Excel/Python model with manual data input, annual validation
1,000–50,000 events/year	Automated data pipeline from SSOT to model; semi-annual validation
50,000–1M events/year	Real-time or near-real-time computation; continuous monitoring; annual third-party audit
> 1M events/year	Enterprise-grade system with SOC 2 Type II certification; continuous auditing by major accounting firm

---

Continue to Chapter 4: Financial Mechanisms — how a verified SUI translates into reduced cost of capital.

Chapter 4: Financial Mechanisms

How SUI Reduces WACC

How SUI Reduces WACC

This page provides the technical mechanism detail behind the SUI-WACC hypothesis — how, specifically, a verified SUI reduces a climate startup's Weighted Average Cost of Capital through each of the five mechanisms introduced in Chapter 1.

The WACC Decomposition for Climate Startups

For an early-stage climate startup, WACC is predominantly determined by the cost of equity (Re), since debt financing is typically unavailable or minimal. Re is priced by investors as:

Re = Rf + β × (Rm - Rf) + α_impact

Where:
  Rf = Risk-free rate (e.g., 10-year US Treasury yield)
  β = Market beta (systematic risk)
  Rm - Rf = Equity risk premium
  α_impact = Impact uncertainty premium (the additional return
             demanded by investors who cannot verify impact claims)

The SUI framework directly targets α_impact. When an investor can independently verify the company's impact claims through an SSOT-backed audit, the informational uncertainty that drives α_impact is reduced — and with it, the required return.

Quantifying the SUI Effect on α_impact

No single study has isolated the impact uncertainty premium for climate startups specifically. However, the following evidence points allow a conservative estimate:

• Greenium studies: Third-party verification adds ~7.5 bps to the greenium for bonds (Kapraun et al., 2021). This is a floor estimate — bond markets have much lower information asymmetry than private equity markets.
• ESG disclosure literature: Companies with robust ESG disclosure trade at 5–15% lower price-to-earnings discount relative to peers with weak disclosure (MSCI, 2020). For private companies, this premium would be captured in the dilution rate at fundraising.
• DFI co-investment impact: When an IFC or IDB co-invests, it signals due diligence quality to commercial co-investors, allowing the lead commercial investor to price the deal at 200–400 bps lower required return (based on Convergence Finance analysis of blended deals).

A conservative synthesis: verified SUI status reduces α_impact by 300–500 bps for an early-stage climate startup relative to an unverified peer. At a $5M equity round, this translates to 2–4% less dilution — worth $100,000–$200,000 in founder equity retention at a $5M post-money valuation.

WACC Reduction Pathway: Step by Step

Step 1: SUI Definition (Year 0)

Startup defines its SUI following the Parameterized SUI Protocol. No immediate WACC effect, but the specification document signals methodological seriousness to investors. Some sophisticated impact investors will reduce their required return marginally (~50 bps) at this stage.

Step 2: SSOT Implementation (Year 0–1)

Startup implements Level 1–2 SSOT (centralised data, version control). Impact due diligence costs for the next investor are reduced — part of this saving converts to better deal terms (~50–100 bps).

Step 3: First Third-Party Verification (Year 1–2)

An independent verifier audits the SUI methodology and SSOT data. Issues a verification statement. This event is the key inflection point:

• Startup becomes eligible for green bond financing (Rd effect)
• Startup qualifies for DFI co-investment pipeline screening (blended finance access)
• Impact premium (α_impact) compresses by an estimated 150–250 bps

Step 4: MDB Taxonomy Alignment (Year 2–3)

Startup aligns its verified SUI to EU Taxonomy and AIMM metrics. This triggers:

• Eligibility for Article 9 SFDR fund investment (significant expansion of investor universe)
• IFC/IDB project pipeline screening qualification
• Green bond issuance eligibility at greenium rates
• Cumulative WACC reduction: 300–500 bps vs. unverified baseline

Step 5: Blended Finance Structure (Year 3–5)

With verified SUI as trigger metrics, startup negotiates a blended finance structure with a DFI anchor investor providing first-loss capital. Commercial investors enter at lower required returns due to de-risked position. WACC reduction is at maximum — potentially 500–700 bps vs. unverified baseline for comparable stage/sector.

Sensitivity Analysis

Assumption	Conservative	Base Case	Optimistic
SUI verification cost (one-time)	$50,000	$30,000	$15,000
SSOT implementation cost	$80,000	$40,000	$20,000
WACC reduction (bps)	200	350	500
Capital raised at reduced WACC	$5M	$10M	$20M
NPV of WACC reduction (7yr)	$140,000	$700,000	$2,800,000
Net benefit (after costs)	$10,000	$630,000	$2,765,000

Even under conservative assumptions, the ROI of SUI verification is positive — and the strategic optionality value (access to blended finance, green bonds, and MDB co-investment) is not captured in this table.

Important Caveats

• The WACC reduction is an upper bound that assumes the startup can credibly access each financial mechanism. A startup in a sector with no established green bond market (e.g., early-stage circular economy niche) will see smaller gains from the greenium mechanism.
• The WACC effect compounds with impact size — a startup with a SUI of 1 tonne CO₂e/application has less financial leverage than one with 100 tonnes/application, even if both are equally well-verified.
• SUI verification is necessary but not sufficient for WACC reduction. The underlying business must also demonstrate commercial viability, defensible technology, and competent management — verification cannot substitute for fundamentals.

---

Next: The Greenium and Verified Impact — deep-dive on the green bond market evidence.

The Greenium and Verified Impact

The Greenium and Verified Impact

The Evidence Base

The existence and magnitude of the greenium has been studied extensively since the first labelled green bonds appeared in 2007. The evidence is now robust across markets and geographies:

Corporate Green Bonds

• Zerbib (2019) — Journal of Financial Economics: Analysis of 135 matched green/conventional bond pairs. Average greenium: −2 bps (green bonds yielded 2 bps less than conventional equivalents). Small but statistically significant.
• Kapraun et al. (2021): Expanded to 640 bonds. Finding: the greenium is concentrated in bonds with third-party verification and aligned to climate standards. Verified bonds: −7.5 bps. Unverified bonds: effectively 0 bps. This is the critical finding for SUI.
• EU Green Bond Standards analysis (2023): Bonds aligned to EU GBS show greenium of −12 to −18 bps, compared to −2 to −5 bps for self-labelled green bonds without EU GBS alignment.

Sovereign Green Bonds

• IFC/World Bank (2022): Sovereign green bonds with strong disclosure and third-party verification show greenium up to −40 bps in some markets. Emerging market sovereign green bonds: −10 to −20 bps average.
• Bloomberg data (2024): The green bond market reached $4.2 trillion in outstanding issuance. The average greenium across the entire market is approximately −5 bps — a small number that represents enormous cost savings at scale.

Implications for Climate Startups

Climate startups rarely issue public bonds directly — they are too small. But the greenium evidence matters for two indirect reasons:

1. VC fund greenium: Impact venture funds that hold verifiably impactful portfolio companies can raise their own green bonds or sustainability-linked bonds at greenium rates, and pass part of the funding cost advantage to portfolio companies through lower-cost venture debt.
2. Green bond readiness as signalling: A startup whose SUI meets green bond verification standards is demonstrably investment-ready for institutional capital — the verification standard serves as a quality signal even when the startup is not yet issuing bonds itself.

What Creates the Greenium

The greenium is not simply investor altruism. Three mechanisms drive it:

Mechanism A: Investor Mandate Compliance

Institutional investors with ESG mandates (pension funds, insurance companies, sovereign wealth funds) must demonstrate that a certain percentage of their portfolio meets green criteria. For these investors, verified green assets are scarce — demand exceeds supply. Scarcity premium = greenium.

Mechanism B: Regulatory Risk Reduction

EU SFDR, UK Sustainability Disclosure Requirements, and SEC climate disclosure rules create regulatory exposure for investments without documented green credentials. Green bond investors reduce their regulatory risk by holding verified assets. Risk reduction = willingness to accept lower yield.

Mechanism C: Liquidity Premium from Green Index Inclusion

Green bonds included in major ESG indices (Bloomberg MSCI Green Bond Index, S&P Green Bond Index) trade at higher liquidity than non-index bonds. Higher liquidity means lower yield. Index inclusion requires meeting minimum verification standards — creating a sharp incentive for issuers to verify.

The Verification Threshold Effect

The most important finding from Kapraun et al. (2021) is the non-linearity of the greenium with verification quality. The greenium does not increase gradually as verification quality improves — it jumps sharply at the threshold of independent third-party verification. Below the threshold, greenium is effectively zero. Above the threshold, greenium appears.

This is exactly the binary logic of the SUI framework: a SUI is either independently verified against an SSOT or it is not. There is no partial credit. And the financial benefit (access to the greenium) appears at the point of verification, not incrementally before it.

Accessing the Greenium as a Startup

A climate startup cannot directly access the greenium as a bond issuer — minimum bond sizes are typically $50M+. But several pathways exist:

Pathway	Mechanism	Startup Requirement
Green Revenue Note	Private debt instrument linked to green-certified revenue	Verified SUI, SSOT, 12+ months revenue history
DFI Concessional Loan	Below-market rate loan from IFC, IDB, or regional DFI	MDB taxonomy alignment, AIMM scoring, verified SUI
Sustainability-Linked Loan (SLL)	Interest rate tied to hitting verified impact milestones	Verified SUI as trigger metric, SSOT for monitoring
Impact VC Fund Allocation	VC fund lowers hurdle rate for verified impact portfolio companies	Third-party SUI verification, IRIS+ reporting
Corporate Green Bond (via offtaker)	Large corporate partner issues green bond backed partly by startup's impact	Verified SUI that meets corporate partner's GBS alignment

---

Next: Blended Finance and First-Loss Guarantees — structuring concessional capital around verified SUI milestones.

Blended Finance and First-Loss Guarantees

Blended Finance and First-Loss Guarantees

The Scale of Blended Finance

Convergence Finance (2024) documented:

• 1,123 blended finance transactions from 2010 to 2023
• Total committed capital: $213 billion
• Leverage ratio: approximately $4 of commercial capital mobilised per $1 of concessional capital
• Trend: average deal size growing; number of deals involving climate solutions increasing

Despite this scale, blended finance has faced persistent criticism for failing to reach the smallest and most innovative climate enterprises — the startups that most need it. The primary barrier: verification. First-loss providers (DFIs, foundations) require verifiable impact milestones before committing capital. Most startups cannot define, let alone verify, such milestones. The SUI is the mechanism that closes this gap.

First-Loss Guarantee Structures

How a First-Loss Guarantee Works

BLENDED FINANCE STRUCTURE

Tranche A: Commercial Investors  ─── Return: market rate
Tranche B: Impact Investors      ─── Return: below-market
Tranche C: DFI First-Loss       ─── Return: 0% or grant
(concessional capital)           ─── Risk: absorbs first losses

When losses occur: Tranche C absorbs first → B absorbs next → A last
This ordering allows A and B to accept lower required returns.

The SUI as Trigger Mechanism

In a results-based blended finance structure, the release (or conversion) of concessional capital is tied to verified impact milestones. The SUI is ideally suited to serve as these milestones because:

• It is defined at a granular level (per application) that accumulates cleanly to round-number milestones
• It is independently verified, so the DFI trigger committee does not need to rely on company self-reporting
• It is linked to an SSOT that can provide real-time progress monitoring without expensive field audits

Becaps example trigger structure:

Milestone	SUI Threshold	Concessional Capital Event
Milestone 1	500 tonnes CO₂e displaced (verified)	First-loss tranche C releases $500K to Tranche B (converts from guarantee to investment)
Milestone 2	2,000 tonnes CO₂e displaced	Second tranche release + interest rate reduction on commercial debt
Milestone 3	5,000 tonnes CO₂e + 1,000 hectares certified	Full guarantee conversion; green bond issuance eligibility achieved

Types of Blended Finance Instruments by SUI Readiness

Instrument	SUI Requirement	Typical DFI Providers	Capital Range
Technical Assistance Grant	SUI definition in progress	IDB Lab, GIZ, Expertise France	$50K–$500K
Recoverable Grant	SUI defined, SSOT planned	DGGF, Adaptation Fund	$200K–$2M
Concessional Equity	SUI defined and verified (Level 1)	IFC, ADB Ventures, BIO	$500K–$5M
First-Loss Guarantee	SUI verified, SSOT Level 2+	USAID DCA, SIDA, AFD	$1M–$20M
Results-Based Finance	SUI verified, SSOT Level 3, independent verifier contracted	World Bank GPOBA, EU EFSD+	$5M–$100M

De-risking the De-riskers: The SSOT Monitoring Role

First-loss providers face their own operational challenge: monitoring dozens of portfolio companies to verify that milestones have been met before releasing capital. This monitoring is expensive — field visits, audit commissions, report reviews — and creates bottlenecks that slow capital deployment.

An SSOT-backed SUI system dramatically reduces monitoring cost. When the first-loss provider has read access to the startup's SSOT dashboard — seeing real-time accumulation of verified SUI events — milestone monitoring becomes semi-automated. The DFI trigger committee reviews a dashboard rather than commissioning a field audit. This efficiency gain is itself a selling point when negotiating blended finance terms.

The CTH Blended Finance Matchmaking Process

CleantechHUB supports portfolio startups through the following blended finance preparation sequence:

1. SUI Definition Workshop (VRF Programme, Month 1–2): Define the SUI, specify parameters, map to AIMM and IRIS+
2. SSOT Roadmap (Month 2–4): Design the SSOT architecture, implement Level 1, plan Level 2 automation
3. Impact Verification (Month 4–8): Commission first independent verification of SUI methodology and historical data
4. Instrument Design (Month 6–12): With CTH facilitation, engage DFI partners to design milestone trigger structure
5. Blended Finance Closing (Month 10–18): Close first blended finance instrument with verified SUI milestones

---

Next: MDB Taxonomy Alignment — how to map your SUI to IFC, IDB, and EU standards.

MDB Taxonomy Alignment

MDB Taxonomy Alignment

Multilateral Development Banks (MDBs) represent the single largest source of structured impact capital available to climate startups in emerging markets. Aligning a SUI to MDB taxonomies is the key that unlocks access to IFC, IDB Invest, ADB, AIIB, and EBRD investment pipelines. This page explains what alignment means, what it requires, and how to achieve it.

Why MDB Taxonomy Alignment Matters

MDBs collectively deploy over $50 billion annually in climate finance. Each MDB has its own impact measurement framework, but these frameworks share a common structure: they require investments to demonstrate "substantial contribution" to defined environmental or social objectives, and they use standardised taxonomies to assess this contribution. A startup that cannot map its impact to these taxonomies is effectively invisible to MDB investment teams.

The Key MDB Taxonomies

IFC AIMM (Anticipated Impact Measurement and Monitoring)

IFC's AIMM is a 100-point scoring system covering 29 sectors. It assesses impact across two dimensions: "Effects on People and Planet" (direct impact of the investment) and "Market Creation" (systemic change the investment triggers).

How SUI maps to AIMM:

• SUI specificity + quantifiability maps to AIMM's "How Much" assessment under Effects on People and Planet
• SUI attribution maps to AIMM's "Contribution" indicator
• SSOT verifiability maps to AIMM's "Risk" dimension — verified data reduces impact risk score
• SUI scalability maps to AIMM's Market Creation dimension — a replicable unit demonstrates market transformation potential

Minimum AIMM score for IFC investment: Typically 40+ out of 100. A startup with a well-defined, verified SUI can reasonably expect to score 50–65 on AIMM, placing it in the strong-impact investment category.

IDB Invest / IDB Lab

IDB Invest (the private sector arm of the Inter-American Development Bank) uses its own "Development Effectiveness Matrix" (DEM) alongside alignment to the IDB Group's 2025–2030 Strategic Framework. For Latin American climate startups, IDB alignment is often the highest-priority MDB target.

IDB focus areas most relevant to SUI-bearing startups:

• Climate Action: mitigation and adaptation solutions in agriculture, energy, water, cities
• Productive Capacity: technology companies improving agricultural productivity
• Sustainable Infrastructure: EV charging, renewable energy access

EU Taxonomy (European Sustainable Finance)

The EU Taxonomy defines six environmental objectives and specifies technical screening criteria for economic activities that make a "substantial contribution" to each objective. While originally designed for EU-based companies, EU Taxonomy alignment has become a global standard signal, particularly for companies seeking European institutional investor capital.

Most relevant EU Taxonomy objectives for CTH portfolio companies:

• Climate Change Mitigation — GHG emissions avoidance or removal
• Climate Change Adaptation — building resilience to climate impacts
• Sustainable use of water and marine resources
• Transition to a circular economy

The Alignment Matrix: SUI to MDB Taxonomies

SUI Element	AIMM (IFC)	DEM (IDB)	EU Taxonomy	TNFD
Outcome domain + IRIS+ code	Sector assignment, Effects indicator	Development outcome indicator	Environmental objective	TNFD metric
Baseline + counterfactual	Contribution score	Additionality assessment	DNSH assessment	Nature dependency mapping
SUI magnitude + unit	Scale score (How Much)	Quantified impact	Technical screening criteria value	Disclosure metric value
SSOT verification	Risk dimension (reduced)	Monitoring plan	Third-party verifier sign-off	Data quality rating
Scalability across applications	Market Creation score	Catalytic potential	Enabling activity assessment	Portfolio exposure mapping

Practical Steps for MDB Alignment

1. Choose your primary MDB target based on geography and sector (IDB for Latin America, IFC for global, ADB for Asia-Pacific)
2. Download the MDB's impact methodology document and identify which indicators map to your SUI
3. Complete a self-scoring exercise using the MDB's scoring rubric — this becomes your AIMM pre-screening document
4. Identify gaps: Which AIMM/DEM indicators does your SUI not yet address? Are there data collection or verification gaps?
5. Engage the MDB's SME or startup desk with your SUI specification document and self-scoring as a conversation starter — MDB investment officers appreciate founders who speak their taxonomy language

CTH Support for MDB Alignment

CleantechHUB maintains relationships with IDB Lab's Colombia team, IFC's Latin America advisory desk, and the Climate Finance Partnership intermediaries operating in the region. CTH portfolio startups with verified SUIs receive facilitated introductions to these networks as part of the VRF programme. The verified SUI specification document serves as the primary conversation-starter document for these introductions.

---

Continue to Chapter 5: Case Studies — the SUI in practice with Becaps and MubOn.

Chapter 5: Case Studies

Becaps (Argentina) — Chemical Displacement per Hectare

Becaps (Argentina) — Chemical Displacement per Hectare

Company Overview

Becaps is an Argentine agri-biotech company that has developed a proprietary microencapsulation technology for soil microorganisms. The core product delivers high-viability microbial consortia — primarily nitrogen-fixing bacteria and phosphate-solubilising fungi — to agricultural soils in a formulation that survives harsh field conditions and achieves root-zone colonisation at commercially meaningful rates.

Technology differentiation:

• Microbial viability at application: ≥10¹¹ CFU per gram (Colony Forming Units)
• Synthetic Displacement Ratio: 1.3:1 — for every 1 kg of Becaps product applied, 1.3 kg equivalent of synthetic nitrogen or phosphate fertiliser is displaced
• Field persistence: active colonisation confirmed at 90-day post-application in field trials
• Crop compatibility: validated for soy, maize, wheat, sunflower, and vegetable cultivation

The SUI: Chemical Displacement per Hectare

Parameter Set

Parameter	Value
SUI Name	Chemical Displacement per Hectare
Outcome Domain	Climate — GHG Emissions Avoided
IRIS+ Code	PI5765 (GHG Emissions Avoided by Investees)
Application Event	Application of 1 kg Becaps biostimulant to 1 hectare of cultivated land
Baseline	220 kg N/ha synthetic nitrogen application (INDEC 2023, Argentina national average)
Observed	85 kg N/ha (average across 120 trial plots, 2022–2024, certified by INTA)
Net Displacement	135 kg N/ha
CO₂e Conversion	135 × 0.758 CO₂e/kg N (IPCC AR6, Tier 1 emission factor for synthetic N production)
SUI Magnitude	102.4 kg CO₂e per hectare per growing season
Uncertainty	±12.3 kg CO₂e (±12%, 95% CI, based on plot-level variance across 120 trials)
Verification Protocol	Annual LCA audit by certified GHG verifier; SSOT ingest from ERP batch records + INTA lab reports

The Becaps SSOT Architecture

Tier 1: Ingest

• Source 1: ERP production records — batch ID, quantity produced (kg), production date, microbial viability QC result (CFU/g)
• Source 2: Logistics records — delivery date, customer ID, delivery location (GPS), quantity delivered (kg)
• Source 3: Customer application records — hectares treated per batch delivery (customer-reported, validated against land registry data for customers >50 ha)
• Source 4: INTA lab reports — soil nitrogen content pre/post application for monitored plots (12 per 500 ha treated, stratified sampling)

Tier 2: Digital Twin

• Model: Python-based LCA model (version-controlled in Becaps GitLab)
• Emission factors: IPCC AR6, INDEC regional agricultural statistics (updated annually)
• Baseline model: INDEC 2023 national average, disaggregated by province and crop type
• Uncertainty propagation: Monte Carlo simulation, 10,000 iterations per batch

Tier 3: Conversion

• IRIS+ PI5765 report: monthly update to GIIN platform
• SUI Ledger: append-only PostgreSQL table with one row per application event
• Auditor export: quarterly CSV package with full calculation audit log
• Blended finance dashboard: cumulative CO₂e displaced vs. milestone thresholds (real-time)

Blended Finance Structure

Becaps secured a blended finance structure in Q3 2024 using the SUI as trigger metric:

• First-loss provider: IDB Lab (via DGGF intermediary), $800K guarantee
• Commercial co-investor: Latin American agri-tech VC, $2.4M equity
• Leverage ratio: 3:1 commercial to concessional
• Milestone 1 trigger: 500 tonnes CO₂e displaced (verified) → $200K of guarantee converts to grant, interest rate on commercial debt reduces 75 bps
• Milestone 2 trigger: 2,000 tonnes CO₂e displaced → Full guarantee conversion, green revenue note eligibility

Key Lessons for Other AgTech Companies

1. The INTA partnership was decisive. Having national agricultural research institute validation of field trial data gave the LCA model credibility that self-collected data alone could not. For CTH portfolio companies, identifying the equivalent national research institute in their country early is critical.
2. Crop-specific baseline disaggregation mattered. Becaps initially used a single national nitrogen average — investors challenged this. Disaggregating the baseline by crop and province improved accuracy and defensibility.
3. The viability specification (10¹¹ CFU/g) became a product standard. Defining the minimum viable SUI trigger (a product lot must meet this viability threshold to count as an application event) forced quality discipline in production that improved product performance.
4. Customers became data partners. Integrating data collection into the customer relationship (land registry verification, application reporting) initially faced resistance. Framing it as "your data helps us show the financial system what you're doing" shifted the conversation.

---

Next: MubOn (Colombia) — kWh Delivered per Charging Point

MubOn (Colombia) — kWh Delivered per Charging Point

MubOn (Colombia) — kWh Delivered per Charging Point

Company Overview

MubOn is a Colombian cleantech company building shared, IoT-connected EV charging infrastructure for residential buildings, commercial properties, and public spaces in Latin American cities. Its platform solves the critical "apartment building problem" of EV adoption: residents of multi-unit buildings cannot install private home chargers, creating a range-anxiety barrier that suppresses EV uptake even when residents want to switch.

Business model innovation:

• Shared charging points installed in building parking facilities (shared among multiple residents)
• Smart scheduling algorithm optimises charging across users, avoiding peak grid demand
• IoT-enabled: real-time data on energy delivered, session duration, grid draw, user identity
• Revenue: per-session charging fees split between MubOn and building management
• Infrastructure cost: amortised across multiple users, reducing capex per EV owner by 60–70% vs. private charger

The SUI: kWh Delivered per Charging Point per Month

Primary SUI: Energy Displacement

Parameter	Value
SUI Name	kWh Delivered per Charging Point per Month
Outcome Domain	Climate — GHG Emissions Avoided (transport sector)
IRIS+ Codes	PI7685 (Clean Energy Generated), OI1284 (GHG Emissions Avoided)
SDGs	SDG 7 (Affordable Clean Energy), SDG 11 (Sustainable Cities), SDG 13 (Climate Action)
Application Event	One completed EV charging session through one MubOn-managed charging point
Baseline	Equivalent km driven by ICE vehicle: Colombian grid average emission factor (0.172 kg CO₂e/kWh, UPME 2024)
Counterfactual	Same trip driven in gasoline vehicle: 2.31 kg CO₂e/km (IDEAM 2024 Colombian light vehicle fleet average)
Observed Efficiency	0.154 kWh/km (EV fleet average in MubOn network, 2025)
Net Emission Factor	Grid sourced kWh: 0.172 kg CO₂e/kWh; ICE equivalent: 2.31/6.5 = 0.355 kg CO₂e/km → per kWh delivered: 0.355/0.154 − 0.172 = 2.31 − 0.172 = 1.12 kg CO₂e net avoided per kWh
SUI Magnitude	1.12 kg CO₂e avoided per kWh delivered (or 6.5 km of electric driving per kWh)
Uncertainty	±0.09 kg CO₂e (±8%, 95% CI — driven by grid emission factor uncertainty)
Verification Protocol	Monthly third-party audit of IoT session logs against billing data; annual LCA review

Secondary SUI: Infrastructure Utilisation

MubOn also defines a secondary SUI that captures its infrastructure efficiency innovation:

Parameter	Value
SUI Name	Charging Point Utilisation Rate
Baseline	<15% utilisation for traditional single-user charging points (ANDEMOS 2024)
Observed	25–40% utilisation for MubOn shared points
SUI Magnitude	+10 to +25 percentage points utilisation uplift per shared charging point
Financial Significance	Higher utilisation → faster payback on charging infrastructure capex → enables deployment at lower subsidy requirement

2025 Impact Results

MubOn's verified impact for calendar year 2025:

• Total kWh delivered: 320,000 kWh across all managed charging points
• Total charging sessions: 22,000 sessions
• GHG avoided: 358,400 kg CO₂e (0.358 tonnes CO₂e, or approximately 358 tonnes)
• Infrastructure utilisation: 31% average across all points (vs. 15% baseline)
• Average session energy: 14.5 kWh per session
• Cities operating: Bogotá, Medellín, Cali

SSOT Architecture: IoT-Native Pipeline

MubOn's SSOT is built on its IoT infrastructure, giving it a significant advantage over companies that must construct their data collection system from scratch:

Tier 1: Ingest

• IoT charging controller: real-time session data (start time, end time, kWh delivered, charger ID, user token)
• Grid metering: utility meter readings for each installed charging point (independent verification of IoT readings)
• UPME grid emission factor API: automatic monthly update from Colombian energy authority

Tier 2: Digital Twin

• Real-time calculation engine running on MubOn's cloud platform
• Per-session CO₂e avoided calculation (kWh × net emission factor)
• Uncertainty propagation from grid emission factor monthly updates
• Daily aggregation to the SUI Ledger

Tier 3: Conversion

• Monthly impact report: kWh delivered + CO₂e avoided, by city and property type
• IRIS+ PI7685 report for investor reporting
• SDG contribution statement (SDGs 7, 11, 13)
• Auditor export: session-level CSV with IoT raw data links

Pathway to Blended Finance

MubOn's verified SUI positions it for several financing structures unavailable to unverified EV infrastructure companies:

• Green Revenue Note: Financing secured against projected kWh delivery revenue, with coupon linked to verified impact milestones
• Municipal co-investment: Bogotá's Secretaría de Movilidad has indicated willingness to co-invest in public charging infrastructure that can demonstrate verified utilisation and emission impact data
• NAMA Facility alignment: Colombia's NAMA for urban mobility requires verified emission reductions — MubOn's SSOT makes it eligible

---

Next: Applying SUI Across Sectors — a generalisation guide for other industries.

Applying SUI Across Sectors

Applying SUI Across Sectors

The SUI framework is sector-agnostic. Any enterprise whose product or service produces a measurable, attributable environmental or social outcome can define a SUI. This page provides a generalisation guide across the major cleantech and impact sectors relevant to the CleantechHUB portfolio.

Sector-by-Sector SUI Templates

Agriculture and Food Systems

Sub-sector	Application Event	SUI Name	Unit	Key Baseline Challenge
Bio-inputs / Biostimulants	1 kg product applied per hectare	Chemical Displacement per Hectare	kg CO₂e / ha	Regional synthetic input averages vary widely; disaggregate by crop and region
Precision irrigation	1 irrigation event per hectare	Water Saved per Irrigation Event	m³ water / ha	Counterfactual irrigation volume from regional water authority statistics
Food waste reduction	1 kg food waste diverted from landfill	Landfill Diversion per kg	kg CO₂e / kg food	National landfill emission factors from EPA/environment ministry
Regenerative agriculture platform	1 hectare enrolled and verified per season	Soil Carbon per Hectare	tCO₂e / ha / year	Requires soil sampling; LCA scope 3 often controversial — document boundary carefully

Energy and Mobility

Sub-sector	Application Event	SUI Name	Unit	Key Baseline Challenge
EV Charging	1 kWh delivered through managed charger	kWh Delivered per Session	kg CO₂e avoided / kWh	Grid emission factor must be updated as grid decarbonises — a diminishing SUI over time
Distributed solar (C&I)	1 kWh generated by installed system	Clean kWh Generated per Month	kg CO₂e / kWh	Grid displacement assumes system substitutes grid power, not additional consumption
Electric two-wheelers (fleet)	1 km driven by fleet vehicle	Clean km per Vehicle	kg CO₂e / km	Fleet average ICE equivalent; leakage if displaced drivers switch to ICE alternatives
Energy efficiency (buildings)	1 month of occupancy in certified efficient building	Energy Intensity Reduction per m²	kWh / m² / month	Baseline energy intensity from building energy audit; weather-normalisation required

Water and Sanitation

Sub-sector	Application Event	SUI Name	Unit	Key Baseline Challenge
Water purification (household)	1 litre purified and delivered	Safe Water per Litre	DALY avoided / 1000 litres	WHO DALY factors for waterborne disease; counterfactual water source quality data
Industrial water recycling	1 m³ water recycled vs. discharged	Water Recycled per m³	m³ freshwater saved	Industrial water withdrawal baseline from watershed authority
Wastewater treatment	1 m³ wastewater treated to standard	Pollution Load Removed per m³	kg BOD removed / m³	Effluent quality standard (discharge permit defines counterfactual)

Circular Economy and Waste

Sub-sector	Application Event	SUI Name	Unit	Key Baseline Challenge
Plastic recycling	1 kg plastic collected and processed	Plastic Diverted per kg	kg CO₂e / kg plastic	Emission factor depends on plastic type and alternative disposal method
Electronics refurbishment	1 device refurbished and resold	Device Life Extension	kg CO₂e / device	Avoided manufacturing emissions require LCA of new device equivalent
Industrial symbiosis platform	1 kg waste matched between producer and consumer	Waste-to-Resource Match per kg	kg CO₂e / kg material	Complex: must account for transport emissions of rerouted material

Biodiversity and Land Use

Sub-sector	Application Event	SUI Name	Unit	Key Baseline Challenge
Forest conservation (REDD+)	1 ha protected for 1 year	Deforestation Avoided per Hectare	tCO₂e / ha / year	FREL (Forest Reference Emission Level) required; jurisdictional baseline complex
Ecosystem restoration	1 ha restored to target condition	Biodiversity Units Restored per Hectare	BNG units / ha (UK metric) or equivalent	Baseline habitat condition assessment; TNFD metrics preferred
Sustainable aquaculture	1 tonne of certified product harvested	Wild Fish Substitution per Tonne	tonne wild harvest avoided / tonne farmed	Feed conversion ratio and wild fish equivalent calculation required

Five Cross-Sector Principles

1. Outcome over output: Always define the SUI at the outcome level (CO₂e avoided, m³ water saved, DALY avoided) not the output level (units sold, installations completed). Investors and MDBs will push to the outcome level in due diligence — define it proactively.
2. Net not gross: The SUI is always net of counterfactual. A solar installation that adds capacity to an already-decarbonising grid has a smaller net SUI than an equivalent installation displacing coal. Acknowledge this honestly — it demonstrates credibility.
3. Scope boundaries must be stated: Scope 1 (direct), Scope 2 (energy), Scope 3 (value chain) boundaries must be explicit. For most cleantech products, the most impactful emissions are Scope 3 avoided — but these are also the hardest to verify. Be precise about which scopes your SUI covers.
4. Diminishing SUIs are acceptable: A grid-connected clean energy SUI will naturally decline as the grid decarbonises. Document this explicitly and include a projection of how the SUI evolves under different grid decarbonisation scenarios. This demonstrates sophistication rather than hiding a risk.
5. Negative SUIs must be disclosed: If your product produces some environmental harm alongside its primary benefit (e.g., mining impacts for battery metals, land use change for bioenergy crops), these must be disclosed and ideally included in a net SUI calculation. DNSH (Do No Significant Harm) compliance requires this — don't wait for an auditor to find it.

SUI Readiness Checklist by Sector

Before claiming a SUI in any sector, confirm:

• [ ] Outcome domain mapped to IRIS+, TNFD, or GRI indicator
• [ ] Application event defined (trigger condition, unit boundary)
• [ ] Counterfactual baseline identified with peer-reviewed or official source
• [ ] Measurement protocol exists for the outcome variable at the point of application
• [ ] Scope boundaries explicitly documented (Scope 1/2/3)
• [ ] Uncertainty range estimated (even if rough at first)
• [ ] Independent verifier identified (even if not yet engaged)
• [ ] SSOT architecture planned (even if not yet built)

---

Continue to Chapter 6: The CTH VRF Integration — how SUI fits into the Venture Readiness Framework.

Chapter 6: The CTH VRF Integration

SUI in the Venture Readiness Framework

SUI in the Venture Readiness Framework

The CleantechHUB Venture Readiness Framework (VRF) is the structured assessment and acceleration programme through which CTH evaluates, supports, and connects climate startups to capital. The SUI framework is embedded in the VRF as a mandatory component for startups seeking access to CTH's investor network and blended finance facilitation services.

VRF Overview

The VRF assesses startups across five readiness dimensions:

Dimension	What it assesses	SUI Relevance
1. Technology Readiness	TRL level, IP protection, scalability of the core technology	SUI specificity criterion — is the application event technically reproducible?
2. Market Readiness	Market size, customer discovery, go-to-market traction	SUI scalability criterion — does the market allow repeated SUI application events?
3. Team Readiness	Founder-market fit, team completeness, advisory board	SUI quantifiability — does the team have data science / measurement competency?
4. Financial Readiness	Financial model, funding history, use of funds clarity	SUI-WACC linkage — has the team mapped SUI verification to financing pathway?
5. Impact Readiness	SUI definition, SSOT status, verification plan, MDB alignment	The SUI framework is the primary tool for assessing Impact Readiness

Impact Readiness: The SUI Component

Impact Readiness is scored on a 0–100 scale, with the following sub-components:

Sub-component	Weight	What Earns Points
SUI Definition Quality	25%	All five criteria met (Specificity, Attribution, Quantifiability, Verifiability, Scalability); taxonomy linkage documented
Baseline Robustness	15%	Official or peer-reviewed baseline source; geographic and temporal specificity; degradation plan
SSOT Maturity	20%	Level 1–3 assessment; data governance documented; verifier access defined
Verification Status	25%	0 pts: no plan; 10 pts: verifier identified; 20 pts: methodology reviewed; 25 pts: full third-party verification complete
MDB/Taxonomy Alignment	15%	AIMM self-score completed; EU Taxonomy or TNFD linkage documented; DFI engagement initiated

VRF Milestones and SUI Requirements

The VRF programme is structured as a 6-month journey with four milestones, each with specific SUI deliverables:

Milestone 1 (Month 1): SUI Definition

Deliverable: Completed SUI Specification Document (all 8 parameters, taxonomy mapping, baseline documentation)

CTH support: Two facilitated workshops with the CTH Impact Team; access to SUI Template and baseline data resources

Gate condition: SUI Specification must score ≥60/100 on the CTH SUI Quality Rubric (see next page)

Milestone 2 (Month 2–3): SSOT Roadmap

Deliverable: SSOT Architecture document (data sources, system design, governance rules, current maturity level assessment)

CTH support: Technical advisory from CTH's data team; introduction to SSOT tooling partners

Gate condition: Clear pathway to SSOT Level 2 within 12 months; data governance policy drafted

Milestone 3 (Month 4): Verification Plan

Deliverable: Signed engagement letter with an independent verifier; verification scope and timeline agreed

CTH support: Warm introductions to CTH's network of certified impact verifiers (ISAE 3000-qualified, sector-experienced)

Gate condition: Verification engagement in place; cost budgeted in financial model

Milestone 4 (Month 5–6): Investor Readiness Package

Deliverable: Complete impact readiness package for investor distribution: SUI Spec + SSOT summary + verification status + AIMM self-score + blended finance opportunity map

CTH support: Facilitated investor introductions; pitch coaching on impact narrative

Gate condition: Impact Readiness score ≥75/100; at least one investor or DFI engagement meeting scheduled

SUI in the CTH Investment Thesis

CTH's investment thesis (for ventures in which CTH takes an advisory equity stake) explicitly prioritises startups that meet or are on a clear pathway to meeting SUI verification standards. The rationale:

• Verified SUI increases the probability of blended finance access, reducing the startup's equity dilution requirement and protecting CTH's advisory equity value
• SSOT systems produce the data quality that CTH's own impact reporting to its funders (P4G, AFCIA, SDC, Energy Catalyst) requires — a verified portfolio startup is a reportable result
• Startups with verified SUIs are more fundable, reducing the time-to-investment and increasing the success rate of CTH-facilitated fundraises — the primary metric of CTH's programme effectiveness

---

Next: Scoring Rubric for SUI Assessment — the detailed scoring criteria used in VRF evaluations.

Scoring Rubric for SUI Assessment

Scoring Rubric for SUI Assessment

This rubric is used by CTH programme staff to score the Impact Readiness of VRF applicants and portfolio startups. It is also provided to startups for self-assessment. The rubric is designed to be specific, repeatable, and free of subjective interpretation.

Section 1: SUI Definition Quality (25 points)

Criterion	0 points	3 points	5 points
Specificity (5 pts max)	Outcome described in generic terms ("reduces environmental impact")	Outcome linked to a recognised domain (climate, water, biodiversity) with approximate unit	Outcome linked to specific IRIS+/TNFD/GRI indicator; application event precisely defined; unit of application clear
Attribution (5 pts max)	No mention of counterfactual; gross impact only	Counterfactual acknowledged; baseline described in general terms	Documented baseline with source citation; geographic and temporal specificity; net impact calculation shown
Quantifiability (5 pts max)	Directional claim only ("significantly reduces emissions")	Numeric estimate with unit; calculation methodology described but not documented	Full calculation methodology documented; uncertainty range provided; measurement protocol specified
Verifiability (5 pts max)	No verification plan; self-certified data	Verifier type identified; verification standard referenced; timeline indicated	Independent verifier engaged or contracted; SSOT access protocol defined; verification standard specified (ISAE 3000 or equivalent)
Scalability (5 pts max)	SUI only demonstrated in pilot context; no protocol for replication	Protocol exists for replication; no infrastructure assessment	Protocol stable across geographies/customer types documented; SSOT infrastructure plan supports target volume

Section 2: Baseline Robustness (15 points)

Indicator	0 points	5 points	10 points	15 points
Baseline Source Quality	No source cited; founder estimate	Industry report or secondary source; limited geographic specificity	Government statistical source or peer-reviewed study; adequate geographic match	National statistical institute or IPCC/equivalent official body; country and crop/sector specific; year cited

Indicator	Deduction
Baseline older than 5 years with no update plan	−3 points
No baseline degradation assessment (what if counterfactual improves?)	−2 points
Baseline scope mismatch (national average applied to highly atypical geography)	−3 points

Section 3: SSOT Maturity (20 points)

SSOT Level	Score	Criteria
Level 0: Fragmented	0 points	Data in multiple disconnected tools; no central repository
Level 1: Consolidated	8 points	All impact-relevant data in one system; version-controlled; manually updated
Level 2: Automated	15 points	Automated data flows from source systems; validation on ingest; change log
Level 3: Audit-Ready	20 points	Immutable audit trail; role-based access with logging; structured export for verifiers

Bonus: +2 points if SSOT roadmap to next level is documented with timeline and resource plan.

Section 4: Verification Status (25 points)

Status	Score	Evidence Required
No verification plan	0 points	—
Verifier identified; not engaged	8 points	Name of proposed verifier; confirmation of their sector experience
Methodology reviewed by verifier	15 points	Written feedback from verifier on SUI methodology; issues identified and addressed
Data audit in progress	20 points	Signed engagement letter; audit scope agreed; SSOT access granted
Full verification complete	25 points	Issued verification statement following ISAE 3000 or GHG Protocol standard

Section 5: MDB / Taxonomy Alignment (15 points)

Indicator	Score	Evidence
No taxonomy mapping	0 points	—
IRIS+ mapping only	3 points	IRIS+ indicator code(s) cited in SUI spec
SDG + IRIS+ mapping	5 points	Relevant SDG targets identified; contribution mechanism described
AIMM self-score completed	8 points	Completed AIMM self-assessment document (IFC template or equivalent)
EU Taxonomy or TNFD alignment	10 points	Environmental objective identified; technical screening criteria assessed
DFI engagement initiated	12 points	Meeting held or email exchange with IFC, IDB, ADB, or regional MDB
DFI pipeline registered	15 points	Formal indication of interest from MDB investment team; project in their pipeline

Total Score Interpretation

Score Range	Classification	CTH Action
0–30	Impact Nascent	SUI Definition Workshop; not yet eligible for investor introductions
31–50	Impact Developing	SSOT and verification advisory; eligible for TA grant facilitation
51–70	Impact Ready	Eligible for impact investor introductions; blended finance scoping begins
71–85	Impact Advanced	Eligible for MDB introductions; blended finance structuring support
86–100	Impact Verified	Full CTH investor network access; results-based finance eligibility; flagship case study

---

Next: Implementation Guide for CTH Startups — how to build your SUI from zero.

Implementation Guide for CTH Startups

Implementation Guide for CTH Startups

This guide walks a CTH portfolio startup through building their SUI from zero to investor-ready verification. It is designed to be followed by a founding team without a dedicated impact measurement staff member. The CTH Impact Team is available to support each step.

Before You Start: What You Need

Gather the following before your first SUI definition session:

• Your product's technical specification or LCA (if one exists)
• Your current operational data — production records, sales data, customer delivery records (in whatever format they currently exist)
• Any market or industry data you use to describe your impact in pitch decks
• The name of at least one academic or government source that describes the problem you solve (e.g., the average synthetic fertiliser application in your target region)

Step 1: Define Your Application Event (Week 1)

The application event is the single most important definitional choice in the SUI process. It defines the boundary of "one SUI."

Guiding questions:

1. What is the smallest unit of your product or service that produces a measurable outcome? (1 kg of product, 1 kWh delivered, 1 session, 1 device)
2. Is this unit consistently countable in your operational records? (Can you tell from your current data how many of these events occurred last month?)
3. Does your team agree on the definition? (Product, sales, and impact team should all point to the same thing)

Common mistakes:

• Defining the application event too broadly ("one customer contract") — too aggregated to verify at unit level
• Defining it too narrowly ("one CFU of bacteria") — not operationally countable
• Conflating the application event with the outcome ("one tonne of CO₂e avoided" is an outcome, not an application event)

Output: A one-sentence application event definition. Example: "Application of 1 kg Becaps biostimulant to 1 hectare of cultivated land."

Step 2: Map to Taxonomy (Week 1)

Open the IRIS+ 5.3b metric browser at thegiin.org and search for indicators that match your outcome domain. You are looking for the most specific indicator that applies — not the most impressive-sounding one.

Output: IRIS+ code(s) + SDG target(s) added to the SUI Specification template.

Step 3: Research Your Baseline (Weeks 1–2)

The baseline research is often the step that takes the most time and produces the most value. You need to find an official or peer-reviewed source that quantifies what happens in your sector without your product.

Sources by sector:

• Agriculture: National agricultural census (DANE in Colombia, INDEC in Argentina, IBGE in Brazil), FAO country statistics, CIMMYT research papers
• Energy: National utility regulator grid emission factors (UPME in Colombia, CAMMESA in Argentina), IEA country profiles, national energy ministry statistics
• Water: IDEAM water quality data (Colombia), ANA (Brazil), national environment ministry reports, WHO/UNICEF JMP data
• Transport: IDEAM vehicle fleet emission factors, national transport ministry statistics, ECLAC transport data for Latin America

Output: Baseline value with source citation, year, geographic scope, and any limitations documented in the SUI Specification.

Step 4: Calculate Your SUI Magnitude (Week 2)

With your baseline and your observed data (from your own field trials, lab reports, or operational records), calculate the net impact per application event.

Required calculation elements:

1. Baseline value (from Step 3)
2. Observed value (from your data)
3. Net difference: Baseline − Observed
4. Conversion factor (from IPCC, EPA, or relevant standard): converts the net difference into your SUI unit (e.g., kg N displaced → kg CO₂e)
5. Uncertainty: estimate the range based on your sample size and measurement variability

Document every step. A future auditor needs to be able to follow your calculation from raw numbers to final SUI magnitude without asking you for help.

Output: SUI magnitude with uncertainty range, documented calculation methodology.

Step 5: Audit Your Data (Week 2–3)

Before engaging an external verifier, conduct an internal data audit:

1. Can you locate the source data for every number in your SUI calculation?
2. Is each data source stored in a consistent, dated format?
3. Is there a chain of custody between raw data and the calculated SUI magnitude?
4. Are there any gaps — periods where data was not collected, or records that were lost or overwritten?

Document gaps honestly. Verifiers prefer disclosed gaps with mitigation plans to hidden gaps discovered during audit.

Step 6: SSOT Assessment (Week 3)

Assess your current SSOT maturity level (0–3) using the criteria in the Scoring Rubric. Then design your path to Level 2:

• Which data source systems will feed the SSOT? (List each system and what data it holds)
• What is the central repository? (Start simple: a well-structured PostgreSQL database, Notion database, or even a Google Sheet with strict access control)
• Who can write data? Who can read? Who can export?
• How will you implement version control for corrections?

Step 7: Engage a Verifier (Week 3–4)

CTH maintains a directory of impact verifiers with sector experience in Latin American cleantech. Contact CTH's Impact Team at impact@cleantechhub.net to request an introduction. When approaching a verifier, provide:

• Your completed SUI Specification Document
• A brief description of your SSOT current state
• The volume of SUI events you want verified (approximate)
• Your target timeline for a verification statement

Step 8: Build Your Impact Investor Package (Week 4–6)

With the SUI defined and verification in progress, assemble your Impact Investor Package:

1. SUI Summary (1 page): The non-technical executive summary of your SUI — what you measure, why it matters, what the magnitude is
2. SUI Specification (full document): The complete parameter set, taxonomy mapping, baseline documentation
3. SSOT Architecture Summary (1 page): Current maturity, data sources, governance, path to Level 3
4. Verification Status Letter: Letter from your verifier confirming engagement and current status
5. AIMM Self-Score (1 page): Your self-assessment against IFC's AIMM framework
6. Blended Finance Opportunity Map (1 page): Which instruments you are eligible for now, and which you will be eligible for as verification progresses

CTH's Impact Team reviews this package before investor introductions. Use the Scoring Rubric to identify any sections below 70% before submitting for review.

Timeline Summary

Week	Deliverable	CTH Support Available
1	Application event defined; taxonomy mapped; baseline identified	SUI Workshop (2hr facilitated session)
2	SUI magnitude calculated; uncertainty range estimated; data audit complete	Data advisory call (1hr)
3	SSOT assessment complete; SSOT roadmap drafted; verifier shortlist identified	Technical advisory call; verifier introductions
4	Verifier engaged; verification scope agreed; SSOT Level 1 confirmed	Verification scope review
5–6	Impact Investor Package assembled; CTH review complete	Package review session; investor matching

---

Continue to Chapter 7: SUI Fundamentals Course — the structured learning path for deeper understanding.

Chapter 7: Course — SUI Fundamentals

Module 1: Impact Measurement Foundations

Module 1: Impact Measurement Foundations

Learning Objectives

By the end of this module, you will be able to:

1. Explain the difference between outputs, outcomes, and impact — and why the distinction matters financially
2. Name the five major impact measurement frameworks and describe their primary use case
3. Explain what "additionality" means and why investors require it
4. Describe the "double materiality" concept and how it applies to climate startups
5. Map your company's impact claim to at least one established framework

1.1 The Ladder of Impact Evidence

Not all impact evidence is equal. Impact investing practice recognises a hierarchy of evidence quality, from least to most credible:

Level	Evidence Type	Example	Investor Credibility
1	Anecdote	"Our farmers tell us they use less fertiliser"	Very low — not financeable
2	Output data	"We sold 10,000 kg of product in 2024"	Low — shows market adoption, not impact
3	Outcome proxy	"Based on product specifications, we estimate 1,000 tonnes CO₂e avoided"	Moderate — acceptable for seed stage
4	Pre/post measurement	"Soil nitrogen measured before and after application; 135 kg N/ha reduction observed"	Good — Series A acceptable
5	Controlled comparison	"Randomised plots with and without treatment; statistically significant N reduction"	Strong — Series B and beyond
6	Third-party verified	"ISAE 3000 verification of LCA methodology and field data; annual audit"	Institutional — blended finance eligible

Most climate startups enter the CTH programme at Level 2–3. The SUI framework is designed to move them to Level 4–6 efficiently.

1.2 Outputs vs. Outcomes vs. Impact

This distinction is foundational and consistently misunderstood:

• Output: What you produce or do. Examples: kg of biostimulant manufactured, kWh of charging capacity installed, litres of clean water distributed.
• Outcome: The change in the world that results from your outputs, in the short to medium term. Examples: kg of synthetic fertiliser displaced, CO₂e emissions avoided, incidence of waterborne disease reduced.
• Impact: The portion of the outcome that is attributable to your intervention — net of what would have happened anyway (counterfactual) and net of contributions from other actors. Impact = Outcome − Counterfactual − Deadweight − Displacement − Attribution to others.

The SUI is an impact claim, not an output or outcome claim. It requires both the measurement of the outcome AND the subtraction of the counterfactual to arrive at the attributable change.

1.3 Additionality: The Core Test

Additionality asks: "Would this impact have happened anyway, without your intervention?" If the answer is largely yes, the impact is not additional — it is deadweight. Investors and MDBs increasingly require proof of additionality before counting impact:

• Financial additionality: Would the project have happened without the concessional or impact finance? (Relevant to DFI investment)
• Impact additionality: Would the environmental outcome have occurred anyway — through market forces, regulation, or competitor actions?

A SUI with a robust counterfactual baseline is, by definition, demonstrating impact additionality. The baseline represents what would have happened without the enterprise — the SUI represents the additional change the enterprise produced.

1.4 Double Materiality

The EU's Corporate Sustainability Reporting Directive (CSRD) introduced the concept of "double materiality" — the requirement to report both:

1. Impact materiality: The company's impact on the environment and society (outside-in perspective)
2. Financial materiality: How environmental and social factors affect the company's financial performance (inside-out perspective)

The SUI framework operationalises double materiality for startups: the SUI captures impact materiality (what the company does to the world), while the SUI-WACC hypothesis captures financial materiality (how verified impact changes the company's cost of capital). For climate startups, these two dimensions are deeply linked — which is precisely why the SUI has financial relevance beyond its communication value.

1.5 The Major Frameworks: Quick Reference

Before proceeding, review these five frameworks at a high level. You do not need to master them — you need to know which one is most relevant to your sector and what it asks for:

1. IRIS+ (GIIN): Go to thegiin.org/iris-plus and search your sector. Find 2–3 indicators that match your SUI outcome. Bookmark them.
2. IMP Five Dimensions (Impact Frontiers): Read the one-pager at impactfrontiers.org. Notice the "Contribution" dimension — that's your additionality/attribution challenge.
3. IFVI / Capitals Coalition: If your impact has a monetary value angle, visit ifvi.org. The Product Framework translates physical impacts into financial values.
4. IFC AIMM: Download IFC's AIMM methodology document. Do a rough self-score. Note which dimensions you score low on — those are your SUI development priorities.
5. EU Taxonomy: Go to the EU Taxonomy Compass at ec.europa.eu/sustainable-finance. Search your sector activity. Read the technical screening criteria for your applicable environmental objective.

Reflection Exercise

Before moving to Module 2, answer these questions in writing:

1. What level of the Evidence Ladder does your current impact claim sit at?
2. Is your primary claim an output, outcome, or impact? If output or outcome — what would you need to make it an impact claim?
3. What is your counterfactual? What would happen in your target market without your product?
4. Which of the five frameworks is most relevant to your sector? What does it ask you to report?

Bring your written answers to your first CTH SUI Workshop session.

---

Next: Module 2: Defining Your SUI — the hands-on workshop session.

Module 2: Defining Your SUI

Module 2: Defining Your SUI

Learning Objectives

By the end of this module, you will have:

1. Written a complete application event definition for your primary product
2. Selected and documented your baseline with source citation
3. Calculated a first-pass SUI magnitude with uncertainty range
4. Completed the taxonomy mapping section of the SUI Specification Document
5. Identified the top three verification challenges for your SUI

2.1 The Application Event: Your Starting Point

The application event is the trigger: one occurrence of this event produces exactly one SUI. Getting this right is the most important step in the entire SUI process.

The Three-Question Test

Run your candidate application event through these three questions. All three must answer "Yes":

1. Is it operationally countable? Can you identify, from your existing business records, exactly how many times this event occurred in the last 12 months? (If the answer involves significant estimation or assumption, the event boundary is wrong.)
2. Is it causally proximate to the outcome? Is this event the direct cause of the environmental change — not a proxy, not an intermediate step, not a hoped-for consequence? (If you need to add "and then..." before reaching the outcome, you may be defining the event too far upstream.)
3. Is it stable across geography and time? Will the same application event definition work in a new city, a new country, or three years from now? (If the answer involves significant caveats, you may need geography-specific SUI variants — acceptable, but must be documented.)

Common Application Event Definitions by Sector

• AgTech bio-input: "Application of [X] kg of [Product] to [1 hectare] of [crop type] cultivation"
• EV charging: "Delivery of [1 kWh] to an electric vehicle through a [Company]-managed charging point"
• Water treatment: "Treatment of [1 m³] of water to [WHO/national standard] drinking quality"
• Industrial efficiency: "One month of operation of [Product] in [Building/Facility] of [size/type]"
• Circular economy: "Collection and verified processing of [1 kg] of [material type] at [certified facility]"

2.2 Baseline Research: Finding Your Counterfactual

The Baseline Search Protocol

Follow this sequence to find your baseline:

1. Government statistics first: National statistical institutes (DANE, INDEC, IBGE, INEI) publish sector-specific data annually. These are the most credible sources for baselines because they are official, nationally representative, and regularly updated.
2. Academic literature second: Google Scholar search: "[your sector] + [your country] + emission factor/average consumption/baseline" + recent year. Peer-reviewed studies published in the last 5 years are acceptable.
3. International agencies third: FAO, IEA, WHO, UNEP publish regional and global data that can serve as proxies when national data is unavailable.
4. Industry reports fourth: Trade associations, consulting firms (McKinsey, BCG, Systemiq) publish sector analyses. Use only if government and academic sources are unavailable, and document limitations.

Baseline Documentation Template

Baseline Value: _____ [unit]
Source: [Author/Agency, Year, Publication Title, URL]
Geographic Scope: [Country / Region / City]
Temporal Validity: [Year of data; update frequency]
Representativeness Note: [How well does this baseline represent your specific customers/geography?]
Limitations: [Any known biases, gaps, or caveats]
Update Trigger: [Condition under which this baseline should be recalculated]

2.3 Calculating Your SUI Magnitude

The Standard Calculation Template

Step 1: Baseline value per application event
        = [value from baseline research] [unit]

Step 2: Observed value per application event  
        = [value from your field data/product specs] [unit]

Step 3: Net difference
        = Step 1 − Step 2 = [difference] [unit]

Step 4: Convert to standard impact unit
        [difference] × [conversion factor from IPCC/EPA/standard source]
        = [SUI magnitude] [CO₂e/m³/kg/etc.]
        
Step 5: Uncertainty range
        Based on: [sample size, measurement method]
        Range: ± [N]% at 95% confidence
        Calculation: [standard deviation / sqrt(n) × 1.96]

SUI MAGNITUDE: [Step 4 result] ± [Step 5 range] [unit]

Where to Find Conversion Factors

• GHG emission factors: IPCC AR6 Annex II (downloadable from ipcc.ch); EPA Emission Factors Hub; DEFRA conversion factors (UK, widely used internationally)
• Agricultural emission factors: IPCC Agriculture, Forestry and Other Land Use (AFOLU) guidelines; FAO GLEAM database
• Grid emission factors: National grid operators (UPME for Colombia, CAMMESA for Argentina); IEA World Energy Outlook country data
• Water quality conversion factors: WHO water quality guidelines; IDEAM for Colombia

2.4 Taxonomy Mapping Exercise

For each component of your SUI, complete the following mapping:

1. Go to thegiin.org/iris-plus → "Explore Metrics" → filter by your sector (e.g., "Agriculture", "Energy", "Water")
2. Find the indicator that most closely matches your SUI outcome. Record: indicator name, code (e.g., PI5765), unit of measurement
3. Check if your SUI outcome aligns with an SDG target (not just an SDG goal). SDG targets are numbered (e.g., 2.4, 13.2). Record the most specific target that applies.
4. Optional: Check the EU Taxonomy Compass for your activity code and environmental objective

2.5 Identifying Verification Challenges

List the top three reasons a third-party verifier might challenge your SUI:

1. Data gap: Which data in your SUI calculation is estimated rather than directly measured? What would it take to directly measure it?
2. Attribution challenge: Is there a plausible alternative explanation for the outcome change you're claiming? How would you rebut it?
3. Baseline contestability: Could an investor argue your baseline overstates the counterfactual (making your SUI look larger than it is)? What evidence would you provide?

Answering these proactively in the SUI Specification Document signals sophistication and reduces verification friction.

Module 2 Deliverable

Complete the SUI Specification Document (template available from CTH's Impact Team). Submit to CTH at impact@cleantechhub.net for review before proceeding to Module 3.

The CTH Impact Team will provide written feedback within 5 business days. A follow-up call of 45–60 minutes will be scheduled to resolve any gaps before proceeding to SSOT design.

---

Next: Module 3: Building Your SSOT — data architecture for impact verification.

Module 3: Building Your SSOT

Module 3: Building Your SSOT

Learning Objectives

By the end of this module, you will have:

1. Assessed your current SSOT maturity (Level 0–3)
2. Mapped all data sources relevant to your SUI
3. Designed a minimum viable SSOT architecture for your company
4. Written your data governance policy (who can write, read, export)
5. Identified the tools and resources needed to reach SSOT Level 2

3.1 The SSOT Maturity Self-Assessment

Answer these questions honestly. The goal is to find your current state — not to impress anyone.

Level 0 Indicators (Fragmented)

• [ ] Impact data lives in multiple spreadsheets maintained by different team members
• [ ] There is no single place where someone new to the team could find all the data behind your impact claims
• [ ] Different presentations use different numbers for the same metric
• [ ] You could not produce a complete history of your impact events from the last 12 months in one hour

Level 1 Indicators (Consolidated)

• [ ] All impact data is in one central place (even a single well-maintained spreadsheet)
• [ ] The data is dated — you know when each entry was added
• [ ] Access is controlled — not everyone can edit the master file
• [ ] A new team member could find and understand the data without a guided tour

Level 2 Indicators (Automated)

• [ ] Data flows automatically from source systems (ERP, IoT, CRM) to the central repository
• [ ] Manual data entry is minimised or eliminated
• [ ] Changes are logged with timestamps and the identity of who made them
• [ ] Errors create a correction record, not an overwrite of the original

Level 3 Indicators (Audit-Ready)

• [ ] Records are cryptographically immutable once verified
• [ ] Role-based access control with access logging in place
• [ ] Verifiers can access underlying data directly without company staff assistance
• [ ] Structured export in verifier-specified format is automated
• [ ] SOC 2 or equivalent security certification in progress

3.2 Data Source Mapping

For every data element in your SUI calculation, identify:

Data Element	Current Location	Update Frequency	Owner	Gap to SSOT
Application event record (count)	[e.g., Sales ERP, manual CSV]	[daily/monthly]	[Sales team]	[needs automated export]
Outcome measurement (observed value)	[e.g., Lab report PDFs in Dropbox]	[per batch]	[R&D team]	[needs ingestion system]
Baseline value	[e.g., Static value in spreadsheet]	[annual]	[Impact lead]	[needs version control]
Conversion factors (emission factors)	[e.g., Hardcoded in Excel model]	[annual IPCC update]	[Impact lead]	[needs versioning and update trigger]

Complete this table for every data element. Gaps represent your SSOT development roadmap.

3.3 Minimum Viable SSOT Design

For most CTH portfolio startups at seed or Series A stage, the minimum viable SSOT has four components:

Component 1: The Central Repository

Choose one of the following, based on your technical capacity:

Option	Technical Level	SSOT Level Achievable	Annual Cost
Google Sheets (structured, access-controlled)	Low	Level 1	$0 (Workspace included)
Airtable or Notion database	Low-Medium	Level 1–2	$10–$50/month
PostgreSQL (self-hosted or Supabase)	Medium	Level 2–3	$25–$100/month
Dedicated impact data platform (Proof of Impact, Persefoni, Greenly)	Low (managed)	Level 2–3	$500–$5,000/month

CTH recommendation: Start with Airtable or a structured Google Sheet at Level 1. Build the data governance discipline before investing in technology. Most startups over-invest in tooling before establishing the human processes that make any tool work. Plan the path to PostgreSQL or equivalent at Series A.

Component 2: The Ingest Protocol

Define how data gets from each source system into the central repository:

• For each source system, specify: who extracts the data, in what format, at what frequency, and how they upload it to the central repository
• For automated sources (IoT, API): define the integration (webhook, API pull, ETL pipeline)
• Include a validation step: what checks run when data is ingested to catch errors before they enter the record

Component 3: The Change Log

The most important single addition to any existing data system. Implement a simple rule: no record is ever overwritten. Corrections are new records with a reference to the original. Every change carries a timestamp and the identifier of who made it. This can be implemented in Google Sheets with a formula-protected "corrections" tab — no engineering required.

Component 4: The Access Control Matrix

Document who has what access to the SSOT:

Role	Access Type	What They Can See/Do
Impact Lead	Write	Add new records, update baseline values (with change log entry)
CEO / CFO	Read	All aggregated data; no write access to underlying records
Board / Investors	Read (aggregated)	Impact dashboard; not raw records
Third-party Verifier	Read (full, time-limited)	All records including raw data, during audit window only
External (public)	None	No access to SSOT

3.4 The Digital Twin: Your Minimum Viable Version

Your Digital Twin does not need to be sophisticated at this stage. A minimum viable Digital Twin is a version-controlled calculation model with documented inputs. Here is a 5-step protocol:

1. Create a dedicated calculation file (Excel or Python notebook) that contains only your SUI calculation — not mixed with financial models or operational data
2. Document every input cell with a comment or adjacent cell containing: value source, source URL, year, geographic scope
3. Version control it: Save as "SUI_Model_v1.0_[date].xlsx" each time you make a material change. Store all versions (never delete old versions)
4. Lock the formula cells: Only the input cells should be editable; calculation cells are password-protected
5. Run a sensitivity analysis: Identify which inputs have the largest impact on the SUI magnitude; document which ones you monitor most closely

3.5 Module 3 Deliverable

Produce a 2-page SSOT Architecture Document containing:

• Current maturity level (with evidence for each indicator checked)
• Data source map (completed table from section 3.2)
• Central repository choice and rationale
• Ingest protocol (one paragraph per data source)
• Access control matrix
• Target maturity level and timeline (with resource requirements)

Submit to CTH with your SUI Specification Document for joint review.

---

Next: Module 4: Connecting Impact to Finance — translating your verified SUI into investor conversations.

Module 4: Connecting Impact to Finance

Module 4: Connecting Impact to Finance

Learning Objectives

By the end of this module, you will be able to:

1. Explain your SUI to a commercial VC, an impact investor, and a DFI in terms each will find compelling
2. Estimate the greenium effect on your next debt financing
3. Design a blended finance milestone structure using your SUI as the trigger metric
4. Identify the three most relevant blended finance instruments for your current stage
5. Build the financial section of your Impact Investor Package

4.1 Tailoring the SUI Message by Investor Type

Different investors respond to different aspects of the SUI. Tailor your pitch accordingly:

Commercial VC (Impact-Agnostic)

What they care about: Market size, defensibility, financial returns. Impact is a secondary concern unless it creates moat or regulatory advantage.

SUI message: "We've quantified the environmental benefit of our product at [X] kg CO₂e per [unit] — independently verified. This gives us access to green finance instruments and DFI co-investment that our competitors don't have. It means our next debt round will be [X] bps cheaper than theirs, and we have a pathway to blended finance structures that reduce our equity dilution over the next two rounds. Impact verification is our financial moat."

Impact VC (Dual Mandate)

What they care about: Achieving both financial returns and verified, scaled impact. They need to report impact metrics to their LPs. They fear "impact washing" accusations.

SUI message: "Our SUI is [Name] — [magnitude and unit], independently verified by [verifier name] against our SSOT data system. This maps to IRIS+ [code] and contributes to SDG [number]. We accumulate SUI events in an auditable ledger that you can access directly. Your LP impact report for [company name] will show [X] events per year by [date] — verifiable, not estimated. Here is our last annual verification statement."

Development Finance Institution (DFI)

What they care about: AIMM score, MDB taxonomy alignment, additionality, systemic market impact, ability to count this investment in their climate finance reporting to shareholders.

SUI message: "Our SUI is aligned to EU Taxonomy [objective] and we've completed an AIMM self-assessment scoring [X]/100. Our impact is additional — the counterfactual baseline uses [national statistics source] and our net displacement of [magnitude] is net of what would have happened through market forces alone. We have an independent verifier contracted and SSOT Level 2 in place. This investment can be counted in your climate finance reporting as [X] tonnes CO₂e avoided per year at scale."

4.2 The Greenium Calculation for Your Deal

Even if you are not issuing public bonds, you can estimate the greenium effect on your next financing:

Step 1: Estimate your next debt financing amount: $[X]M

Step 2: Identify the applicable greenium range for your instrument type:
  - Sustainability-Linked Loan: 10–25 bps rate reduction for hitting verified milestones
  - Green Revenue Note: 15–40 bps vs. conventional equivalent
  - DFI concessional loan: 100–300 bps below market (depends on DFI programme)

Step 3: Calculate annual interest saving:
  $[X]M × [bps]/10,000 = $[Y] per year

Step 4: Calculate NPV of interest saving over loan tenor:
  $[Y] × [tenor years] × [discount factor] = $[Z] NPV

Step 5: Compare to SUI verification cost:
  Cost: $[verification cost + SSOT implementation]
  Benefit: $[Z] NPV + strategic optionality (blended finance, MDB access)
  
  Net benefit: $[Z - cost] — this is the minimum case argument for SUI investment

4.3 Designing Your Blended Finance Milestone Structure

If you want to pursue blended finance, you need to propose a milestone structure — the specific SUI thresholds that trigger concessional capital events. Here is a design process:

Step 1: Define Your Milestones

Choose 3 milestone thresholds that represent meaningful scale for your business:

• Milestone 1: A threshold you are confident of reaching within 12–18 months (low risk for the first-loss provider)
• Milestone 2: A threshold representing successful early scaling (18–36 months)
• Milestone 3: A threshold that demonstrates market-transforming scale (36–60 months)

Express each milestone as a cumulative SUI count, not an annual rate. Example: "5,000 verified SUI events (hectares treated)" not "5,000 per year."

Step 2: Attach Capital Events

For each milestone, propose what happens to the concessional capital:

• Guarantee trigger: First-loss guarantee amount reduces pro-rata as milestones are hit (reducing commercial investor risk)
• Rate reduction trigger: Interest rate on concessional loan reduces by [X] bps per milestone hit
• Conversion trigger: Grant or recoverable grant converts to equity or debt at pre-agreed terms

Step 3: Verify the Verification Mechanism

For each milestone, specify how achievement will be verified:

• Verifier: [Name of contracted third-party verifier]
• Verification timing: [e.g., within 30 days of claimed milestone date]
• Data access: [Verifier has read access to SSOT dashboard; milestone claimed when SUI Ledger shows N verified events]
• Dispute resolution: [If verifier and company disagree, independent expert appointed by [mechanism]]

4.4 Blended Finance Instrument Selection

Use this decision tree to identify your most relevant blended finance instruments:

Is your SUI verified by a third party?
  NO → Technical Assistance Grant (fund the verification first)
  YES → continue

Is your SSOT at Level 2 or above?
  NO → Recoverable Grant (to build SSOT to Level 2)
  YES → continue

Do you have 12+ months of verified impact data?
  NO → Concessional Equity (angel-stage DFI)
  YES → continue

Is your cumulative SUI above [sector-specific threshold]?
  NO → First-Loss Guarantee (to de-risk commercial investment)
  YES → Results-Based Finance (milestone payments from DFI programme)

4.5 Building the Financial Section of Your Impact Investor Package

The financial section of your Impact Investor Package should contain:

1. SUI-WACC analysis (1 page): Show the five WACC reduction mechanisms and your estimated effect on each, with conservative/base/optimistic scenarios
2. Blended finance milestone structure (1 page): Three milestones with capital triggers and verification mechanism
3. Instrument eligibility map (1 page table): Which instruments you are currently eligible for and which require what additional verification steps
4. Greenium calculation (half page): Estimated interest saving on next debt financing with and without SUI verification
5. Impact capital provider target list (half page): 5–8 specific DFIs, foundations, or impact funds most likely to invest in your combination of geography, sector, and SUI type

---

Next: Module 5: Verification and Audit — preparing for and passing a third-party SUI verification.

Module 5: Verification and Audit

Module 5: Verification and Audit

Learning Objectives

By the end of this module, you will be able to:

1. Describe the ISAE 3000 verification process and what it requires from the company
2. Prepare a verification-ready data package
3. Anticipate and address the five most common verification findings before the audit begins
4. Understand the difference between limited assurance and reasonable assurance — and which you need
5. Build verification costs into your financial model and fundraising timeline

5.1 What Verification Means

Impact verification is not an inspection of your business — it is an audit of your impact claim. The verifier is answering one question: "Is the company's stated SUI magnitude supported by the evidence, methodology, and data system presented?"

Verification follows the ISAE 3000 (Revised) standard — the international standard for assurance engagements on non-financial information. The same standard used by accounting firms to audit sustainability reports. It has two assurance levels:

Assurance Level	Standard Expression	What it Means	Appropriate For	Typical Cost
Limited Assurance	"Nothing has come to our attention that causes us to believe the assertion is materially misstated"	Verifier reviewed the methodology and sampled the data; found no major problems	First verification; Series A stage; internal impact reporting	$8,000–$25,000
Reasonable Assurance	"In our opinion, the assertion is fairly stated in all material respects"	Full audit of methodology and data; positive opinion issued	Green bond prospectus; MDB co-investment; blended finance trigger	$25,000–$75,000

Start with limited assurance. Move to reasonable assurance when the financial stakes justify the higher cost — typically at the point of seeking a blended finance structure or green bond issuance.

5.2 Who Can Verify Your SUI

Your verifier must be:

• Independent: No financial interest in the verification outcome; not your investor, your auditor, or your technology provider
• Competent: Experience with the relevant sector (a GHG verifier for climate claims; a water quality specialist for water claims) and familiar with LCA methodology
• Credible: Recognised by the market — investors and DFIs will ask "who verified this?" The name should carry weight

Types of verifiers used in the CTH portfolio:

• Big Four accounting firms (Deloitte, PwC, EY, KPMG) — maximum credibility, highest cost, best for Series B+ and green bond issuances
• Specialist ESG/GHG verifiers (Bureau Veritas, SGS, TÜV Rheinland, SCS Global Services) — strong credibility, mid-range cost, good for Series A impact verification
• Boutique impact verifiers (Rina, Trellis Climate, South Pole verification services) — good sector expertise, lower cost, appropriate for limited assurance at seed/Series A
• Academic institutions (CIAT, IICA, national agriculture research institutes) — high technical credibility for AgTech claims, lower commercial credibility for financial instruments

Contact CTH at impact@cleantechhub.net for introductions to verifiers with Latin American experience in your sector.

5.3 Preparing for Verification: The Pre-Audit Checklist

Complete this checklist before the verifier engagement begins. Every unchecked item will slow the audit and increase cost.

Methodology Documentation

• [ ] SUI Specification Document completed and internally reviewed
• [ ] All emission factors and conversion coefficients cited with source, version, and date
• [ ] Baseline documented with source and geographic/temporal scope
• [ ] Impact pathway documented (from application event to outcome, step by step)
• [ ] Scope boundaries defined (Scope 1, 2, 3 coverage stated explicitly)
• [ ] Uncertainty quantification methodology documented
• [ ] Known limitations and material uncertainties disclosed

Data Package

• [ ] All application event records for the audit period exported from SSOT in structured format
• [ ] All outcome measurement data (lab reports, sensor data, field records) organised by application event
• [ ] Change log showing all data corrections during the audit period
• [ ] Baseline data source documents (PDFs of cited reports, downloaded data files)
• [ ] Digital Twin model file with all version history
• [ ] Access credentials prepared for verifier (read-only SSOT access, time-limited)

Governance Documentation

• [ ] Data governance policy (who can write/read/export)
• [ ] Quality control procedures (how errors are detected and corrected)
• [ ] Internal review process (who signs off on impact reports before external publication)

5.4 The Five Most Common Verification Findings

Anticipate and address these issues before the verifier finds them:

Finding 1: Undisclosed Data Gaps

What it looks like: Verifier finds periods where data was not collected or records are missing — and the company had not disclosed this.

Resolution: Proactively disclose all data gaps in the SUI Specification. Document the gap, its magnitude (what percentage of the audit period is affected), and how you handled it (extrapolation, conservative estimate, exclusion). Disclosed gaps are manageable; discovered gaps undermine trust.

Finding 2: Baseline Contested

What it looks like: Verifier argues your baseline overstates the counterfactual — for example, using a national average that is higher than what your specific customers would have used.

Resolution: Disaggregate your baseline to the most specific level available. If national data is the only option, document why and note the potential for overstatement. Some verifiers will accept a sensitivity analysis showing the SUI magnitude under a conservative (lower) baseline.

Finding 3: Attribution Not Established

What it looks like: Verifier cannot confirm that the outcome change is caused by your product rather than by concurrent factors (weather, management changes, other interventions).

Resolution: Design your data collection to include control data — measurements from comparable sites that did not receive your product, or pre/post measurements with explicit controls for other factors. At minimum, document the other factors that could explain the outcome change and explain why they are not the primary driver.

Finding 4: Double Counting

What it looks like: The same impact event is counted more than once — for example, a product applied to the same hectare in two consecutive seasons counted as two independent SUI events without adjustment for persistence effects.

Resolution: Define your SUI's temporal boundary explicitly. If one application per growing season is the standard, document this. If there is an overlap risk (e.g., product persistence carries impact into the next season), quantify it and subtract it from your SUI count or magnitude.

Finding 5: Inadequate Chain of Custody

What it looks like: The verifier cannot trace from the reported SUI total back to the individual application event records — the chain of evidence is broken somewhere between Tier 1 (Ingest) and the reported output.

Resolution: Test your own chain of custody before the audit. Pick a random SUI event from your ledger and trace it backwards: ledger entry → Digital Twin calculation → Tier 1 ingest record → source document. If you cannot complete this trace in under 10 minutes, your chain of custody has a gap that needs fixing.

5.5 After Verification: Maintaining Verification Status

Verification is not a one-time event — it is an ongoing commitment. Plan for:

• Annual re-verification: Most verifiers issue annual limited assurance statements. Budget for this in your operational costs from Series A onwards ($10,000–$30,000/year depending on volume).
• Material change triggers: Any material change to your product, methodology, or baseline requires notification to your verifier and possibly a mid-cycle review.
• Model version updates: When you update your Digital Twin (new emission factors, revised LCA boundary), document the change and its effect on historical SUI calculations. Some changes require retrospective restatement — better to address this proactively than to have investors or DFIs discover it.
• SSOT continuous improvement: Plan your path from your current SSOT level to the next level on an 18–24 month cycle. Verification costs decrease and reliability increases with each SSOT level upgrade.

Module 5 Deliverable

Produce a Verification Readiness Report — a self-assessment against the pre-audit checklist (section 5.3) with a remediation plan for each unchecked item. Submit to CTH with a proposed timeline for first verification engagement.

Upon completing all five modules and submitting all deliverables, you are eligible for:

• CTH "Impact Ready" designation (displayed in CTH portfolio materials)
• Facilitated introduction to CTH's verifier network
• CTH Impact Investor Package review and investor matching session
• Access to CTH's blended finance facilitation programme