The Hitchhiker's Guide to Capitalizing Software Development Costs
Capitalize software development costs with clear rules, examples and practical guidance for finance and engineering teams.
Engineering is the largest cost center in most technology companies. It also produces some of the most defensible long-term value a business can create.
Yet the way most organizations account for that investment, if they account for it at all, ranges from "rough spreadsheet estimate" to "we'll figure it out at year-end."
That creates real financial exposure: missed tax deductions, incorrect EBITDA calculations, audit risk, and board conversations built on guesswork.
This guide walks through what software capitalization actually means, how the major accounting frameworks treat it, what is genuinely eligible, how agile teams navigate the rules, and, critically, how AI coding tools have complicated both the documentation burden and the ROI question for engineering leaders.
Life, the universe and accounting standards
Software capitalization refers to the practice of treating certain software development costs as capital expenditures (CapEx) rather than operating expenses (OpEx).
The logic is straightforward: when work produces a durable asset with future economic value, the costs associated with creating that asset belong on the balance sheet rather than the income statement. The practical challenge is that the line between "building something new" and "keeping the lights on" is rarely obvious, and regulators know it.
Different jurisdictions apply meaningfully different rules, which creates complexity for any engineering organization operating across markets.
US GAAP standards for software cost capitalization
Under US GAAP, the treatment of software costs depends heavily on what the software is for and who will use it. ASC 350-40 governs internal-use software, while ASC 985-20 applies to software developed for sale or license.
For internal-use software under ASC 350-40, development costs are divided into three phases: preliminary project, application development, and post-implementation. Only the middle phase, application development, generates capitalizable costs. This includes coding, testing, and direct integration work. Preliminary work such as vendor evaluation, requirements definition, and post-launch maintenance is expensed as incurred.
For software products sold to external customers (ASC 985-20), capitalization begins only after "technological feasibility" is established, a bar that is sometimes difficult to define cleanly in modern iterative development environments.
Section 174 and 174A of the Internal Revenue Code govern the tax treatment of research and experimentation (R&E) expenditures separately. Under changes effective from 2022, R&E costs must now be amortized over five years (domestic) or fifteen years (foreign) rather than immediately expensed. This single change substantially raised the stakes for engineering cost classification because it directly affects taxable income in years one through five of any qualifying project.
IFRS standards for software cost capitalization
Under IAS 38 (Intangible Assets), development costs can be capitalized once a project has passed the research phase and the entity can demonstrate six specific criteria: technical feasibility, intention to complete, ability to use or sell, likely future economic benefits, adequate resources, and ability to measure expenditure reliably. Research-phase costs must always be expensed.
In practice, IFRS tends to be more permissive than US GAAP in the sense that it requires judgment about probable future benefit rather than mandating a specific phase-based approach. That flexibility also means more documentation is needed to defend capitalization decisions under audit.
IFRS 15 and IFRS 16 intersect with software costs where development is tied to customer contracts or cloud-hosted arrangements, adding further complexity for SaaS businesses.
Canadian standards for software cost capitalization
Canada generally follows IFRS for publicly accountable enterprises, meaning IAS 38 applies. Private enterprises using ASPE (Accounting Standards for Private Enterprises) may follow a similar development-phase approach under Section 3064. The practical effect is that Canadian engineering organizations face much the same documentation challenges as their IFRS counterparts, with CRA scrutiny of SR&ED (Scientific Research and Experimental Development) claims adding a parallel track that engineering teams often manage separately.
EU standards for software cost capitalization
European Union entities follow IFRS as endorsed by the EU for consolidated financial statements of public companies. Local statutory accounts may follow national GAAP, which varies by member state, but the broad framework under IAS 38 applies at the group level for any multinational.
The EU's ongoing digitization initiatives and evolving tax harmonization discussions are worth monitoring, as transfer pricing of intangible assets (including internally developed software) has attracted increasing regulatory attention.
United Kingdom standards for software cost capitalization
Post-Brexit, the UK continues to apply UK-adopted IFRS for listed companies and FRS 102 or FRS 105 for smaller entities. FRS 102 Section 18 (Intangible Assets Other Than Goodwill) mirrors IAS 38 in most material respects, requiring the same six-criteria test for capitalization. HMRC's R&D relief schemes (RDEC and the reformed merged scheme) operate on a separate track but draw from similar documentation of qualifying activities.
Australian standards for software cost capitalization
Australia applies AASB 138 (equivalent to IAS 38) under the Australian Accounting Standards Board framework. The Taxation Office administers its own R&D incentive program separately, with specific eligibility criteria and registration requirements. As with Canada, engineering organizations often find themselves navigating two parallel documentation tracks, one for accounting, one for tax.
Mostly harmless: a guide to what's worth capitalizing
The short version: work that creates new functionality or substantially improves existing functionality is typically capitalizable. Work that keeps existing functionality running is not.
The longer version requires judgment at the activity level. The following activities are generally capitalizable under most frameworks once a project has passed the preliminary design phase: coding new features and core application modules, writing automated tests tied to new development, integration work connecting new systems to existing infrastructure, direct management time spent supervising qualifying development activities, and security or performance work that meaningfully enhances capability rather than merely maintaining it.
The following are generally expensed: bug fixes and routine maintenance, user training, data conversion from legacy systems, post-launch support, and overhead not directly tied to development activities.
The challenge is that in practice, most engineers do some combination of both categories across any given sprint. A story that starts as a feature request may require fixing an underlying defect before new code can be written. An AI coding assistant may produce output that includes both new logic and corrected existing logic.
Documentation and review work spans both categories. None of this is unusual, it simply means that activity-level classification requires either time tracking, artifact-level tagging, or an automated system capable of inferring work type from the nature of the contribution itself.
My team is agile, how does this work for us?
The honest answer is that agile development creates genuine friction with traditional capitalization frameworks, and most accounting guidance was written before continuous delivery was the default mode of software development.
The core problem is phase separation. ASC 350-40 assumes a project proceeds from preliminary work to active development to post-implementation in a recognizable sequence. Agile teams run all three activities simultaneously: defining requirements, building features, and maintaining production systems happen in the same sprint, sometimes on the same day by the same engineer.
Three approaches are commonly used in practice. The first is the effort-estimation method, where teams assign a fixed percentage of engineering time to capitalizable activities based on the nature of the sprint or project portfolio. This is administratively simple but difficult to defend under audit because the percentages are assumptions rather than observations. The second is timesheet-based tracking, where engineers log time against capitalizable and non-capitalizable categories. This produces defensible documentation but creates workflow overhead that most engineering teams resist.
The third approach, increasingly viable with AI-powered tooling, is artifact-based attribution, where the nature and purpose of each code change, pull request, or work item is analyzed directly rather than inferred from time estimates. A system that understands what a given commit does, what ticket it resolves, and whether that ticket represents new development versus maintenance can classify work continuously and automatically, producing documentation that is both accurate and auditable.
That third approach is where engineering intelligence platforms have created real value for finance and tax teams, and where the documentation burden that once required weeks of manual reconstruction becomes a continuous, automated byproduct of the work itself.
The AI tools ROI problem
"Is AI actually making us more productive or just changing how work is done?"
This is the question boards and investors are asking in 2026, and most engineering organizations cannot answer it. Companies are spending significantly on tools like GitHub Copilot, Cursor, Claude Code, and Gemini Code Assist without a reliable way to connect that investment to delivery outcomes, quality impact, or capitalizable output.
The capitalization angle here is not trivial. AI-assisted code changes the economics of software development in ways that affect how organizations should think about cost attribution. If an engineer produces a 600-line feature in three hours with AI assistance where the same task would previously have taken two days, the labor cost allocated to that work changes. If AI tools are raising the floor on output quality, defect rates should be declining, which affects how much rework is expensed rather than capitalized. If agentic workflows are generating code that engineers then review and modify, the question of who (or what) authored a qualifying R&E contribution becomes relevant to documentation.
These are not hypothetical edge cases. Pensero's 2026 benchmark report measured engineering delivery across thousands of active engineers from November 2025 to April 2026. Average delivery rose 34.2% in that period. The top 5% of teams grew 51.4%, at roughly 1.5 times the rate of the average. The performance gap between elite and average teams widened from 4.9× to 5.9×, and the acceleration tracked directly to the period when AI-assisted and agentic development workflows shifted from experiment to default.
Those numbers matter for capitalization in a specific way: if your team's delivery baseline has shifted materially, your cost-per-unit-of-capitalizable-output has also shifted. Organizations that assume their capitalization percentages from 2023 or 2024 still apply in 2026 may be misallocating engineering costs in either direction.
Pensero shows the real impact on work patterns and helps teams measure the ROI of these investments rather than relying on theoretical performance claims.
How Pensero connects engineering activity to defensible cost attribution
Pensero is an empowerment tool for engineering performance that brings together real signals from GitHub, Jira, and the tools your team already uses to uncover how work moves, where it gets blocked, and how development practices and AI usage translate into real business impact.
For engineering leaders and managers thinking about software capitalization, this matters because Pensero solves the documentation problem that makes capitalization defensible rather than estimated.
Most capitalization processes break down at the artifact layer. Finance teams receive a spreadsheet. Engineering managers provide their best recollection of what was built versus maintained. Tax advisors apply a multiplier based on industry averages. None of this survives serious audit scrutiny because none of it is connected to the actual work.
Pensero connects compensation to pull requests, commits, and work items. It allocates cost by initiative and contributor, generating defensible CapEx versus OpEx splits automatically. Reports can be exported in audit-ready formats without timesheets, without manual tagging, and without year-end reconstruction. The work is classified continuously, in real time, from the source of truth: the delivery artifacts themselves.
Beyond the compliance function, the platform provides three capabilities that are directly relevant to any engineering organization evaluating its capitalization posture and team performance.
Benchmark: Do you have the best engineering team you could have?
"How do we compare to similar teams?"
Most engineering leaders can answer this question approximately, "we think we're above average", but cannot answer it with evidence. Pensero Benchmark places your organization against real global peers on real delivery data, not surveys, not self-reported activity, and not generic industry reports.
The benchmark tracks ten performance dimensions including delivery per headcount, defect rate, AI adoption and impact, cycle time, contribution distribution, and collaboration intensity. Every view includes a percentile ranking from 0 to 100 and a six-month trend line, so you can see not just where you stand but whether you are catching up, holding position, or falling behind.
For capitalization purposes, understanding your delivery percentile is relevant to the cost efficiency argument. A board or investor asking "are we getting a good return on what we are investing?" deserves a more precise answer than intuition. If your organization is at the 40th percentile on delivery per headcount, the cost-per-capitalizable-unit argument looks different than if you are at the 80th. That context shapes not just compliance conversations but resource allocation decisions, hiring prioritization, and AI tool investment justification.
ClosedLoop CEO Andrew Eye put it plainly: "I was being told by the board we were slow to ship, but I didn't have any visibility as to why that was. Now our entire team is above the 80th percentile."
Calibrate: Are all teams contributing the way we expect?
"Is everyone contributing at the level we expect?" and "What are our best engineers doing differently, and can we replicate that across the team?"
Pensero Calibrate lets engineering leaders and managers compare any team, cohort, or individual side by side on eleven performance metrics. This is not a ranking exercise, it is a diagnostic tool for understanding where performance patterns diverge and why.
You can compare new hires against tenured engineers to assess onboarding effectiveness. You can compare contractors by vendor against internal headcount to evaluate sourcing decisions. You can compare remote teams against co-located teams using the same objective delivery signals, eliminating the proximity bias that distorts most distributed team assessments. You can compare teams working on different product areas using complexity-weighted delivery rather than raw activity counts, which accounts for the fact that a team maintaining a legacy system and a team building a new microservice architecture are not doing equivalent work even if their PR counts are similar.
For capitalization, Calibrate addresses a specific gap: when cost allocation happens at the team or initiative level, knowing that performance varies significantly across those teams matters. If one team is operating at substantially lower delivery efficiency than peers on comparable work types, the cost per unit of capitalizable output for that team is higher. That is a management decision, not just an accounting one, but it only becomes visible when you have a way to compare internally with objective signals.
The numbers that surface are grounded in real work. Pensero's AI models score every contribution across magnitude and complexity, creating a unified view of delivery that does not rely on how engineers self-report their time or how managers recall what was shipped.
Engineering spend, classified and defensible
The case for continuous, artifact-based capitalization documentation is not primarily a tax argument, it is a business intelligence argument. Finance teams that understand what engineering is producing, in what cost categories, with what return characteristics, can make better capital allocation decisions. Engineering leaders who can show that their AI tool investments are generating measurable output gains, not just activity increases, have a stronger case for continued investment. Boards that receive structured, defensible reporting on engineering costs rather than approximations make better governance decisions.
Pensero turns engineering work into continuous, defensible cost attribution. Geography-aware team structures support office-level attribution. Salary mapping to R&E-eligible work items produces reproducible allocation logic. Classification of capitalizable engineering work connects directly to 174/174A compliance documentation.
"We estimated percentages" will not survive scrutiny. Artifact-based attribution will.
Proven success with TravelPerk, Despegar, and Caravelo demonstrates that this approach works at scale across engineering organizations managing seasonal delivery pressure, complex third-party integrations, and distributed global teams, exactly the conditions where manual capitalization processes break down most visibly.
Pricing as of March 2026: free tier available for up to 10 engineers and one repository; premium at $50/month; enterprise at custom pricing. Pensero is SOC 2 Type II, HIPAA, and GDPR compliant.
Integrations include GitHub, GitLab, Bitbucket, Jira, Linear, GitHub Issues, Slack, Microsoft Teams, Notion, Confluence, Google Calendar, Cursor, Claude Code, GitHub Copilot, Gemini Code Assist, OpenAI Codex, Google Drive, Google Chat, YouTrack, and Microsoft 365 Calendar.
Frequently Asked Questions
What is the difference between CapEx and OpEx in software development?
Capital expenditures (CapEx) represent investments in assets expected to produce value over multiple periods, recognized on the balance sheet and amortized over their useful life. Operating expenditures (OpEx) are period costs recognized in full in the income statement when incurred. For software, new feature development that creates durable functionality is generally CapEx; maintenance, bug fixes, and routine support are generally OpEx. The split has direct implications for EBITDA, tax exposure, and reported earnings.
Does Section 174 apply to all US companies developing software?
Section 174 applies to any domestic entity incurring research or experimental expenditures as defined under the Internal Revenue Code. For most software companies this means qualifying R&E costs must now be amortized over five years domestically and fifteen years for work performed outside the US, rather than deducted in full in the year incurred. The practical impact depends heavily on the volume of qualifying expenditures relative to taxable income. All organizations should consult qualified tax counsel to assess their specific exposure.
How does agile development affect our ability to capitalize software costs?
Agile does not prevent capitalization, it complicates documentation. The underlying accounting rules still apply, but the phase-based model that traditional guidance assumes does not map cleanly onto continuous delivery. The defensible approach is artifact-level classification: connecting each unit of work to its business purpose (new development versus maintenance) using actual delivery evidence rather than time estimates or project-phase assumptions.
Can AI-assisted code be capitalized?
Generally yes, subject to the same criteria as any other software development work. AI-generated code that forms part of a new application or substantially improves existing functionality during the application development phase meets the same tests as human-authored code under most frameworks. The documentation challenge is attributing the qualifying work accurately, particularly when AI tools assist with both new development and defect correction within the same session or pull request.
What documentation do auditors typically expect for software capitalization?
Auditors will typically want to see a consistent methodology for distinguishing capitalizable from non-capitalizable activities, documentation connecting cost pools to specific projects and phases, evidence that the capitalization policy has been applied consistently across periods, and support for the useful life assumptions used for amortization. The more this documentation is derived from actual delivery artifacts rather than retrospective estimates, the stronger it is under scrutiny.
How does Pensero help with Section 174 and R&D capitalization specifically?
Pensero provides continuous, artifact-based attribution that connects salary costs to qualifying R&E work items at the contributor and initiative level. The platform generates structured documentation suitable for audit and due diligence review, exports data in both CSV and API formats, and supports geography-aware team structures for the domestic/foreign amortization distinction under 174. It does not provide tax advice, all capitalization and tax treatment decisions should be made with qualified tax professionals.
What is the Pensero Benchmark and why does it matter for capitalization?
Pensero Benchmark ranks your engineering organization against real global peers on ten performance dimensions including delivery per headcount, defect rate, and AI impact. For capitalization purposes, understanding where your team sits on the delivery efficiency curve affects the cost-per-unit-of-capitalizable-output calculation and informs how you communicate engineering ROI to boards and investors. The benchmark updates weekly from live delivery data, not surveys.
What is Pensero Calibrate and how is it different from the Benchmark?
Benchmark measures your organization against external peers. Calibrate measures internal teams, cohorts, and individuals against each other and against the industry median. It is designed for operational decisions, promotions, team structure, vendor assessments, AI adoption analysis, using eleven performance metrics with drill-down capability and color-coded scoring relative to both company average and industry median.
Engineering is the largest cost center in most technology companies. It also produces some of the most defensible long-term value a business can create.
Yet the way most organizations account for that investment, if they account for it at all, ranges from "rough spreadsheet estimate" to "we'll figure it out at year-end."
That creates real financial exposure: missed tax deductions, incorrect EBITDA calculations, audit risk, and board conversations built on guesswork.
This guide walks through what software capitalization actually means, how the major accounting frameworks treat it, what is genuinely eligible, how agile teams navigate the rules, and, critically, how AI coding tools have complicated both the documentation burden and the ROI question for engineering leaders.
Life, the universe and accounting standards
Software capitalization refers to the practice of treating certain software development costs as capital expenditures (CapEx) rather than operating expenses (OpEx).
The logic is straightforward: when work produces a durable asset with future economic value, the costs associated with creating that asset belong on the balance sheet rather than the income statement. The practical challenge is that the line between "building something new" and "keeping the lights on" is rarely obvious, and regulators know it.
Different jurisdictions apply meaningfully different rules, which creates complexity for any engineering organization operating across markets.
US GAAP standards for software cost capitalization
Under US GAAP, the treatment of software costs depends heavily on what the software is for and who will use it. ASC 350-40 governs internal-use software, while ASC 985-20 applies to software developed for sale or license.
For internal-use software under ASC 350-40, development costs are divided into three phases: preliminary project, application development, and post-implementation. Only the middle phase, application development, generates capitalizable costs. This includes coding, testing, and direct integration work. Preliminary work such as vendor evaluation, requirements definition, and post-launch maintenance is expensed as incurred.
For software products sold to external customers (ASC 985-20), capitalization begins only after "technological feasibility" is established, a bar that is sometimes difficult to define cleanly in modern iterative development environments.
Section 174 and 174A of the Internal Revenue Code govern the tax treatment of research and experimentation (R&E) expenditures separately. Under changes effective from 2022, R&E costs must now be amortized over five years (domestic) or fifteen years (foreign) rather than immediately expensed. This single change substantially raised the stakes for engineering cost classification because it directly affects taxable income in years one through five of any qualifying project.
IFRS standards for software cost capitalization
Under IAS 38 (Intangible Assets), development costs can be capitalized once a project has passed the research phase and the entity can demonstrate six specific criteria: technical feasibility, intention to complete, ability to use or sell, likely future economic benefits, adequate resources, and ability to measure expenditure reliably. Research-phase costs must always be expensed.
In practice, IFRS tends to be more permissive than US GAAP in the sense that it requires judgment about probable future benefit rather than mandating a specific phase-based approach. That flexibility also means more documentation is needed to defend capitalization decisions under audit.
IFRS 15 and IFRS 16 intersect with software costs where development is tied to customer contracts or cloud-hosted arrangements, adding further complexity for SaaS businesses.
Canadian standards for software cost capitalization
Canada generally follows IFRS for publicly accountable enterprises, meaning IAS 38 applies. Private enterprises using ASPE (Accounting Standards for Private Enterprises) may follow a similar development-phase approach under Section 3064. The practical effect is that Canadian engineering organizations face much the same documentation challenges as their IFRS counterparts, with CRA scrutiny of SR&ED (Scientific Research and Experimental Development) claims adding a parallel track that engineering teams often manage separately.
EU standards for software cost capitalization
European Union entities follow IFRS as endorsed by the EU for consolidated financial statements of public companies. Local statutory accounts may follow national GAAP, which varies by member state, but the broad framework under IAS 38 applies at the group level for any multinational.
The EU's ongoing digitization initiatives and evolving tax harmonization discussions are worth monitoring, as transfer pricing of intangible assets (including internally developed software) has attracted increasing regulatory attention.
United Kingdom standards for software cost capitalization
Post-Brexit, the UK continues to apply UK-adopted IFRS for listed companies and FRS 102 or FRS 105 for smaller entities. FRS 102 Section 18 (Intangible Assets Other Than Goodwill) mirrors IAS 38 in most material respects, requiring the same six-criteria test for capitalization. HMRC's R&D relief schemes (RDEC and the reformed merged scheme) operate on a separate track but draw from similar documentation of qualifying activities.
Australian standards for software cost capitalization
Australia applies AASB 138 (equivalent to IAS 38) under the Australian Accounting Standards Board framework. The Taxation Office administers its own R&D incentive program separately, with specific eligibility criteria and registration requirements. As with Canada, engineering organizations often find themselves navigating two parallel documentation tracks, one for accounting, one for tax.
Mostly harmless: a guide to what's worth capitalizing
The short version: work that creates new functionality or substantially improves existing functionality is typically capitalizable. Work that keeps existing functionality running is not.
The longer version requires judgment at the activity level. The following activities are generally capitalizable under most frameworks once a project has passed the preliminary design phase: coding new features and core application modules, writing automated tests tied to new development, integration work connecting new systems to existing infrastructure, direct management time spent supervising qualifying development activities, and security or performance work that meaningfully enhances capability rather than merely maintaining it.
The following are generally expensed: bug fixes and routine maintenance, user training, data conversion from legacy systems, post-launch support, and overhead not directly tied to development activities.
The challenge is that in practice, most engineers do some combination of both categories across any given sprint. A story that starts as a feature request may require fixing an underlying defect before new code can be written. An AI coding assistant may produce output that includes both new logic and corrected existing logic.
Documentation and review work spans both categories. None of this is unusual, it simply means that activity-level classification requires either time tracking, artifact-level tagging, or an automated system capable of inferring work type from the nature of the contribution itself.
My team is agile, how does this work for us?
The honest answer is that agile development creates genuine friction with traditional capitalization frameworks, and most accounting guidance was written before continuous delivery was the default mode of software development.
The core problem is phase separation. ASC 350-40 assumes a project proceeds from preliminary work to active development to post-implementation in a recognizable sequence. Agile teams run all three activities simultaneously: defining requirements, building features, and maintaining production systems happen in the same sprint, sometimes on the same day by the same engineer.
Three approaches are commonly used in practice. The first is the effort-estimation method, where teams assign a fixed percentage of engineering time to capitalizable activities based on the nature of the sprint or project portfolio. This is administratively simple but difficult to defend under audit because the percentages are assumptions rather than observations. The second is timesheet-based tracking, where engineers log time against capitalizable and non-capitalizable categories. This produces defensible documentation but creates workflow overhead that most engineering teams resist.
The third approach, increasingly viable with AI-powered tooling, is artifact-based attribution, where the nature and purpose of each code change, pull request, or work item is analyzed directly rather than inferred from time estimates. A system that understands what a given commit does, what ticket it resolves, and whether that ticket represents new development versus maintenance can classify work continuously and automatically, producing documentation that is both accurate and auditable.
That third approach is where engineering intelligence platforms have created real value for finance and tax teams, and where the documentation burden that once required weeks of manual reconstruction becomes a continuous, automated byproduct of the work itself.
The AI tools ROI problem
"Is AI actually making us more productive or just changing how work is done?"
This is the question boards and investors are asking in 2026, and most engineering organizations cannot answer it. Companies are spending significantly on tools like GitHub Copilot, Cursor, Claude Code, and Gemini Code Assist without a reliable way to connect that investment to delivery outcomes, quality impact, or capitalizable output.
The capitalization angle here is not trivial. AI-assisted code changes the economics of software development in ways that affect how organizations should think about cost attribution. If an engineer produces a 600-line feature in three hours with AI assistance where the same task would previously have taken two days, the labor cost allocated to that work changes. If AI tools are raising the floor on output quality, defect rates should be declining, which affects how much rework is expensed rather than capitalized. If agentic workflows are generating code that engineers then review and modify, the question of who (or what) authored a qualifying R&E contribution becomes relevant to documentation.
These are not hypothetical edge cases. Pensero's 2026 benchmark report measured engineering delivery across thousands of active engineers from November 2025 to April 2026. Average delivery rose 34.2% in that period. The top 5% of teams grew 51.4%, at roughly 1.5 times the rate of the average. The performance gap between elite and average teams widened from 4.9× to 5.9×, and the acceleration tracked directly to the period when AI-assisted and agentic development workflows shifted from experiment to default.
Those numbers matter for capitalization in a specific way: if your team's delivery baseline has shifted materially, your cost-per-unit-of-capitalizable-output has also shifted. Organizations that assume their capitalization percentages from 2023 or 2024 still apply in 2026 may be misallocating engineering costs in either direction.
Pensero shows the real impact on work patterns and helps teams measure the ROI of these investments rather than relying on theoretical performance claims.
How Pensero connects engineering activity to defensible cost attribution
Pensero is an empowerment tool for engineering performance that brings together real signals from GitHub, Jira, and the tools your team already uses to uncover how work moves, where it gets blocked, and how development practices and AI usage translate into real business impact.
For engineering leaders and managers thinking about software capitalization, this matters because Pensero solves the documentation problem that makes capitalization defensible rather than estimated.
Most capitalization processes break down at the artifact layer. Finance teams receive a spreadsheet. Engineering managers provide their best recollection of what was built versus maintained. Tax advisors apply a multiplier based on industry averages. None of this survives serious audit scrutiny because none of it is connected to the actual work.
Pensero connects compensation to pull requests, commits, and work items. It allocates cost by initiative and contributor, generating defensible CapEx versus OpEx splits automatically. Reports can be exported in audit-ready formats without timesheets, without manual tagging, and without year-end reconstruction. The work is classified continuously, in real time, from the source of truth: the delivery artifacts themselves.
Beyond the compliance function, the platform provides three capabilities that are directly relevant to any engineering organization evaluating its capitalization posture and team performance.
Benchmark: Do you have the best engineering team you could have?
"How do we compare to similar teams?"
Most engineering leaders can answer this question approximately, "we think we're above average", but cannot answer it with evidence. Pensero Benchmark places your organization against real global peers on real delivery data, not surveys, not self-reported activity, and not generic industry reports.
The benchmark tracks ten performance dimensions including delivery per headcount, defect rate, AI adoption and impact, cycle time, contribution distribution, and collaboration intensity. Every view includes a percentile ranking from 0 to 100 and a six-month trend line, so you can see not just where you stand but whether you are catching up, holding position, or falling behind.
For capitalization purposes, understanding your delivery percentile is relevant to the cost efficiency argument. A board or investor asking "are we getting a good return on what we are investing?" deserves a more precise answer than intuition. If your organization is at the 40th percentile on delivery per headcount, the cost-per-capitalizable-unit argument looks different than if you are at the 80th. That context shapes not just compliance conversations but resource allocation decisions, hiring prioritization, and AI tool investment justification.
ClosedLoop CEO Andrew Eye put it plainly: "I was being told by the board we were slow to ship, but I didn't have any visibility as to why that was. Now our entire team is above the 80th percentile."
Calibrate: Are all teams contributing the way we expect?
"Is everyone contributing at the level we expect?" and "What are our best engineers doing differently, and can we replicate that across the team?"
Pensero Calibrate lets engineering leaders and managers compare any team, cohort, or individual side by side on eleven performance metrics. This is not a ranking exercise, it is a diagnostic tool for understanding where performance patterns diverge and why.
You can compare new hires against tenured engineers to assess onboarding effectiveness. You can compare contractors by vendor against internal headcount to evaluate sourcing decisions. You can compare remote teams against co-located teams using the same objective delivery signals, eliminating the proximity bias that distorts most distributed team assessments. You can compare teams working on different product areas using complexity-weighted delivery rather than raw activity counts, which accounts for the fact that a team maintaining a legacy system and a team building a new microservice architecture are not doing equivalent work even if their PR counts are similar.
For capitalization, Calibrate addresses a specific gap: when cost allocation happens at the team or initiative level, knowing that performance varies significantly across those teams matters. If one team is operating at substantially lower delivery efficiency than peers on comparable work types, the cost per unit of capitalizable output for that team is higher. That is a management decision, not just an accounting one, but it only becomes visible when you have a way to compare internally with objective signals.
The numbers that surface are grounded in real work. Pensero's AI models score every contribution across magnitude and complexity, creating a unified view of delivery that does not rely on how engineers self-report their time or how managers recall what was shipped.
Engineering spend, classified and defensible
The case for continuous, artifact-based capitalization documentation is not primarily a tax argument, it is a business intelligence argument. Finance teams that understand what engineering is producing, in what cost categories, with what return characteristics, can make better capital allocation decisions. Engineering leaders who can show that their AI tool investments are generating measurable output gains, not just activity increases, have a stronger case for continued investment. Boards that receive structured, defensible reporting on engineering costs rather than approximations make better governance decisions.
Pensero turns engineering work into continuous, defensible cost attribution. Geography-aware team structures support office-level attribution. Salary mapping to R&E-eligible work items produces reproducible allocation logic. Classification of capitalizable engineering work connects directly to 174/174A compliance documentation.
"We estimated percentages" will not survive scrutiny. Artifact-based attribution will.
Proven success with TravelPerk, Despegar, and Caravelo demonstrates that this approach works at scale across engineering organizations managing seasonal delivery pressure, complex third-party integrations, and distributed global teams, exactly the conditions where manual capitalization processes break down most visibly.
Pricing as of March 2026: free tier available for up to 10 engineers and one repository; premium at $50/month; enterprise at custom pricing. Pensero is SOC 2 Type II, HIPAA, and GDPR compliant.
Integrations include GitHub, GitLab, Bitbucket, Jira, Linear, GitHub Issues, Slack, Microsoft Teams, Notion, Confluence, Google Calendar, Cursor, Claude Code, GitHub Copilot, Gemini Code Assist, OpenAI Codex, Google Drive, Google Chat, YouTrack, and Microsoft 365 Calendar.
Frequently Asked Questions
What is the difference between CapEx and OpEx in software development?
Capital expenditures (CapEx) represent investments in assets expected to produce value over multiple periods, recognized on the balance sheet and amortized over their useful life. Operating expenditures (OpEx) are period costs recognized in full in the income statement when incurred. For software, new feature development that creates durable functionality is generally CapEx; maintenance, bug fixes, and routine support are generally OpEx. The split has direct implications for EBITDA, tax exposure, and reported earnings.
Does Section 174 apply to all US companies developing software?
Section 174 applies to any domestic entity incurring research or experimental expenditures as defined under the Internal Revenue Code. For most software companies this means qualifying R&E costs must now be amortized over five years domestically and fifteen years for work performed outside the US, rather than deducted in full in the year incurred. The practical impact depends heavily on the volume of qualifying expenditures relative to taxable income. All organizations should consult qualified tax counsel to assess their specific exposure.
How does agile development affect our ability to capitalize software costs?
Agile does not prevent capitalization, it complicates documentation. The underlying accounting rules still apply, but the phase-based model that traditional guidance assumes does not map cleanly onto continuous delivery. The defensible approach is artifact-level classification: connecting each unit of work to its business purpose (new development versus maintenance) using actual delivery evidence rather than time estimates or project-phase assumptions.
Can AI-assisted code be capitalized?
Generally yes, subject to the same criteria as any other software development work. AI-generated code that forms part of a new application or substantially improves existing functionality during the application development phase meets the same tests as human-authored code under most frameworks. The documentation challenge is attributing the qualifying work accurately, particularly when AI tools assist with both new development and defect correction within the same session or pull request.
What documentation do auditors typically expect for software capitalization?
Auditors will typically want to see a consistent methodology for distinguishing capitalizable from non-capitalizable activities, documentation connecting cost pools to specific projects and phases, evidence that the capitalization policy has been applied consistently across periods, and support for the useful life assumptions used for amortization. The more this documentation is derived from actual delivery artifacts rather than retrospective estimates, the stronger it is under scrutiny.
How does Pensero help with Section 174 and R&D capitalization specifically?
Pensero provides continuous, artifact-based attribution that connects salary costs to qualifying R&E work items at the contributor and initiative level. The platform generates structured documentation suitable for audit and due diligence review, exports data in both CSV and API formats, and supports geography-aware team structures for the domestic/foreign amortization distinction under 174. It does not provide tax advice, all capitalization and tax treatment decisions should be made with qualified tax professionals.
What is the Pensero Benchmark and why does it matter for capitalization?
Pensero Benchmark ranks your engineering organization against real global peers on ten performance dimensions including delivery per headcount, defect rate, and AI impact. For capitalization purposes, understanding where your team sits on the delivery efficiency curve affects the cost-per-unit-of-capitalizable-output calculation and informs how you communicate engineering ROI to boards and investors. The benchmark updates weekly from live delivery data, not surveys.
What is Pensero Calibrate and how is it different from the Benchmark?
Benchmark measures your organization against external peers. Calibrate measures internal teams, cohorts, and individuals against each other and against the industry median. It is designed for operational decisions, promotions, team structure, vendor assessments, AI adoption analysis, using eleven performance metrics with drill-down capability and color-coded scoring relative to both company average and industry median.
