Pitch Deck

Populating Investment Banking Pitch Deck Templates

Reference Files

Read all reference files at task start before beginning any work. These contain critical patterns and anti-patterns that will affect your approach. Do not wait until you encounter issues.

---

Workflow Decision Tree

What type of task is this?

┌─ Populating empty template with source data?
│  └─→ Follow "Template Population Workflow" below
│
├─ Editing existing populated slides?
│  └─→ Extract current content, modify, revalidate
│
└─ Fixing formatting issues on existing slides?
   └─→ See "Common Failures" table, apply targeted fixes

---

⚠️ Critical Rendering Limitation

LibreOffice is used for validation but DOES NOT render PowerPoint files accurately. It will mangle fonts, gradients, shape positions, text wrapping, and some table formatting.

What this means: A slide that passes visual validation in LibreOffice may still have issues in Microsoft PowerPoint. The validation loop catches structural issues (missing content, broken tables, placeholder formatting retained) but cannot catch font substitution, subtle alignment shifts, or gradient problems.

Required action: Always include this statement when delivering output:

"This file was validated using LibreOffice. Please review in Microsoft PowerPoint before distribution, as rendering differences may exist."

---

Template Population Workflow

Copy and track progress:

Pitch Deck Progress:
- [ ] Phase 1: Extract and validate source data
- [ ] Phase 2: Map content to template sections
- [ ] Phase 3: Populate slides with proper formatting
- [ ] Phase 4: Validate → Fix → Repeat until clean
- [ ] Phase 5: Final verification

Phase 1: Data Extraction

1. Create backup of original template before any modifications — copy to [filename]_backup.pptx. Direct XML editing or unexpected errors can corrupt files. 2. Identify all source materials (Excel, CSV, PDF reports, Word documents, databases, web sources) 3. Extract relevant data points from each source 4. Validate all numbers against original sources 5. Standardize units and currency (convert all figures to the primary unit/currency used in the template) 6. Note any calculations that need verification → see `calculation-standards.md` for formulas

Phase 2: Content Mapping

1. Open and visually review the template — understand its structure, style, and existing content before modifying 2. Analyze template structure — identify all placeholder areas and content boxes 3. Map source data to corresponding template sections → see `slide-templates.md` for mapping guidance 4. Identify placeholder guidance boxes (colored instruction boxes from task creator) 5. Note any data gaps or mismatches → see `slide-templates.md` for resolution

Phase 3: Template Population

1. Remove or reformat placeholder boxes — colored instruction boxes show WHAT to create, not HOW to format. Delete them and create properly formatted content in their place. See Critical Anti-Patterns. 2. Populate each section with mapped content (focus on content first) 3. Then apply formatting to match template style → see `formatting-standards.md` 4. Create tables as actual table objects (NEVER use pipe/tab-separated text) → see `xml-reference.md` 5. Create arrows/shapes as PowerPoint objects → see `xml-reference.md` 6. Insert company logo if provided in task files; if not available, flag to user: "[LOGO NOT PROVIDED - please supply company logo]"

Phase 4: Validate → Fix → Repeat

This is a feedback loop. Repeat until all checks pass OR escalation is triggered.

# Convert to images for visual validation
soffice --headless --convert-to pdf presentation.pptx
pdftoppm -jpeg -r 150 presentation.pdf slide

Validation checklist (check each slide image):

• [ ] Text readable against background?
• [ ] Tables are actual objects (columns aligned, NOT pipe/tab-separated text)?
• [ ] Charts/tables fill designated areas?
• [ ] Bullet formatting consistent within sections?
• [ ] Font sizes match across same-level boxes?
• [ ] No content beyond slide boundaries?
• [ ] No placeholder formatting retained (no large colored boxes with data dumped in)?
• [ ] No text-based "tables" (no | or tab separators creating fake columns)?
• [ ] Cross-slide consistency: Same metrics/figures identical across all slides where they appear?

Fix cycle protocol:

After 3 cycles, if issues remain: 1. List each unresolved issue with slide number and description 2. Explain what was attempted 3. Deliver the file with explicit disclaimer: "The following issues could not be resolved automatically: [list]. Manual review required."

Do not continue cycling indefinitely. Some issues (font rendering, complex shape alignment) may require manual intervention in PowerPoint.

Phase 5: Final Verification

Run through the Final Quality Checklist before delivering.

---

Quick Reference Tables

Bullet Symbols

Slide Hierarchy Levels (Typical)

These are typical ranges—adjust based on template specifications:

Font Consistency Matching

Boxes at the same hierarchy level MUST use identical font sizes:

Rounding for Presentation

These are typical conventions — adjust based on the magnitude of values and template style:

Principle: Rounding should not materially change the figure. For smaller values, use finer precision.

Text Density Rules

• Max 6-7 bullets per content box
• Max 2 lines per bullet point
• Parenthetical examples: same line or indented below
• No orphan words (single word on new line)

Alignment Principles

Vertically stacked boxes must have identical:

• Left margin position, bullet indentation, text start position, box width

Horizontally adjacent boxes must have identical:

• Top position, height (where possible), internal padding

Multi-Slide Consistency

When the same data appears on multiple slides:

• Use identical figures, formatting, and terminology
• If a metric is updated on one slide, update all occurrences
• Cross-reference during validation to catch mismatches

---

MUST Requirements

These requirements are non-negotiable regardless of template:

---

Critical Anti-Patterns: NEVER DO THESE

These failures occur when placeholder formatting is mistaken for output formatting. Recognizing these patterns is essential.

Anti-Pattern 1: Populating Data INTO Placeholder Boxes

What happens: Template has colored instruction boxes (yellow, orange, etc.) with guidance text. Model replaces the guidance text with actual data BUT KEEPS THE COLORED BOX.

Why it's wrong: The colored box IS the placeholder. It tells you what content goes there. The output should have different formatting — typically dark text on white/light background, or properly styled shapes.

Recognition test: If your populated slide has large colored rectangles filled with data text, you have copied the placeholder format instead of replacing it.

Critical distinction — two types of "placeholders":

If uncertain: check if the shape exists on an empty slide from the same template. Layout placeholders persist; instruction boxes are regular shapes.

Anti-Pattern 2: Text-Based "Tables"

What happens: Model creates table-like content using separator characters (|, tabs, spaces) instead of actual table objects.

Why it's wrong: This is NOT a table. Columns will never align properly, it cannot be formatted consistently, and it looks unprofessional.

Recognition test: If you're typing | characters or relying on spaces/tabs to create columns, you're creating text, not a table.

MUST verify: After creating any table, verify it is an actual table object. See `xml-reference.md` for verification methods.

Anti-Pattern 3: Inheriting Placeholder Contrast

What happens: Placeholder uses light text on colored background (e.g., white on yellow). Model populates data but keeps this color scheme, resulting in hard-to-read output.

Why it's wrong: Placeholder colors are deliberately distinct to signal "replace me." Production slides typically use dark text on light backgrounds for body content.

Recognition test: If your populated content has light/white text on bright colored backgrounds in body areas (not headers), you've inherited placeholder formatting.

Correct approach: Apply production formatting — typically dark text (#000000 or #333333) on white or light backgrounds for body content. Headers and accent areas may use brand colors.

Summary: Placeholder vs. Production

The placeholder tells you WHAT to create, not HOW to format it.

---

Common Failures

For detailed explanations of the most critical failures, see Critical Anti-Patterns above.

---

Error Handling

If PDF/image conversion fails: 1. Check LibreOffice is installed: which soffice 2. Try alternative: libreoffice --headless --convert-to pdf presentation.pptx 3. If still failing, open in PowerPoint/LibreOffice manually and export

If source data has inconsistencies or conflicts: 1. Priority order: Use data explicitly provided in the task files first 2. If using data from other sources (web search, external documents), flag this to the user 3. Document any discrepancies explicitly 4. Add footnote explaining data source choice

If calculations don't match source projections: 1. Show your calculation methodology 2. Note the discrepancy and possible causes (different base year, methodology) 3. Present both values if material difference 4. Flag to user for resolution

---

Table Structure Guidelines

When creating tables (MUST be actual table objects):

Column Alignment:

• Text columns: Left-aligned (header and content)
• Numeric columns: Right-aligned or center-aligned (header matches content)

Header Row:

• Bold text
• Shaded background (template's brand color)
• White or contrasting text

Consensus/Total Row:

• Bold text
• Separator line above
• Distinct background shading

Width: Fill designated section width completely.

For XML implementation, see `xml-reference.md`.

---

Footnote Format

Format:

Sources: [Source 1] (Year), [Source 2] (Year).
Notes: (1) [First note]; (2) [Second note].

Example:

Sources: Grand View Research (2024), Mordor Intelligence (2024), Markets and Markets (2023).
Notes: (1) Excludes hardware revenue; (2) Includes both B2B and B2C segments.

All superscript numbers (¹, ², ³) in slide body MUST have corresponding Notes entries.

---

Logo Placement

• Use logo file provided in task materials
• If no logo provided, flag to user: "[LOGO NOT PROVIDED - please supply company logo]"
• Position: typically top-right, consistent size across slides, must not overlap content

---

Data Requirements by Slide Type

For detailed data requirements, formatting principles, and example column headers for each slide type, see `slide-templates.md`.

Common slide types covered: Market Definition, Market Sizing/TAM, Competitive Landscape, Financial Summary, Transaction Comparables.

---

Final Quality Checklist

Before delivering the populated template, verify:

Data Accuracy

• [ ] All figures match original source documents
• [ ] Calculated values verified against formulas (see `calculation-standards.md`)
• [ ] Years and time periods are correct
• [ ] Company/competitor names spelled correctly
• [ ] Same figures are identical across all slides where they appear

Content Mapping

• [ ] Every template section populated with appropriate data
• [ ] No [bracket] placeholder text remaining
• [ ] All source citations included in footnotes
• [ ] Footnote numbers (¹²³) have corresponding Notes entries

Formatting

• [ ] Text readable against all backgrounds (sufficient contrast)
• [ ] Tables are actual table objects (NOT pipe/tab-separated text)
• [ ] Charts/tables fill designated areas (no thumbnails)
• [ ] Bullet formatting consistent within each section
• [ ] Font sizes match across same-level boxes
• [ ] No content extends beyond slide boundaries
• [ ] No placeholder boxes retained with data dumped inside
• [ ] No colored instruction boxes in final output

Template Compliance

• [ ] Placeholder instruction boxes reformatted or removed
• [ ] Formatting matches template style (colors, fonts)
• [ ] Logo present and correctly positioned
• [ ] Production formatting applied (dark text on light background for main content)

Final Step

• [ ] Recommend user validate in Microsoft PowerPoint before distribution (LibreOffice may render differently)

Calculation Verification Reference

This file provides formulas and guidelines for verifying pre-calculated values in source data before populating templates. Source data should already contain calculated figures—use these formulas to verify accuracy.

Contents

• Key Verification Formulas
• Consensus Methodology
• Rounding Guidelines
• Verification Checklist
• Red Flags to Investigate

---

Key Verification Formulas

CAGR Projection

Formula:

Future Value = Present Value × (1 + CAGR)^n

Variables:

• Present Value: Current/base year market size
• CAGR: Compound Annual Growth Rate (as decimal, e.g., 16.4% = 0.164)
• n: Number of years between base and target year

Verification example:

Source claims: $22.1bn (2024) at 16.4% CAGR = $55.0bn (2030)

Verify: 22.1 × (1.164)^6 = 22.1 × 2.488 = 55.0 ✓

Calculating n (years): Count years between base and target year. Examples: 2024→2030 = 6 years, 2025→2030 = 5 years.

Valuation Multiples

EV/Revenue:

EV/Revenue Multiple = Enterprise Value ÷ Revenue
Implied EV = Revenue × Multiple

EV/EBITDA:

EV/EBITDA Multiple = Enterprise Value ÷ EBITDA
Implied EV = EBITDA × Multiple

Verification example:

Source claims: $436m deal at 9.7x revenue multiple on $45m revenue

Verify: 436 ÷ 45 = 9.69 ≈ 9.7x ✓

Market Share

Formula:

Market Share = (Segment Size ÷ Total Market Size) × 100

Verification example:

Source claims: Online segment ($18bn) is 28% of total market ($65bn)

Verify: 18 ÷ 65 = 0.277 = 27.7% ≈ 28% ✓

Growth Rate

Year-over-Year:

YoY Growth = (Current Year - Prior Year) ÷ Prior Year × 100

CAGR from endpoints:

CAGR = (End Value ÷ Start Value)^(1/n) - 1

---

Consensus Methodology

When source data contains multiple estimates, verify consensus calculations:

Size Consensus (Range)

Method: Full min-max range across all sources

Example:

Sources: $14.9bn, $18.3bn, $21.1bn, $21.2bn, $22.1bn
Consensus: $15-22bn (rounded to nearest $1bn)

CAGR Consensus (Central Cluster)

Method: Exclude outliers (highest and lowest), use central cluster range

Example:

Sources: 10.6%, 16.4%, 17.2%, 19.0%, 22.7%
Exclude outliers: 10.6% (low), 22.7% (high)
Central cluster: 16.4%, 17.2%, 19.0%
Consensus: 16-19% or 16-17% (conservative)

Projection Consensus

Method: Apply consensus CAGR to midpoint of size range

Example:

Size range: $15-22bn → Midpoint: $18.5bn
CAGR consensus: 16-17%
At 16%: 18.5 × (1.16)^6 = $45.1bn
At 17%: 18.5 × (1.17)^6 = $47.5bn
Consensus projection: $45-48bn

---

Rounding Guidelines

These are typical conventions — adjust based on the magnitude of values and template style:

Rounding principles:

• Rounding should not materially change the figure — for smaller values, use finer precision
• Consistency matters more than precision — use same rounding across similar figures
• When creating ranges, round down for low end, round up for high end
• For summary statistics (mean, median), match precision of input data

---

Verification Checklist

Before using any calculated value from source data:

Formula Verification

• [ ] Projection uses correct CAGR formula: PV × (1 + r)^n
• [ ] Multiples calculated as EV ÷ Metric (not reversed)
• [ ] Growth rates use correct base year in denominator
• [ ] Percentage shares sum to ~100% where applicable

Input Verification

• [ ] Base year figures match source documents
• [ ] CAGR/growth rates match stated source methodology
• [ ] Time periods (n) calculated correctly
• [ ] Currency and units consistent ($bn vs $m)

Output Verification

• [ ] Calculated result matches source's stated figure
• [ ] If mismatch, investigate methodology difference
• [ ] Rounding applied consistently
• [ ] Results are plausible (no order-of-magnitude errors)

Consensus Verification

• [ ] All sources included in range calculations
• [ ] Outlier exclusion methodology documented
• [ ] Midpoint calculations use correct averaging
• [ ] Range bounds represent actual min/max or documented subset

---

Red Flags to Investigate

Projection mismatches:

• Calculated projection differs from source by >5%
• Likely cause: Different base year, different CAGR, or rounding

Multiple mismatches:

• Calculated multiple differs from source
• Likely cause: Different metric definition (LTM vs. NTM, Revenue vs. Net Revenue)

Consensus mismatches:

• Your consensus differs from source's consensus
• Likely cause: Source excluded certain data points, different outlier treatment

When in doubt: Note the discrepancy in a footnote and show your calculation methodology.

Formatting Standards Reference

This reference file contains general PowerPoint formatting guidance for pitch deck creation. These are best practices that should be adapted to the specific template being used.

---

Table of Contents

1. Visual Hierarchy and Layout 2. Text Formatting 3. Table Creation 4. Chart and Image Handling 5. Data Visualization 6. Font Consistency 7. Template Adaptation

---

Visual Hierarchy and Layout

Box and Section Layout

Slide layouts vary based on content requirements and template design. Common elements include:

• Header sections with titles and subtitles
• Content boxes with label sidebars
• Tables for structured data
• Charts for visual data representation
• Footnote bars at slide bottom

The specific layout should follow the template provided. Common content types and their typical structures:

• Market definition slides: Label boxes with bullet content + commentary sections
• TAM/sizing slides: Metrics callouts + data tables + key takeaways
• Competitive analysis: Comparison tables or matrices
• Financial summaries: Charts with supporting data tables

Alignment Principles

Vertical alignment of parallel sections:

Boxes that are vertically stacked should have consistent:

• Left margin position
• Bullet indentation
• Text start position
• Box width

Boxes that are horizontally adjacent should have consistent:

• Top position
• Height (where content allows)
• Internal padding

---

Text Formatting

Bullet Point Structure

Avoid unstructured text dumps. Break content into scannable bullet points.

Illustrative Correct Structure:

✓  Consumer mobile and web language learning apps
   (Duolingo, Babbel, Memrise, Busuu)
✓  B2B enterprise language training platforms
   (goFLUENT, Speexx, Learnship)
✓  Online tutoring marketplaces
   (italki, Preply, Cambly)

Illustrative Incorrect Structure (Text Dump):

Consumer mobile/web apps (Duolingo, Babbel, Memrise, Busuu)
B2B enterprise platforms (Speexx, Rosetta Stone Enterprise)
Online tutoring marketplaces (Preply, italki, Cambly)

Bullet Symbol Guidelines

Adapt symbol usage to match the template's existing conventions.

Bullet Consistency

All bullets within a box/section should have identical formatting:

• Same bullet symbol throughout the box (unless intentionally differentiated)
• Same indent level for all primary bullets
• Same bullet size
• Same spacing between bullet and text
• Same font size for all bullet text at same level

Font Size Guidelines

These are typical ranges - adjust based on template specifications:

Text Density Guidelines

• Maximum 6-7 bullets per content box (adjust based on space)
• Maximum 2 lines per bullet point
• Parenthetical examples on same line or indented below
• Avoid orphan words - adjust line breaks to avoid single words on new lines

---

Table Creation

CRITICAL: Use Actual Table Objects

Tables must be actual table objects, NOT text with tab spacing.

Text with tabs will never align properly and looks unprofessional. Always create proper table objects.

Table Structure Guidelines

1. Column alignment:

• Text columns: Left-aligned (both header and content)
• Numeric columns: Center-aligned or right-aligned
• Headers should align with their column content

2. Header row:

• Bold text
• Shaded background (use template's brand color)
• Contrasting text color for readability
• Alignment matches column content alignment

3. Alternating rows (optional):

• Light shading on alternate rows improves readability

4. Summary/Total row:

• Bold text
• Heavier top border (separator line)
• Distinct background shading

5. Table width:

• Fill the designated section width
• Avoid tables floating in white space

For XML implementation patterns, see `xml-reference.md`

---

Chart and Image Handling

Pasting Charts from Excel

When pasting charts from Excel:

1. Paste the chart ONLY - do not include source data tables 2. Resize to fill the designated area - charts should not appear as tiny thumbnails 3. Maintain aspect ratio - do not distort the chart 4. Verify readability - axis labels, legends, data labels must be legible

Pasting Tables from Excel

When pasting tables from Excel:

1. Paste the formatted table ONLY - exclude any source data or calculations 2. Resize to fill the designated area - table should occupy its full section 3. Verify column widths - adjust so text is not truncated 4. Check formatting preservation - colors, borders, fonts may need adjustment

Size Guidelines

Minimum sizing principles:

• Charts: Should occupy a substantial portion of their designated area
• Tables: Fill the designated section width completely
• Images: Sized appropriately for context, never thumbnail-sized

Indicators of undersized visuals (avoid these):

• Chart occupies small fraction of available space
• Text labels are unreadable
• Large empty areas surrounding the visual
• Visual appears as a "thumbnail"

Proper Sizing Workflow

1. Identify the target area dimensions 2. Paste the chart/table 3. Immediately resize to fill the target area 4. Verify all text remains readable 5. Adjust internal elements if needed (legend position, axis labels)

---

Data Visualization

Key Metrics Display

When displaying key metrics (e.g., TAM, CAGR, projections), consider showing relationships between values rather than listing them statically:

• Visual flow indicators: Shapes (arrows, chevrons, connectors) showing progression
• Size hierarchy: Larger font for primary metrics, smaller for labels
• Spatial arrangement: Position elements to show logical flow

Arrow and Flow Indicators

If using arrows or flow indicators:

• Use PowerPoint shape objects, not text characters
• Do not use text-based arrows (→, ⟹) in the final presentation
• Create arrows using PowerPoint's shape tools or via XML shape elements

For XML implementation, see [`xml-reference.md`](xml-reference.md#arrow-shapes)

---

Font Consistency

Cross-Box Font Consistency

All text boxes at the same hierarchy level should use identical font sizes.

Same-level boxes that should match:

Verification Process

1. Identify all text boxes at the same hierarchy level 2. Check font size of each box 3. If any box differs, adjust all to match 4. Default to the larger size if content fits; otherwise use the smaller size consistently

Exception: Sub-bullets or secondary text may use smaller font than primary bullets, but this must be consistent across ALL boxes.

---

Template Adaptation

These standards should be adapted to match the specific template being used:

1. Colors: Use the template's brand colors rather than prescribing specific colors 2. Fonts: Use the template's font family 3. Spacing: Match the template's existing spacing conventions 4. Layout: Follow the template's section structure

The key principles that remain constant regardless of template:

• Text must be readable against its background
• Tables must be actual table objects
• Content should fill available space appropriately
• Formatting should be consistent across parallel elements
• Charts/images should be properly sized

Content Mapping Reference

This file provides guidance for mapping source data to pitch deck template sections. The process is template-agnostic—these principles apply regardless of the specific template design.

Contents

• Template Analysis Process
• Content Mapping Workflow
• Common Slide Types and Data Requirements
• Mapping Verification Checklist
• Handling Data-Template Mismatches
• Template-Specific Adaptation

---

Template Analysis Process

Before populating any template, analyze its structure:

Step 1: Identify All Content Areas

Scan each slide for:

• Title/header placeholders — Where slide titles go
• Subtitle/definition areas — Secondary headers or definitions
• Content boxes — Main content areas (may have label sidebars)
• Table placeholders — Areas designated for tabular data
• Chart/visual areas — Spaces for charts, diagrams, or images
• Metric callout boxes — Highlighted key figures
• Footnote/source bars — Bottom areas for citations and notes
• Logo placeholder — Usually top-right corner

Step 2: Note Template Conventions

Each template has its own style. Observe:

• Color scheme — What colors are used for headers, backgrounds, accents?
• Font choices — What fonts and sizes are already set?
• Box styling — Do content boxes have sidebars, borders, or shading?
• Bullet styles — What bullet symbols does the template use?
• Alignment patterns — How are parallel sections aligned?

Step 3: Identify Instruction vs. Output Areas

Templates often include guidance:

• Instruction boxes — Colored boxes with guidance text (often yellow background, white text)
• Placeholder text — Text in [brackets] indicating what to replace
• Example content — Sample content showing expected format

Key distinction: Instruction boxes tell you what to do; they should be reformatted or removed in final output. Output areas are where your content goes.

---

Content Mapping Workflow

Step 1: Inventory Source Data

Create a list of all available data:

• Market size figures and ranges
• Growth rates (CAGR, YoY)
• Company names and descriptions
• Segment definitions
• Financial metrics
• Source citations and dates
• Footnote content

Step 2: Match Data to Template Sections

For each template section, identify:

Step 3: Identify Gaps

After mapping, note:

• Missing data — Template requires data not in sources
• Extra data — Sources contain data with no template home
• Format mismatches — Data exists but in wrong format

Step 4: Resolve Gaps Before Populating

• Missing data: Flag for user or search for additional sources
• Extra data: Confirm if it should be excluded or if template needs adjustment
• Format mismatches: Transform data to required format

---

Common Slide Types and Data Requirements

These are typical data requirements for common slide types. Your specific template may vary—always follow the template's actual structure.

Market Definition Slides

Typical content areas:

• Segments included in scope (with examples/key players)
• Segments excluded from scope (with examples)
• Market definition text
• Scope rationale/justification

Data mapping considerations:

• Source data should clearly distinguish included vs. excluded segments
• Key players should be mapped to their respective segments
• Definition text should align with how sources define the market

Data typically needed:

• List of market segments to include (with key player examples)
• List of market segments to exclude (with examples)
• Market definition text
• Scope rationale or justification

Formatting principle: Parallel sections (included vs. excluded) should use matching formatting.

Verification questions:

• Does every segment have the appropriate symbol (✓ for included, × for excluded)?
• Are key players correctly assigned to segments?
• Does the definition match the source methodology?

Market Sizing / TAM Slides

Typical content areas:

• Current market size (with year)
• Growth rate (CAGR with period)
• Future projection (with target year)
• Source-by-source breakdown table
• Consensus/summary figures
• Key takeaways or insights

Data typically needed:

• Market size figures with base year
• Growth rates (CAGR with time period)
• Projection figures with target year
• Source citations for each data point

Example column headers: Source | [Base Year] Size | CAGR | [Target Year] Projection

Formatting principle: If showing multiple sources, include a consensus/summary row.

Data mapping considerations:

• Multiple sources may have different estimates—map each to table rows
• Consensus figures require calculation from individual sources
• Projections should be verifiable using CAGR formula

Verification questions:

• Do all source figures match original documents?
• Is the consensus calculated correctly (not just copied from one source)?
• Are projection years consistent across all figures?
• Do CAGR-based projections match when manually verified?

Competitive Landscape Slides

Typical content areas:

• Comparison table with competitors as columns
• Feature/capability rows
• Financial metric rows (revenue, growth, market share)
• Key observations or positioning notes

Data typically needed:

• List of competitors to compare
• Features or capabilities for each
• Financial metrics (revenue, growth, market share) if available
• Time period for financial data

Formatting principle: Subject company should be visually distinguished from competitors (e.g., bold text, different background color, border, or positioned in rightmost column).

Data mapping considerations:

• Ensure all competitors from source data are included
• Feature comparisons should use consistent criteria
• Financial figures should be from comparable periods

Verification questions:

• Are all competitors from the source data represented?
• Is the subject company visually distinguished?
• Are financial figures from the same time period?
• Is the ✓/× usage consistent and accurate?

Financial Summary Slides

Typical content areas:

• Key metric callouts (headline figures)
• Historical financials table (actuals)
• Projected financials table (estimates)
• Growth rates and margins
• Optional trend charts

Data typically needed:

• Historical financials (actuals) for recent years
• Projected financials (estimates) for future years
• Key metrics: Revenue, Growth %, Margins, EBITDA

Example column headers: Metric | FY[Year-2] | FY[Year-1] | FY[Year]A | FY[Year+1]E | FY[Year+2]E

Formatting principle: Clearly distinguish historical (A) from projected (E) data.

Data mapping considerations:

• Clearly distinguish historical (A) from projected (E) data
• Ensure metric definitions match source (Revenue vs. Net Revenue, EBITDA vs. Adjusted EBITDA)
• Growth rates should be calculated consistently

Verification questions:

• Are historical vs. projected periods clearly labeled?
• Do calculated growth rates match source or manual calculation?
• Are metric definitions consistent with source documents?

Transaction Comparables Slides

Typical content areas:

• Transaction table (date, target, acquirer, deal value)
• Valuation multiples (EV/Revenue, EV/EBITDA)
• Summary statistics (mean, median, high, low)
• Implied valuation for subject company

Data typically needed:

• Transaction details: Date, Target, Acquirer, Deal Value
• Valuation multiples: EV/Revenue, EV/EBITDA
• Subject company metrics for implied valuation

Formatting principle: Include summary statistics (Mean, Median, High, Low) for multiples.

Data mapping considerations:

• Multiples should be calculated from transaction data, not just copied
• Summary statistics require calculation across all transactions
• Implied valuation applies multiples to subject company metrics

Verification questions:

• Are all relevant transactions from the source included?
• Are multiples calculated correctly (EV ÷ Metric)?
• Do summary statistics cover all transactions in the table?
• Is implied valuation clearly labeled as illustrative?

---

Mapping Verification Checklist

Before moving to formatting, verify mapping completeness:

Data Completeness

• [ ] Every template placeholder has mapped source data
• [ ] All source citations are recorded for footnotes
• [ ] No placeholder [brackets] remain unmapped

Data Accuracy

• [ ] Figures match original source documents exactly
• [ ] Years and time periods are correctly noted
• [ ] Company names are spelled correctly
• [ ] Calculated values (consensus, projections, multiples) verified

Logical Consistency

• [ ] Included vs. excluded segments are logically coherent
• [ ] Historical data precedes projected data chronologically
• [ ] Comparison data uses consistent time periods
• [ ] Totals and subtotals sum correctly

Source Attribution

• [ ] Every data point can be traced to a source
• [ ] Source names and publication years recorded
• [ ] Footnote numbers assigned for special notes

---

Handling Data-Template Mismatches

Template Requires More Data Than Available

Options: 1. Flag the gap explicitly for user review 2. Mark section as "Data not available" with explanation 3. Search for additional sources if appropriate 4. Recommend template adjustment if data doesn't exist

Do not: Fabricate data or make unsupported estimates.

Source Has More Data Than Template Accommodates

Options: 1. Include most relevant/recent data points 2. Summarize or aggregate where appropriate 3. Add footnotes referencing additional available data 4. Recommend template expansion if data is critical

Data Format Doesn't Match Template Format

Common transformations:

• Individual figures → Range (use min-max from sources)
• Detailed breakdown → Summary category
• Annual figures → CAGR (calculate from endpoints)
• Absolute values → Percentages (calculate share)
• Multiple sources → Consensus (apply methodology)

Template Uses Different Terminology

Resolution process: 1. Identify template term and source term 2. Confirm they refer to the same concept 3. Use template terminology in output 4. Add footnote if clarification needed

---

Template-Specific Adaptation

Remember: This guidance describes common patterns, not requirements. Always:

1. Follow the template — If template uses different section names, use those 2. Match template style — Use template's existing fonts, colors, bullet styles 3. Preserve template structure — Don't rearrange sections unless necessary 4. Respect template spacing — Content should fit designated areas without overflow

The goal is to populate the template as designed, not to redesign it.

PowerPoint XML Reference

This file contains XML patterns for programmatic PowerPoint editing. Use these patterns when working directly with OOXML format.

Note: Color values in examples (e.g., E67E22, D35400) are placeholders. Replace with your template's brand colors.

---

⚠️ When to Use This Reference

Use python-pptx for:

• Creating new tables (handles cell structure and relationships automatically)
• Adding text boxes
• Inserting images
• Most shape creation
• Any operation where python-pptx provides an API

Use direct XML editing only for:

• Modifying properties of existing elements that python-pptx doesn't expose
• Fine-tuning cell formatting after table creation via python-pptx
• Adjusting specific shape properties not available via the python-pptx API

NEVER use direct XML for:

• Creating tables from scratch (relationship management is error-prone and will likely corrupt the file)
• Initial shape creation (shape ID collision risk)
• Anything you can accomplish via python-pptx

The XML patterns in this file are for reference and targeted modifications, not wholesale element construction.

---

XML Editing Risks

Direct XML editing can corrupt PowerPoint files if not done carefully:

• PowerPoint XML has interdependencies (relationship files, content types)
• Invalid XML or missing relationships can corrupt the entire file
• Shape IDs must be unique across each slide

Always work on a backup copy — never edit the original file directly.

---

Contents

• Table Implementation
• Arrow Shapes
• Text Boxes
• Shapes with Fill
• Image Insertion
• Connector Lines
• Unit Conversions

---

Table Implementation

CRITICAL: Verify Tables Are Actual Table Objects

After creating any table, you MUST verify it is an actual table object, not text with separators.

Programmatic verification (python-pptx):

for shape in slide.shapes:
    if shape.has_table:
        print(f"✓ Found table: {len(shape.table.rows)} rows, {len(shape.table.columns)} columns")

Visual verification (in exported image):

• Columns align perfectly regardless of content length
• Cell borders are consistent
• Selecting the table selects all cells as a unit

Failure indicators — you have created TEXT, not a table:

• | characters visible between values
• Columns misalign when content length varies
• Tab characters (\t) used for spacing
• Multiple text boxes arranged to look like a table

Text-based "tables" cannot be edited by the recipient, will misalign when fonts change, and signal amateur work. There is no acceptable use case for pipe/tab-separated tabular data in a pitch deck.

---

Basic Table Structure

<a:tbl>
  <a:tblPr firstRow="1" bandRow="1">
    <a:tableStyleId>{5C22544A-7EE6-4342-B048-85BDC9FD1C3A}</a:tableStyleId>
  </a:tblPr>
  <a:tblGrid>
    <a:gridCol w="2000000"/>  <!-- Source column - width in EMUs -->
    <a:gridCol w="1200000"/>  <!-- 2024 Size column -->
    <a:gridCol w="1200000"/>  <!-- CAGR column -->
    <a:gridCol w="1200000"/>  <!-- 2030 Projection column -->
  </a:tblGrid>
  <!-- Row definitions follow -->
</a:tbl>

Table Row with Cells

<a:tr h="370840">  <!-- Row height in EMUs -->
  <a:tc>
    <a:txBody>
      <a:bodyPr/>
      <a:lstStyle/>
      <a:p>
        <a:pPr algn="l"/>  <!-- Left alignment for text columns -->
        <a:r>
          <a:rPr lang="en-US" sz="1000" b="0"/>
          <a:t>Grand View Research</a:t>
        </a:r>
      </a:p>
    </a:txBody>
    <a:tcPr/>
  </a:tc>
  <a:tc>
    <a:txBody>
      <a:bodyPr/>
      <a:lstStyle/>
      <a:p>
        <a:pPr algn="ctr"/>  <!-- Center alignment for numeric columns -->
        <a:r>
          <a:rPr lang="en-US" sz="1000"/>
          <a:t>22.1</a:t>
        </a:r>
      </a:p>
    </a:txBody>
    <a:tcPr/>
  </a:tc>
  <!-- Additional cells... -->
</a:tr>

Header Row Styling

<a:tr h="370840">
  <a:tc>
    <a:txBody>
      <a:bodyPr/>
      <a:lstStyle/>
      <a:p>
        <a:pPr algn="l"/>
        <a:r>
          <a:rPr lang="en-US" sz="1000" b="1">  <!-- Bold for headers -->
            <a:solidFill>
              <a:srgbClr val="FFFFFF"/>  <!-- White text -->
            </a:solidFill>
          </a:rPr>
          <a:t>Source</a:t>
        </a:r>
      </a:p>
    </a:txBody>
    <a:tcPr>
      <a:solidFill>
        <a:srgbClr val="E67E22"/>  <!-- Orange background -->
      </a:solidFill>
    </a:tcPr>
  </a:tc>
  <!-- Additional header cells... -->
</a:tr>

---

Arrow Shapes

Right Arrow Shape

<p:sp>
  <p:nvSpPr>
    <p:cNvPr id="10" name="Arrow Right"/>
    <p:cNvSpPr/>
    <p:nvPr/>
  </p:nvSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="3000000" y="2500000"/>  <!-- Position in EMUs -->
      <a:ext cx="500000" cy="300000"/>   <!-- Size in EMUs -->
    </a:xfrm>
    <a:prstGeom prst="rightArrow">
      <a:avLst/>
    </a:prstGeom>
    <a:solidFill>
      <a:srgbClr val="E67E22"/>  <!-- Arrow fill color -->
    </a:solidFill>
    <a:ln>
      <a:noFill/>  <!-- No outline -->
    </a:ln>
  </p:spPr>
</p:sp>

Down Arrow Shape

<p:sp>
  <p:nvSpPr>
    <p:cNvPr id="11" name="Arrow Down"/>
    <p:cNvSpPr/>
    <p:nvPr/>
  </p:nvSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="2500000" y="3000000"/>
      <a:ext cx="300000" cy="500000"/>
    </a:xfrm>
    <a:prstGeom prst="downArrow">
      <a:avLst/>
    </a:prstGeom>
    <a:solidFill>
      <a:srgbClr val="E67E22"/>
    </a:solidFill>
  </p:spPr>
</p:sp>

Chevron Shape

<p:sp>
  <p:nvSpPr>
    <p:cNvPr id="12" name="Chevron"/>
    <p:cNvSpPr/>
    <p:nvPr/>
  </p:nvSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="3000000" y="2500000"/>
      <a:ext cx="400000" cy="600000"/>
    </a:xfrm>
    <a:prstGeom prst="chevron">
      <a:avLst/>
    </a:prstGeom>
    <a:solidFill>
      <a:srgbClr val="E67E22"/>
    </a:solidFill>
  </p:spPr>
</p:sp>

---

Text Boxes

Basic Text Box

<p:sp>
  <p:nvSpPr>
    <p:cNvPr id="5" name="TextBox 4"/>
    <p:cNvSpPr txBox="1"/>
    <p:nvPr/>
  </p:nvSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="500000" y="1500000"/>
      <a:ext cx="4000000" cy="500000"/>
    </a:xfrm>
    <a:prstGeom prst="rect">
      <a:avLst/>
    </a:prstGeom>
    <a:noFill/>
  </p:spPr>
  <p:txBody>
    <a:bodyPr wrap="square" rtlCol="0">
      <a:spAutoFit/>
    </a:bodyPr>
    <a:lstStyle/>
    <a:p>
      <a:r>
        <a:rPr lang="en-US" sz="1400" dirty="0"/>
        <a:t>Text content here</a:t>
      </a:r>
    </a:p>
  </p:txBody>
</p:sp>

Text Box with Bullet Points

<p:txBody>
  <a:bodyPr wrap="square">
    <a:spAutoFit/>
  </a:bodyPr>
  <a:lstStyle/>
  <a:p>
    <a:pPr marL="342900" indent="-342900">
      <a:buFont typeface="Wingdings" panose="05000000000000000000" pitchFamily="2" charset="2"/>
      <a:buChar char="&#252;"/>  <!-- Checkmark character -->
    </a:pPr>
    <a:r>
      <a:rPr lang="en-US" sz="1400" dirty="0"/>
      <a:t>First bullet point</a:t>
    </a:r>
  </a:p>
  <a:p>
    <a:pPr marL="342900" indent="-342900">
      <a:buFont typeface="Wingdings" panose="05000000000000000000" pitchFamily="2" charset="2"/>
      <a:buChar char="&#252;"/>
    </a:pPr>
    <a:r>
      <a:rPr lang="en-US" sz="1400" dirty="0"/>
      <a:t>Second bullet point</a:t>
    </a:r>
  </a:p>
</p:txBody>

Text with White Color (for dark backgrounds)

<a:r>
  <a:rPr lang="en-US" sz="1000" b="1" i="1" dirty="0">
    <a:solidFill>
      <a:srgbClr val="FFFFFF"/>  <!-- White text -->
    </a:solidFill>
  </a:rPr>
  <a:t>White text on colored background</a:t>
</a:r>

---

Shapes with Fill

Rectangle with Solid Fill

<p:sp>
  <p:nvSpPr>
    <p:cNvPr id="20" name="Rectangle 19"/>
    <p:cNvSpPr/>
    <p:nvPr/>
  </p:nvSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="500000" y="2500000"/>
      <a:ext cx="1000000" cy="2000000"/>
    </a:xfrm>
    <a:prstGeom prst="rect">
      <a:avLst/>
    </a:prstGeom>
    <a:solidFill>
      <a:srgbClr val="E67E22"/>  <!-- Orange fill -->
    </a:solidFill>
    <a:ln w="12700">  <!-- Border width -->
      <a:solidFill>
        <a:srgbClr val="D35400"/>  <!-- Darker border -->
      </a:solidFill>
    </a:ln>
  </p:spPr>
  <p:txBody>
    <a:bodyPr rtlCol="0" anchor="ctr"/>  <!-- Vertically centered text -->
    <a:lstStyle/>
    <a:p>
      <a:pPr algn="ctr"/>  <!-- Horizontally centered -->
      <a:r>
        <a:rPr lang="en-US" sz="1600" b="1">
          <a:solidFill>
            <a:srgbClr val="FFFFFF"/>
          </a:solidFill>
        </a:rPr>
        <a:t>Label Text</a:t>
      </a:r>
    </a:p>
  </p:txBody>
</p:sp>

---

Image Insertion

Adding Image to Slide

<p:pic>
  <p:nvPicPr>
    <p:cNvPr id="99" name="Company Logo"/>
    <p:cNvPicPr>
      <a:picLocks noChangeAspect="1"/>
    </p:cNvPicPr>
    <p:nvPr/>
  </p:nvPicPr>
  <p:blipFill>
    <a:blip r:embed="rIdLogo"/>  <!-- Reference to relationship ID -->
    <a:stretch>
      <a:fillRect/>
    </a:stretch>
  </p:blipFill>
  <p:spPr>
    <a:xfrm>
      <a:off x="10800000" y="200000"/>  <!-- Top-right position -->
      <a:ext cx="800000" cy="600000"/>   <!-- Logo dimensions -->
    </a:xfrm>
    <a:prstGeom prst="rect">
      <a:avLst/>
    </a:prstGeom>
  </p:spPr>
</p:pic>

Adding Image Relationship

In ppt/slides/_rels/slideN.xml.rels:

<Relationship Id="rIdLogo" 
  Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" 
  Target="../media/logo.png"/>

---

Connector Lines

Straight Connector

<p:cxnSp>
  <p:nvCxnSpPr>
    <p:cNvPr id="15" name="Straight Connector 14"/>
    <p:cNvCxnSpPr>
      <a:cxnSpLocks/>
    </p:cNvCxnSpPr>
    <p:nvPr/>
  </p:nvCxnSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="500000" y="2500000"/>
      <a:ext cx="5000000" cy="0"/>  <!-- Horizontal line -->
    </a:xfrm>
    <a:prstGeom prst="line">
      <a:avLst/>
    </a:prstGeom>
    <a:ln w="12700">
      <a:solidFill>
        <a:srgbClr val="E67E22"/>
      </a:solidFill>
    </a:ln>
  </p:spPr>
</p:cxnSp>

Dashed Line

<p:spPr>
  <a:xfrm>
    <a:off x="500000" y="4500000"/>
    <a:ext cx="5000000" cy="0"/>
  </a:xfrm>
  <a:prstGeom prst="line">
    <a:avLst/>
  </a:prstGeom>
  <a:ln w="12700">
    <a:solidFill>
      <a:srgbClr val="E67E22"/>
    </a:solidFill>
    <a:prstDash val="dash"/>  <!-- Dashed style -->
  </a:ln>
</p:spPr>

---

Unit Conversions

Common Slide Dimensions (16:9)

• Width: 12192000 EMUs (13.333 inches)
• Height: 6858000 EMUs (7.5 inches)

Typical Element Positions