Introduction to Cost Capitalization

Cost capitalization helps you understand which engineering projects qualify as innovation (capitalized) versus infrastructure and maintenance (non-capitalized).
This distinction matters because companies can receive R&D tax credits for capitalized, innovation-related work.

Traditionally, Finance teams ask Engineering Managers (EMs) to classify work manually—usually with spreadsheets—into capitalized vs. not capitalized categories, which can be time consuming and painful.

Those classifications are later translated into FTE (Full-Time Equivalent) costs to understand how much time and money go toward innovation versus “keep-the-lights-on” (KTLO) work.

With Span, this process becomes easier, more consistent, and more transparent. Span streamlines this process by connecting real engineering activity — commits, PRs, tickets, calendar data — to cost and classification logic, producing structured, auditable capitalization data.

Key Benefits

How Cost Is Calculated

Span estimates costs using job level/title salary benchmarks configured by an admin. The simplified formula is:

Capitalized Cost =
  (Annual Salary / 250 FTE days)
  × Assigned FTE Days
  × Capitalization %
  × OOO Adjustment (if applicable)

FTE days are inferred from actual work signals: commits, PRs, code reviews, and tickets.

Work Classification Sources

Cost Cap uses work classification to determine how engineering effort is grouped and measured. When configuring Cost Cap, you can choose from five classification methods depending on how your team structures and tracks work:

1. Epics from Project Management System

2. Initiatives from Project Management System

3. All issues from Project Management System

4. AI Inferred Workstreams (Refined)

5. AI Inferred Workstreams (Raw Top Level)

Epics from Project Management System (Jira)

This option uses the Epic hierarchy from your connected issue tracker (e.g., Jira, Linear) as the basis for classification. Engineering effort is grouped and attributed according to your existing Epics and the issues linked to them.

Best for: Teams that maintain well-organized Epics in their project management tool and want Cost Cap to reflect that structure directly.

Prerequisite: Epics must be consistently defined and linked to issues in your project management system.

Initiatives from Project Management System (Jira)

Similar to Epics, this option uses Initiatives — a higher-level grouping that typically sits above Epics and represents broader business objectives or strategic themes. Effort is attributed based on how issues roll up to Initiatives in your project management system.

Best for: Teams whose roadmap planning operates at an Initiative level, and where Initiatives accurately reflect the major investment categories you want to track.

Prerequisite: Your project management system must support and actively use an Initiatives hierarchy layer.

All Issues from Project Management System (Jira)

This option classifies work at the individual issue level — using every issue (stories, tasks, bugs, etc.) from your project management system, regardless of whether they are organized under Epics or Initiatives.

Best for: Teams that want granular visibility into work distribution without relying on a clean Epic or Initiative hierarchy. Useful when top-level groupings are inconsistent or incomplete.

Note: Because this operates at the issue level, the number of work categories may be larger and require more configuration to group meaningfully.

AI Inferred Workstreams (Refined)

This option uses Span's machine learning models to automatically discover and group related work into logical workstreams — based on signals from your code changes, pull requests, commit messages, issue titles, and descriptions. The "Refined" version allows your team to customize workstream names, descriptions, and hierarchy on top of the AI-generated output.

Key characteristics:

• Supports a hierarchical structure (top-level workstreams and sub-workstreams)

• Workstream names and descriptions can be tailored to your organization's context

• Includes an "Unlinked Work" category for engineering activity that could not be confidently classified

Best for: Teams that want AI-driven categorization that surfaces natural patterns in engineering work — especially useful if your project management data is incomplete or inconsistently structured. The "Refined" option is recommended when you want the accuracy of AI classification combined with the clarity of human-defined labels.

AI Inferred Workstreams (Raw Top Level)

This option surfaces the original, unmodified AI-generated workstreams at the top level — exactly as Span's models inferred them, without any customizations applied by your team.

Key characteristics:

• Top-level workstreams only — no sub-workstream hierarchy

• No custom names or descriptions; workstream labels are AI-generated

• Reflects Span's raw classification output before any team refinement

Best for: Teams exploring Cost Cap for the first time who want to see how Span naturally groups their engineering work before making any configuration decisions. Also useful for benchmarking or comparing against refined workstreams.

Choosing the Right Option

If your team has a well-maintained project management hierarchy, Epics or Initiatives will give you the most predictable structure. If your PM data is sparse or inconsistent, AI Inferred Workstreams (Refined) is typically the most powerful option, as it surfaces natural patterns in your engineering activity and lets you refine the output to match your organizational context.

2. Capitalization % (Partial Capitalization)

Each project/epic can have a custom capitalization percentage (default: 100%). Finance teams can configure these by job level, project maturity, or internal policy — e.g., "only 80% of QA work is capitalized" or different rates for ICs vs. managers.

3. Start/End Date Windows

Capitalization windows can be defined per Epic via Jira field mappings — for example, only capitalizing work after a project reaches GA.

4. Excluded Work Handling

When work falls outside the capitalization window (by % or date), three strategies are available (configurable in your cost Cap Settings)

Redistribution windows can be set at day, week, month, or quarter granularity. Week-level redistribution achieves ~90% success rate.

5. OOO Time Handling

OOO time from HRIS or calendar integrations is factored in automatically. If a person has both OOO time and productive work on the same day, Span rescales upward — the full day's salary cost is attributed to the actual work rather than being artificially reduced.

Integrations

Operational Workflow

1. Setup — Admin configures salary benchmarks by job level, maps Jira fields (status, start/end dates), and selects exclusion method and redistribution window

2. Classification — Work is automatically classified based on Epics, Workstreams, or Initiatives; exclusion rules applied

3. Review — Engineering Managers or Finance can review and override classifications or adjust capitalization %

4. Reporting — Download Finance-ready reports showing FTE days, costs, and capitalization status by

🧭 What You Can Do in Span

Span lets you view and classify work directly from your connected data sources:

• View projects by Project, Team, or Person

• Mark work as Capitalized or Non-Capitalized

• Download reports for Finance to calculate cost and ROI

Span uses the Cost Estimates defined in your Settings, based on:

• Job Level or Job Title

• Average annual salary (entered by an admin)

Note: Span does not expose individual salaries — cost data is shown as aggregated averages to provide directional ROI insights, and you can hide cost data from certain personas in your roles and permissions settings.

💡 Why This Matters

Before Span, teams rely on “back-of-the-napkin” calculations because consistent, structured data is hard to maintain.

Span automates this process by tying together real work artifacts (commits, PRs, tickets, etc.) with cost and classification logic.

A Step by Step Guide to Cost Capitalization Settings:

You can populate your Cost Capitalization table in two ways:

1. Through Epics from your project management system (e.g., Jira)

2. Through Initiatives from your project management system (e.g. Jira)

3. Through AI-Inferred Workstreams, which Span automatically groups based on observed activity

Handling Excluded Work

In some cases, not all work on a project should be capitalized. Span provides two adjustment methods in the Cost Capitalization Work Table:

1. Capitalization %

By default, this is set to 100%, but you can override it to reflect partial capitalization.
Finance teams often set these rules based on:

• Job Level

• Project maturity or GA status

• Internal capitalization policies

2. Start and End Date Exclusion

You can exclude work from capitalization based on Epic start/end dates — for example, only capitalizing work after a project reaches GA.

Note: Date-based exclusion is configured at the Epic level.

🧮 Options for Handling Excluded Work

When work is excluded in the Work Table (either via % or date filters), Span gives you three options:

1. Uncapitalized (Recommended)
   Excluded FTE days are reclassified as non-capitalized work.

2. Redistribute where possible, otherwise show as non-capitalized
   Excluded FTE days are redistributed to overlapping projects when possible; otherwise, they appear as non-capitalized.

3. Redistribute where possible, otherwise hide
   Same redistribution logic, but any remaining excluded time is hidden entirely.

   We don’t recommend this option, as it can obscure your total work picture.

🔄 Redistributing Excluded Work

If you choose to redistribute excluded time, Span lets you define how far back or forward to look for overlapping work:

• By Day

• By Week

• By Month

• By Quarter

This setting determines the timeframe Span uses to identify overlapping projects for redistribution.

🧱 Epic Configuration

If your Jira projects already use a “Capitalization Status” tag, you can map that field in Span. Span will then automatically recognize which Epics are capitalized versus not.

Capitalization Start and End Dates

You can also define which fields in Jira determine the start and end of capitalization for each Epic.

🤖 Classifying Work with AI-Inferred Workstreams

If you’re using Workstreams instead of Epics for Cost Capitalization, all the same exclusion and redistribution options apply.

You can calculate FTE days in two ways:

1. Inferred from observed events
   (commits, PRs, reviews, tickets, etc.)
   → Requires mapping AI-inferred Workstreams to your actual projects.

2. Supervisor-Approved FTE Days
   Engineering Managers review and validate project allocations, overriding percentages or reassigning days if needed.

Note: If Workstreams haven’t been mapped to projects, Span defaults to classifying work by Jira Epics.

Q&A

Q: Can I map work by Initiative instead of Epic?
​A: Yes. In Investment → Cost Cap, click the Display button and choose Show Jira Initiatives.
This adds a column for Initiatives in the Work Table, which you can sort or filter as needed.

✅ Summary
Cost Capitalization in Span brings together your engineering activity, financial estimates, and project metadata to create a consistent, auditable view of R&D investment.

By automating data ingestion, classification, and exclusion logic, Span replaces spreadsheets and guesswork with structured insight.