Chapter 7: Course — SUI Fundamentals
A structured 5-module learning path for founders and impact teams.

Module 1: Impact Measurement Foundations
Module 1: Impact Measurement Foundations
Module Overview: Before defining a SUI, founders must understand why and how impact measurement has evolved, what the major frameworks require, and where the field is heading. This module provides that foundation in approximately 2 hours of reading and reflection.
Learning Objectives
By the end of this module, you will be able to:
Explain the difference between outputs, outcomes, and impact — and why the distinction matters financially
Name the five major impact measurement frameworks and describe their primary use case
Explain what "additionality" means and why investors require it
Describe the "double materiality" concept and how it applies to climate startups
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:
Impact materiality: The company's impact on the environment and society (outside-in perspective)
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:
IRIS+ (GIIN): Go to thegiin.org/iris-plus and search your sector. Find 2–3 indicators that match your SUI outcome. Bookmark them.
IMP Five Dimensions (Impact Frontiers): Read the one-pager at impactfrontiers.org. Notice the "Contribution" dimension — that's your additionality/attribution challenge.
IFVI / Capitals Coalition: If your impact has a monetary value angle, visit ifvi.org. The Product Framework translates physical impacts into financial values.
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.
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:
What level of the Evidence Ladder does your current impact claim sit at?
Is your primary claim an output, outcome, or impact? If output or outcome — what would you need to make it an impact claim?
What is your counterfactual? What would happen in your target market without your product?
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
Module Overview: This is the practitioner module — you will complete your SUI Specification Document by the end. Allow 3–4 hours for reading and working through the exercises. Have your product data, market research, and the Module 1 reflection answers ready.
Learning Objectives
By the end of this module, you will have:
Written a complete application event definition for your primary product
Selected and documented your baseline with source citation
Calculated a first-pass SUI magnitude with uncertainty range
Completed the taxonomy mapping section of the SUI Specification Document
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":
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.)
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.)
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:
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.
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.
International agencies third: FAO, IEA, WHO, UNEP publish regional and global data that can serve as proxies when national data is unavailable.
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:
Go to thegiin.org/iris-plus → "Explore Metrics" → filter by your sector (e.g., "Agriculture", "Energy", "Water")
Find the indicator that most closely matches your SUI outcome. Record: indicator name, code (e.g., PI5765), unit of measurement
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.
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:
Data gap: Which data in your SUI calculation is estimated rather than directly measured? What would it take to directly measure it?
Attribution challenge: Is there a plausible alternative explanation for the outcome change you're claiming? How would you rebut it?
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
Module Overview: The SSOT is the infrastructure that makes SUI verification possible. This module guides you through assessing your current data architecture, designing a minimum viable SSOT, and planning the path to audit-readiness. Allow 2–3 hours.
Learning Objectives
By the end of this module, you will have:
Assessed your current SSOT maturity (Level 0–3)
Mapped all data sources relevant to your SUI
Designed a minimum viable SSOT architecture for your company
Written your data governance policy (who can write, read, export)
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:
Create a dedicated calculation file (Excel or Python notebook) that contains only your SUI calculation — not mixed with financial models or operational data
Document every input cell with a comment or adjacent cell containing: value source, source URL, year, geographic scope
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)
Lock the formula cells: Only the input cells should be editable; calculation cells are password-protected
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
Module Overview: A verified SUI is only valuable if it changes your financing conversations. This module teaches you how to present your SUI to different types of investors, how to map it to blended finance instruments, and how to use it as a negotiating tool to reduce your cost of capital. Allow 2–3 hours.
Learning Objectives
By the end of this module, you will be able to:
Explain your SUI to a commercial VC, an impact investor, and a DFI in terms each will find compelling
Estimate the greenium effect on your next debt financing
Design a blended finance milestone structure using your SUI as the trigger metric
Identify the three most relevant blended finance instruments for your current stage
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:
SUI-WACC analysis (1 page): Show the five WACC reduction mechanisms and your estimated effect on each, with conservative/base/optimistic scenarios
Blended finance milestone structure (1 page): Three milestones with capital triggers and verification mechanism
Instrument eligibility map (1 page table): Which instruments you are currently eligible for and which require what additional verification steps
Greenium calculation (half page): Estimated interest saving on next debt financing with and without SUI verification
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
Module Overview: Third-party verification is the inflection point that converts your SUI from a credible claim into a financeable asset. This module prepares you for the verification process — what to expect, how to prepare, what common findings look like, and how to maintain verification status over time. Allow 2 hours.
Learning Objectives
By the end of this module, you will be able to:
Describe the ISAE 3000 verification process and what it requires from the company
Prepare a verification-ready data package
Anticipate and address the five most common verification findings before the audit begins
Understand the difference between limited assurance and reasonable assurance — and which you need
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
Congratulations on completing the SUI Fundamentals Course. You now have the conceptual foundation, practical tools, and implementation roadmap to build a verified Scalable Unit of Impact. The CTH Impact Team is available at impact@cleantechhub.net to support your implementation. We look forward to reporting your verified impact alongside our portfolio companies worldwide.