Skip to content

Financial Models Overview

This section contains documentation for the financial models used in e-mobility subscription service analysis.

Modeling Objective & Workflow

The Challenge: Modeling a Complex Web of Transactions

The e-mobility ecosystem involves multiple business units conducting continuous transactions across both B2C (retail) and B2B (enterprise) frameworks. Each entity generates revenue, incurs costs, and affects others' capacity utilization—creating an interconnected web of dependencies that's difficult to analyze as a monolithic system.

This model framework solves that problem by:

  1. Creating clear boundaries – Each business unit is modeled as an independent Bottom-Up Financial Model (BUFM) with self-contained economics
  2. Isolating unit economics – Every BUFM can be validated independently, ensuring each stakeholder's financial logic is sound before integration
  3. Managing interconnectedness – A centralized Demand-Supply (DS) parameter set controls how business units interact, affecting both revenue and cost-productivity through utilization rates

Business Unit Relationships

Figure 1: Transaction architecture showing how the ABS Platform (OM) orchestrates B2C retail payments and B2B enterprise invoicing across Battery Fleet (BF), Swap Network (SN), and Power Generator (PG) business units.

Business Unit Ecosystem

Figure 2: Self-contained business unit economics with centralized Demand-Supply integration. Each BUFM has Scale-Dependent parameters (CapEx + Fixed OpEx), Variable OpEx (usage-driven), and KPIs. The DS layer controls PRICE × AMOUNT + Utilization parameters that affect all BUs simultaneously.

Why Two Diagrams?

Figure 1 (Transaction Flow) shows how money moves through the ecosystem: - B2C retail payments (VW → OM) - B2B enterprise invoicing (BF, SN, PG ↔ OM) - Real-time vs. contract-based settlement frameworks

Figure 2 (Economic Structure) shows how performance is influenced by the business environment: - Each BU operates independently with self-contained CapEx/OpEx parameters - The Demand-Supply (DS) layer acts as the central integration point - DS parameters (PRICE, AMOUNT, Utilization) affect both revenue AND cost-productivity - Changes in DS propagate to all BUs, creating dynamic interdependencies

Key Architectural Insight: By separating transaction mechanics (Figure 1) from economic dependencies (Figure 2), we achieve: 1. Modular validation – Each BUFM's unit economics can be verified independently 2. Centralized scenario control – Change DS parameters to test ecosystem-wide impacts 3. Clear causality – DS utilization affects revenue (fewer billable units) AND costs (poor fixed cost absorption) 4. Scalable complexity – Add new BUs without restructuring existing models

How It Works: BUFMs + Demand-Supply Integration

The project builds a suite of Bottom-Up Financial Models (BUFMs) that each represent a single stakeholder's economics (rider, battery asset owner, swap network operator, power generator, etc.). Every BUFM is:

  • Self-contained: Inputs, calculations, and KPIs can be validated independently before the model interacts with others.
  • Scenario-ready: Parameters live in shared data definitions so each BUFM can be stress-tested without breaking ecosystem-level alignment.
  • Provider/Consumer aware: Every stakeholder is either buying services from another or selling services to another, so cash flows are explicitly modeled as buy/sell transactions.

The Critical Insight: Utilization Drives Everything

Business units don't just trade money—they trade capacity (slots, batteries, kWh). When demand from one BUFM changes, it affects another BUFM's utilization rate, which simultaneously impacts:

  • Revenue side: Lower utilization = fewer billable units (lost sales)
  • Cost side: Lower utilization = poor fixed cost absorption (higher unit costs)
  • Profitability: Utilization misalignment cascades through ROI, payback period, and breakeven metrics

Example: If rider demand drops 20%, the Swap Network (SN) experiences: - ❌ 20% less revenue (fewer swap transactions) - ❌ Same fixed costs (property, labor, security) spread over fewer swaps - ❌ Higher cost-per-swap, lower margins, extended payback period

The Demand-Supply (DS) tab captures these dynamics by defining: - Transaction quantities (AMOUNT) – How many units flow between BUFMs - Transaction prices (PRICE) – Unit rates for services traded - Utilization impacts – How demand-supply balance affects installed vs. active capacity

Once a BUFM is validated in isolation, it participates in a provider-consumer workflow:

  1. Define service quantities – e.g., how many kWh a battery operator can deliver, how many swaps a rider consumes per day.
  2. Express the transaction in buy/sell terms – the provider sets a unit price, the consumer books a cost, and both models reference the same named parameters.
  3. Model population ratios – the Demand & Supply relationship captures how many providers and consumers exist and whether capacity matches demand.
  4. Propagate constraints – if a consumer cannot afford the price, or a provider cannot meet demand, those constraints feed back into each BUFM for re-balancing.

This workflow keeps the models modular while still enabling integrated ecosystem planning. See the Demand & Supply Model for detailed methodology on provider-consumer connections.

Integrated Workbook

📥 Download: E-Mobility Ecosystem Model

All models are integrated into a single Excel workbook with the following structure:

  • 📋 Assumptions - Shared parameters and baseline values (single source of truth)
  • 📊 Rider-Swapping - Delivery rider financial analysis
  • 🔋 Battery-Asset - Battery lifecycle and fleet management (planned)
  • 🏪 Swap-Network - Station operations and network economics (planned)
  • ⚡ Power-Generator - Energy supply and charging infrastructure (planned)
  • 📈 Dashboard - Integrated KPIs and visualizations (planned)
  • 🔗 Cross-Model-Analysis - Interdependency analysis (planned)

Why One Workbook?

  1. Shared Assumptions - All models reference the same baseline parameters
  2. Cross-Model Links - Direct cell references between tabs (e.g., rider demand → battery fleet size)
  3. Consistency - One source of truth for all ecosystem parameters
  4. Easy Distribution - Share one file with all stakeholder analyses

Available Models

Ecosystem Framework

Demand & Supply Model - Provider-consumer connection framework - Defines buy/sell relationships between stakeholders - Establishes quantity-price handshake methodology - Provides demand-supply ratio analysis - Enables modular yet coupled ecosystem planning

Ecosystem Participant Models

These models analyze the ecosystem from different stakeholder perspectives, each answering the fundamental question: "What's in it for me?"

  1. Rider Battery Circulation Model - Delivery rider perspective
  2. Analyzes the financial viability of switching from petrol to electric motorcycles
  3. Calculates fuel cost savings, investment payback period, and TCO
  4. Key decision: Should I invest in an electric bike with swap subscription?

Planned Models

  1. Battery Asset Model (battery-asset.md) - Asset owner perspective
  2. Battery lifecycle economics and fleet management
  3. Depreciation, maintenance, and replacement strategies

  4. Swap Network Model (swap-network.md) - Network operator perspective

  5. Station deployment, capacity planning, and operational costs
  6. Revenue from subscriptions vs. infrastructure investment

  7. Power Generator Model (power-generator.md) - Energy provider perspective

  8. Charging infrastructure and electricity supply economics
  9. Demand patterns and capacity planning

Model Integration

These models are interdependent - outputs from one model feed into others: - Rider demand → Network capacity requirements - Network operations → Battery fleet sizing - Battery lifecycle → Swap pricing strategy - Power costs → Subscription pricing

The Demand & Supply Model provides the framework for managing these interdependencies through: - Provider-consumer role definitions - Buy/sell transaction language - Demand-supply ratio tracking - Capacity-pricing adjustment mechanisms

Critical Modeling Methodology: Integer Unit Constraints & Scaling Factors

The Infrastructure Investment Challenge

Unlike digital services that scale continuously, physical infrastructure expands in discrete jumps. This fundamental constraint shapes every investment decision in the e-mobility ecosystem:

  • Battery Fleet (BF): Cannot deploy 19.5 battery packs—only 19 or 20 (1 pack = 10 batteries × 3.4 kWh)
  • Swap Network (SN): Cannot build 1.3 racks—only 1 or 2 racks (1 rack = 15 slots + 15 chargers)
  • Power Generator (PG): Cannot install 2.7 generator units—only 2 or 3 (1 unit = 120kW/261kWh)

Scale Factor = Integer Multiplier representing how many complete base units must be deployed.

Demand-Supply Misalignment: The Utilization Problem

When demand doesn't align perfectly with modular unit sizes, operators face a critical trade-off between capital efficiency and service quality:

Strategy 1: Round Up (Over-Investment)

Example: 20 slots needed, must build 2 racks = 30 slots (scale factor = 2)

Advantages: - 100% service level: All demand served immediately - Growth buffer: Extra capacity absorbs demand spikes and future growth - Customer satisfaction: No queuing, no service delays, no lost sales - Competitive advantage: Reliable service builds brand loyalty

Costs: - 67% utilization: 10 idle slots (33% wasted capacity) - Higher CapEx per active unit: $9,600 ÷ 20 active slots = $480/slot (vs $320 if perfectly sized) - Diluted fixed OpEx: Property rent, labor, security spread over underutilized assets - Longer payback period: More capital invested, same revenue stream - Reduced ROI: Lower return on investment due to idle capacity

Strategy 2: Round Down (Under-Investment)

Example: 20 slots needed, build only 1 rack = 15 slots (scale factor = 1)

Advantages: - 100% utilization: Every slot fully utilized, maximum asset efficiency - Lower CapEx: $4,800 initial investment (50% less than round-up) - Better unit economics: Higher ROI per installed slot - Faster payback: Less capital to recover

Costs: - 75% service level: Only 15 out of 20 riders served (25% unmet demand) - Customer churn: Unreliable service drives users to competitors - Revenue loss: Missing 25% of potential daily income (~$100/day) - Brand damage: Poor service reputation difficult to recover - Market share erosion: Competitors with better capacity capture frustrated customers - Growth bottleneck: Cannot scale revenue without new CapEx injection

The Two-Layer Economic Model

Our models explicitly separate these realities to capture the economic impact of integer constraints:

Infrastructure Layer (Integer-Constrained - What You Must Build): - Scale Factor: Integer only (1, 2, 3... units) - Installed Capacity: Scale factor × Base unit size - CapEx: Based on installed capacity (whole units) - Fixed OpEx: Property, insurance, labor, security (spread over installed capacity)

Operational Layer (Demand-Driven - What You Actually Use): - Active Demand: Real customer demand (can be any value from DS model) - Utilization Rate: Active demand ÷ Installed capacity - Revenue: Based on active capacity only - Variable OpEx: Energy, cycling, consumables (scales with actual usage)

Critical Metric: Utilization Rate = Active Demand / Installed Capacity

  • 100%: Perfect match (rare)—optimal economics, but no buffer for growth
  • 85-95%: Excellent range—minimal oversizing penalty, some growth buffer
  • 67-85%: Acceptable range—moderate over-investment, good service quality
  • <60%: Poor—serious capital efficiency problem, consider delaying expansion
  • >100%: Under-capacity—service degradation, immediate expansion needed

Real-World Example: Test Case A

Business Unit Demand Must Install Utilization Economic Impact
Battery Fleet 200 batteries 20 packs × 10 = 200 100% Perfect match! Optimal economics
Swap Network 20 slots 2 racks × 15 = 30 67% ⚠️ Over-investment: 10 idle slots, diluted fixed costs
Power Generator 714 kWh/day 2 units × 541 = 1,082 66% ⚠️ Over-capacity: 368 kWh/day unused, higher LCOE

Key Insight: Even in a carefully designed test case, 2 out of 3 business units experience 30-35% overcapacity due to integer constraints! This is a fundamental challenge of modular infrastructure investment.

Capacity Planning Strategies & Service-Level Dynamics

The "right" scaling strategy depends on business priorities, market maturity, and competitive dynamics:

Business Priority Scale Strategy Accept Optimize For When to Use
Market Capture Round up aggressively 60-80% utilization Service quality, growth readiness Early market, high growth phase
Capital Efficiency Round down conservatively Service delays, queuing ROI, payback speed Mature market, capital-constrained
Balanced Growth Phased modular expansion 75-90% utilization Incremental capacity adds Steady growth, predictable demand
Risk Mitigation Hybrid (some over, some under) Mixed utilization Portfolio optimization Uncertain demand, pilot phase

Dynamic Capacity Planning: - Stage 1 (Launch): Round down (prove demand before heavy investment) - Stage 2 (Growth): Round up (capture market share while demand is elastic) - Stage 3 (Maturity): Optimize (fine-tune capacity to stabilize utilization at 85-90%)

Beyond Simple Rounding: The Need for Advanced Analytics

Current Approach: Deterministic demand, static integer rounding, fixed utilization assumptions

This provides a foundation for strategic planning, but real-world operations face additional complexity:

🔮 Coming Soon—More Nuanced Analytical Tools:

1. Queueing Theory Models - Analyze wait times, service delays, and buffer capacity requirements - Determine optimal over-provisioning based on acceptable service-level targets - Model M/M/c, M/G/∞, and other queue disciplines for swap station operations - Example: How many slots needed to keep average wait time < 5 minutes during peak hours?

2. Discrete Event Simulation (DES) - Model hourly/daily demand variability, peak vs off-peak patterns - Simulate seasonal fluctuations, weather impacts, holiday effects - Test "what-if" scenarios: equipment failures, demand surges, competitor entry - Example: Simulate 1 year of operations with stochastic rider arrival patterns

3. Stochastic Optimization - Find optimal scale factors under demand uncertainty using Monte Carlo methods - Risk-adjusted capacity planning with confidence intervals - Multi-objective optimization: balance CapEx, service level, and utilization - Example: What's the 95th percentile capacity need for next quarter?

4. AI-Powered Demand Forecasting - Machine learning models to predict demand patterns from historical data - Time-series forecasting (ARIMA, LSTM neural networks) - Anomaly detection for unusual demand events - Example: Predict next month's swap demand with 90% accuracy

5. Real-Time Adaptive Capacity Planning - Dynamic algorithms that trigger modular expansion based on utilization trends - Predictive alerts: "Utilization trending toward 95%—plan for 3rd rack deployment" - Automated scenario generation for board-level investment decisions - Example: Dashboard showing "expand now" vs "wait 2 months" ROI comparison

Why This Matters:

  • Static models assume constant demand—but riders come in waves (morning commute peak, evening rush, weekend lulls)
  • Integer constraints become dynamic—when exactly to expand from 2 to 3 racks as demand grows 5% monthly?
  • Service-level trade-offs are probabilistic—is 90% slot availability acceptable, or do you need 99% to compete?
  • Capacity decisions have long lead times—ordering a new rack takes 3 months, but demand can shift in 2 weeks
  • Uncertainty is expensive—over-building wastes capital, under-building loses customers

These advanced tools will help operators make smarter, data-driven capacity decisions under real-world uncertainty—balancing capital efficiency with service reliability in a way that simple integer rounding cannot capture.

Methodological Evolution:

Phase 1 (Current): Deterministic integer scaling
         ↓
Phase 2 (Next):    Stochastic demand modeling + queueing theory
         ↓
Phase 3 (Future):  AI-powered predictive capacity optimization

Model Structure

Each model typically includes: - Input parameters - Calculation logic - Output metrics and KPIs - Sensitivity analysis