Cost Capitalization Report (CapEx) – LinearB Support

LinearB’s Cost Capitalization (Cost Cap/ Capex) report is built on top of the same data and logic used in the Resources → Allocation dashboard and delivered via Google Sheets and/or Excel. This article explains:

How LinearB allocates work across issues, epics, and initiatives
How that allocation is converted into FTE and cost units
How to configure Resource Allocation so your Cost Cap report is accurate
How to interpret and troubleshoot common questions

TL;DR:

Resource Allocation estimates where engineering time went, per person / issue / day, using assignment + activity signals (not time tracking).
Each active, assigned issue on a given day gets an equal slice of that day.
- 30 day period: 30 calendar days = 1 FTE. Weekends and holidays are included when issues are active.
- Quarterly: 30 calendar days = 1/3 FTE. Weekends and holidays are included when issues are active.
Cost Cap uses the same allocation data but applies your capitalization rules (0/1 mapping, parent inheritance, custom fields) to separate capitalizable from non-cap work.
For accurate Cost Cap results, make sure your capitalization fields are added under Resources → Allocation → Configure → + Custom field and properly mapped in the report’s Setup and Classification tabs.
If numbers look off, first check: active/assigned logic, missing parents or fields, and your 0/1 classification rules before assuming a data problem.

Key idea: Cost Cap is a finance-focused view on top of Resource Allocation data. Resource Allocation shows all work. Cost Cap shows the capitalizable slice of that work, based on your rules.

How Resource Allocation Works

Resource Allocation answers two questions:

How much effort did each engineer invest?
Where was that effort invested? (epics, projects, initiatives, investment categories, etc.)

Under the hood, Resource Allocation uses a consistent model:

Per person
Per issue (story, bug, task, subtask, etc.)
- Please note: Labels will not be pulled into the Cost Cap Report from Resource Allocation
Per day

What makes an issue “active”?

For each developer and each day, LinearB determines which issues were “active” and assigned to that person. Only those issues participate in allocation for that day.

An issue is considered active on a given day if:

It is assigned to the developer, and
Is in an In Progress–type state and
has recent activity (ticket updates in the last few days)

There is direct Git activity that references the ticket key (commits, branches, pull requests) on the given day, even if the ticket is not in an In Progress state.

Important: We do not use time tracking or manual “hours logged” for Resource Allocation. Allocation is based on assignment + activity signals from your PM tool and Git.

Daily allocation: per person, per issue, per day

Once LinearB knows which issues are active for a developer on a given day, it splits that day’s effort equally across those issues.

If a developer has 2 active issues on a day, each issue receives 1 / 2 = 0.5 of that day.
If a developer has 5 active issues on a day, each issue receives 1 / 5 = 0.2 of that day.

This same logic is applied for each day in the reporting period and for every developer included in the report.

Example: daily allocation over a 7-day window

A developer has 5 active issues every day for a 7-day period.

Per day: each issue receives 1/5 = 0.2 allocated days/day
Over 7 days: each issue receives 0.2 × 7 = 1.4 allocated days (for that developer)

Converting allocated days to FTE (depends on the baseline)

To express that allocation as FTE, divide allocated days by your chosen baseline (commonly the length of the period you’re analyzing):

If your baseline is the same 7-day period (1 FTE = 7 days): FTE = 1.4 ÷ 7 = 0.2 FTE for that developer on that issue in that 7-day period.
If you’re viewing a 30-day period (1 FTE = 30 days) and the issue was only active for 7 of those days: The issue still has 1.4 allocated days, but now: FTE = 1.4 ÷ 30 ≈ 0.05 FTE for that developer on that issue within the 30-day reporting period.

Subtasks & parent rollup

In ticket management systems, teams often split work into subtasks under a parent story or requirement. Resource Allocation handles this by rolling subtask effort into the parent.

Subtask activity (assignment + activity signals) contributes to the parent story’s allocation.
The parent story receives the rolled-up allocation even when the actual work happens on subtasks.
When you aggregate at higher levels (epic, initiative, project), those parent stories roll up further.

Subtasks are never “lost”: their effort is included via the parent. If you do not see subtask effort where expected, check that: (1) subtasks are correctly linked to a parent; and (2) the parent and/or subtask has the right classification fields.

Calendar days, weekends & FTEs

Resource Allocation works in calendar days, not workdays. Weekends and holidays are included if:

The issue is still considered active by the rules above, and
The developer remains assigned to that issue over those days.

Convert allocated days to FTE (per person, within the selected period)

In a reporting period of X calendar days, a single engineer can contribute at most X allocated days total across all issues (since each day’s effort sums to 1 when split across active issues). Therefore, an individual engineer’s FTE for the period is capped at 1.0.

Formula

FTE (per period) = (total allocated days in the period) ÷ X, where X = number of calendar days in the selected period.

Example (30-day period)

If an engineer has 15 allocated days in the 30-day period: 15 ÷ 30 = 0.5 FTE
If an engineer has 30 allocated days in the 30-day period: 30 ÷ 30 = 1.0 FTE (max)

If Alice has 10 allocated days in the 30-day period, and Bob has 7 allocated days in the 30-day period, their total FTE would be 10÷ 30 + 7÷ 30 = 17÷ 30 = 0.567 FTEs

Work Unit Breakdown metrics

On the Resource Allocation dashboard, the Work Unit Breakdown section helps you understand how work is distributed across issues, epics, projects, and types.

Epics/Issues – The number of active work items in the selected period.
- When you filter by initiatives or projects, this shows the number of epics.
- When you filter by epics, this shows the number of issues under those epics.
% of Total Work – The percentage of total FTE allocated in the selected timeframe that falls into the current filter (initiative, project, investment category, etc.).
Effort (FTE) – The total FTE sum for all active issues in the selected period and filter.
Estimated Cost by FTE – Applies the configured average employee cost to FTE to estimate the cost of the work invested.
Issues With No Epics – When filtering by projects, this metric identifies issues that are not linked to any epics. This is a useful indicator of unstructured or “orphan” work.
FTE Allocation by Issue Type – A breakdown of FTE by issue type (e.g., Story, Bug, Task, or custom types like “QA Defect”), showing how effort is distributed.

Tip: Use the date range picker at the top of the Resource Allocation page to analyze how investment patterns change across weeks, months, or quarters.

Configuring Resource Allocation & Cost Cap

Cost Cap uses the same underlying allocation data as Resource Allocation, plus your capitalization rules. There are two configuration surfaces:

The Resource Allocation dashboard in the LinearB UI
The Cost Cap report sheet (Google Sheets or Excel)

Adding custom fields in the UI

Many teams manage categorization information directly on Work Items Epics or Features. To include additional PM-tool custom fields (such as Investment Strategy, Project Type, or a capitalization flag) in Resource Allocation and Cost Cap:

Go to Resources → Allocation in the LinearB app.
Click Configure.
Use + Custom field to add the PM-tool fields you want to surface in the report.

Once a new report is generated, these fields become available in the Cost Cap report’s Setup sheet and Classification tabs for further mapping and logic.

Note: In some setups, not all custom fields are pulled by LinearB's PM tool’s ingestion pipeline. If you do not see a field, contact your LinearB team to have it added.

Using the Setup sheet in the Cost Cap report

Each Cost Cap report is delivered as both a Google Sheet and an Excel file. The Setup tab controls how Resource Allocation data is interpreted for capitalization.

Note: to use the Excel report, you must download it and open it with Microsoft Excel. Do not open it in Google Drive.

Key elements:

Capitalization field selection
Choose the custom field from your PM tool, if any, that encodes capitalizability (for example, a field like Cost capitalization or Investment Strategy).
Classification by Parent vs Custom Field
Decide whether capitalization decisions happen:
- At the parent level the parent (e.g., an epic is marked as capitalizable or not, and its children all fall under that bucket), or
- Rely directly on the custom field value on each work item. In this case if the work item does not provide a value, but its parent (e.g. Epic) does, it will inherit the parent’s value. This lets you mark Epics but override for specific children.
Capitalization percentage (buffer)
Configure the percentage of capitalizable work that should actually be treated as capitalizable. For example:
- 70% means 70% of capitalizable work is counted as capex, 30% remains non-cap.
- 100% means all capitalizable work is treated as capex.

Classification & capitalization logic

The Cost Cap report includes tabs such as:

Classification by custom field
Classification by parent
Capitalization summary
Non-cap summary

Classification values (0 / 1)

In the classification tabs, LinearB uses numeric values to encode capitalization:

1 = capitalizable
0 = non-capitalizable

In the Classification by custom field tab you can:

See all distinct values from your capitalization field (e.g., “Feature enhancement”, “Bug fix”, “Non-cap”).
Set each value’s classification to 1 or 0.

Recommended setup: Map your field so that all “non-cap” or missing values are 0 and only true feature / new value work is 1.

Classification by Parent

Many teams decide on capitalization, or maintain capitalization fields, only on epics or higher-level items. In that case, you can ask the sheet to use the parent.

When classifying by the parent, the parent decides and all the children are included.

Classification by Custom Field

Many teams maintain capitalization fields on specific issues as well, and want to be able to override capitalization decisions in child issues (for example, the Epic is capitalized but a child Bug work item should be classified as non-capitalized). In that case, you can ask the sheet to use classification by customer field.

Children that lack a capitalization value will inherit from their parent epic or feature.
If you need exceptions, you can override specific children directly in the sheet.

This pattern is especially useful when:

Epics are flagged as capitalizable vs non-capitalizable (e.g., EA vs BAU initiatives).
Children tickets should follow the epic’s classification by default.

Resource Allocation vs Cost Cap

Resource Allocation and Cost Cap are built from the same underlying allocation data but serve different audiences.

Aspect	Resource Allocation	Cost Cap
Primary audience	Engineering managers, DevEx / Platform, product leaders	Finance, accounting, auditors
Scope	All work (features, bugs, maintenance, infra, etc.)	Only work classified as capitalizable
Unit	Days and FTE per person / issue / parent	Same days/FTE model, filtered by cap rules
Cost	Estimated cost by FTE on dashboard	Finance-grade report for capex vs non-cap reporting, tax credits etc.

Common gotchas & edge cases

Closed / backlog issues still showing up: if there is direct Git activity (commits, branches, PRs) that reference a ticket, it can be treated as active for allocation even if the workflow state is not In Progress.
“Duplicate-looking” rows in the sheet: the data sheet is per person / issue / day. Seeing the same issue and person across many dates is expected, not a duplication bug.
Totals don’t match other tools exactly: Cost/FTE numbers rarely match 1:1 with other vendors because each uses different allocation algorithms. A good first check is whether the same top epics / initiatives show up with roughly similar relative weight.
Missing buckets when grouping by a field: issues with no parent and no value for that field (e.g., Project type) will drop out when you split by that field. This is often a data hygiene issue, not a calculation problem.
More contributors than FTE: expected. FTE is relative effort (allocated_days ÷ days_in_period), so vacations, part-time work, and context-switching naturally produce fewer FTEs than active contributors. Remember the max FTE for any person across any period is 1.0.

Refresh behavior

The Resource Allocation dashboard updates on a daily schedule (6:30 AM UTC).
Configuration changes (e.g., adding a custom field, adjusting capitalization mapping) trigger re-computation for the next refresh.
Each Cost Cap report is generated for a specific period (month, quarter, or year) and can be re-run if configuration changes, project data is clean up, or additional projects are added.

Resource Allocation & Cost Cap – FAQ

Is the cost cap report SOC 1 Type II certified?

Yes, we are proud to day this is a finacial-grade report for capex that is SOC 1 Type II certified.

Cost Cap uses the same allocation data but applies your capitalization rules to separate capitalizable vs non-capitalizable work. It is designed for finance and accounting use cases, including audit support.

How does LinearB calculate work allocation?

Allocation is calculated per person, per issue, per day. For each developer-day:

Identify all active, assigned issues for that developer on that date.
Split the day equally across those issues (e.g., 3 issues → each gets 1/3 of a day).
Repeat for every day in the reporting period.

The unit is days (absolute) and FTE (relative to the period in consideration).

Do weekends and holidays count in allocation?

Yes. Allocation reflects where effort is attributed, not exact working hours. If an issue remains active and assigned through a weekend or holiday, those calendar days are included in the allocation.

When is an issue considered active?

An issue is active on a given day when:

It is assigned to the developer, and
It is in an In Progress–type state with recent activity (ticket updates inside a trailing window), or
There is direct Git activity referencing the ticket (commits, branches, PRs) on that day.

Why are there more contributors than FTEs?

FTE is a measure of total effort, not headcount. It is:

Sum of allocated days across all contributors ÷ number of days in the period.

It is common to see more contributors than FTE because:

People take vacations, holidays, and leaves.
Some engineers work part-time.
Some work happens outside of the project management system and is not reflected in work items.
Developers split time across multiple initiatives, so each initiative only receives a fraction of their day.

How often does the report update?

The in-app Resource Allocation dashboard refreshes daily at 6:30 AM UTC.
Cost Cap sheets are generated on a schedule agreed with your LinearB team (e.g., monthly, quarterly).

How are subtasks treated in reports?

Subtasks roll into their parent issues:

Assignment and activity on a subtask contributes to the parent story’s allocation.
The parent rolls up further into epics, initiatives, or higher-level planning items.

Can we add custom fields to reports?

Yes. There are two steps:

In the LinearB app, add the custom field in Resources → Allocation → Configure → + Custom field.
In the Cost Cap sheet, use the Setup and Classification by custom field tabs to map those values to capitalizable/non-cap logic or to groupings (e.g., investment strategy).

What’s the difference between Cost Cap and Resource Allocation?

Resource Allocation shows all work and how it is distributed across projects, epics, issue types, and teams. It is primarily for engineering, DevEx, and product stakeholders.