Writing CapEx rationales (US GAAP)

You classified the work correctly. The project was CapEx from day one — new capability, new platform, clear future economic benefit. Finance is happy. The auditors arrive. They ask: “Can you show us the rationale for capitalizing this $1.2M of engineering effort under ASC 350-40?”

You open Jira. You gesture vaguely at a project board. You mention something about “application development stage.” The auditor’s expression changes — because what they needed was a narrative, and what you have is ticket titles.

This play covers capitalization under US GAAP (ASC 350-40), which applies to internal-use software developed by US-reporting companies. For IFRS, see Writing CapEx rationales (IFRS).

Classification gets you to the starting line. The rationale is what actually gets the cost on the balance sheet.

The job

ASC 350-40 (Internal-Use Software) doesn’t work like IFRS. There are no six recognition criteria to satisfy. Instead, the standard defines three project stages, and the capitalization rules are different for each:

Preliminary project stage. You’re evaluating alternatives, determining whether the project is feasible, selecting vendors, making the go/no-go decision. Nothing is capitalized. All costs are expensed as incurred.
Application development stage. You’ve committed to building it. Design, coding, testing, installation — this is where capitalization begins. Costs directly attributable to developing the software are capitalized. This includes salaries of developers writing code, contractor costs for development work, and third-party software purchased for the project.
Post-implementation/operation stage. The software is live. Training, maintenance, bug fixes — all expensed. Capitalization stops when the software is substantially complete and ready for its intended use.

The critical question isn’t “does this meet six criteria?” It’s “which stage is this work in, and can you prove it?”

A CapEx rationale under US GAAP is the document that maps your project timeline to these three stages with enough evidence that an auditor can verify the boundaries.

Why it matters

The numbers are material. A 200-person engineering organization spending $25M annually might capitalize 40-60% of that. That’s $10-15M that hits the balance sheet instead of the P&L. The difference between a strong rationale and a weak one isn’t whether the work qualifies — it’s whether you can defend the stage boundaries.

Audit exposure. US auditors focus heavily on the transition points between stages. When exactly did “preliminary project” become “application development”? When exactly was the software “substantially complete”? If you can’t point to specific dates with supporting evidence, the auditor will draw the lines themselves. They will be conservative.

Board and investor confidence. For PE-backed companies, the capitalization ratio is a metric that operating partners watch. A high CapEx percentage tells a story about investment in future value. But only if the rationale holds up. If auditors force a reclassification, the P&L takes a hit and the story unravels publicly.

Finance trust. Every time engineering produces a clean, well-evidenced rationale without being chased, the relationship between engineering and finance gets stronger. Every time finance has to reconstruct the narrative from scraps, it erodes.

What good looks like

Mature practice:

Every capitalized project has a written rationale that maps the project timeline to ASC 350-40 stages
Stage transition dates are documented with evidence (architecture sign-off, go-live confirmation)
Engineering managers write them as part of project setup — it’s a ten-minute job, not a compliance exercise
Auditors review rationales and move on. No follow-up meetings. No extended testing.
The capitalization decision is defensible twelve months later without anyone having to remember the context

Struggling practice:

Classification happens at quarter-end based on retrospective judgment
Rationales are written after the fact by finance, based on conversations with engineers who’ve moved on
Audit queries generate scrambles, late nights and uncertain outcomes
The organization capitalizes conservatively because nobody’s confident the stage boundaries will hold up — leaving legitimate CapEx on the P&L

The approach

Step 1: Know the three stages cold

This is simpler than IAS 38 in some ways, more prescriptive in others. The entire framework turns on correctly identifying which stage the work is in.

Preliminary project stage — everything before the commitment to build:

Evaluating build vs. buy
Proof-of-concept work to determine feasibility
Vendor selection and RFP processes
Strategic planning and requirements gathering
All costs expensed. No exceptions.

Application development stage — everything from commitment to substantial completion:

Detailed design of the chosen approach
Coding and unit testing
Integration testing
Data conversion and migration (directly related to getting the software functional)
Costs are capitalized, including: developer salaries for time spent on the project, contractor costs, third-party software costs integral to the project

Post-implementation stage — everything after the software is live:

User training
Ongoing maintenance and bug fixes
Minor enhancements (unless they add significant new functionality — then they might restart the cycle)
All costs expensed.

The grey area that causes the most trouble: when does preliminary project end and application development begin? The standard says it’s when management commits to funding the project and it’s probable that the project will be completed and used as intended. In practice, this is usually the point where you have an approved technical approach, an allocated team, and a funded timeline.

Step 2: Write the rationale at the stage transition

The most important moment to document is the transition from preliminary to application development. This is the date from which costs start being capitalized. Get this wrong and everything downstream is off.

The rationale should include:

Project name and identifier. Match it to whatever your project management system uses. Auditors will cross-reference.

Business context. Two to three sentences on why this project exists and how the software will be used internally. ASC 350-40 applies specifically to internal-use software — if the software is being developed for sale, ASC 985-20 applies instead.

Preliminary stage summary. What alternatives were evaluated, what proof-of-concept work was done, when and how the decision to build was made. This establishes that the preliminary stage happened and is complete.

Application development start date. The specific date. Tie it to a concrete event: “Architecture review board approved the technical approach on March 15. Team allocation was confirmed on March 18. Application development stage began March 18.” Auditors love dates with evidence.

What’s being capitalized. Developer time (name the roles, not necessarily the people), contractor costs, any third-party software purchased for the project. Be specific about what’s included and what’s excluded — testing costs directly related to the project are capitalizable, but general overhead and training are not.

Expected completion date. When you expect the software to be substantially complete and in use. This is when capitalization stops and amortization begins.

Step 3: Document the finish line

The second critical transition is application development to post-implementation. Capitalization stops when the software is “substantially complete and ready for its intended use.” Document:

The date the software went live or was substantially complete
Evidence of completion (deployment records, user acceptance sign-off)
Confirmation that amortization should begin from this date
The useful life estimate for amortization purposes (typically 3-5 years for internal-use software)

Step 4: Handle upgrades and enhancements

ASC 350-40 has specific guidance on upgrades. If a modification adds significant new functionality, the costs can be capitalized as a new asset. If it’s maintenance, bug fixes, or minor enhancements, it’s expensed.

The rationale for an enhancement should explain:

What new functionality is being added
Why it constitutes a significant addition rather than maintenance
The application development start and end dates for the enhancement specifically

This is where organizations most commonly get tripped up. An engineer’s “major refactor” might be OpEx if it doesn’t add new functionality. A “small feature” might be CapEx if it enables a genuinely new capability. The rationale forces the conversation.

Step 5: Build a rationale library

After a few quarters, you’ll have rationales for a dozen projects. These become templates. New rationales get faster to write because you’re not starting from scratch — you’re adapting a proven structure. Engineering managers start to internalize what a good rationale looks like.

This library also becomes a powerful reference for finance. When the CFO needs to explain the capitalization position to the board, the rationales are the source material. When auditors arrive, the library is the first thing you hand them.

The conversations

With your CFO

Trust-building: “Every capitalized project has a written rationale that maps to ASC 350-40 stages with documented transition dates. Here’s the library for this year — your auditors should be able to work through them independently.”

Trust-eroding: “Yeah, we capitalized about 50% of engineering this year. I can probably explain why if you give me a few days to go through the Jira boards.”

With your auditors

Trust-building: “Each project in scope has a rationale document that identifies the preliminary, application development, and post-implementation stages with specific transition dates and supporting evidence. Expenditure attribution ties back to our workforce data. Let me walk you through the first one.”

Trust-eroding: “We think most of this work was new development. Can I get back to you with more detail?”

With your engineering managers

Trust-building: “When you move a project from exploration into active development, I need a one-page rationale. What stage are we in, when did it transition, and what are we capitalizing. Takes ten minutes and it protects millions of dollars on the balance sheet.”

Trust-eroding: “Finance needs you to justify every project’s capitalization. I know, I know. Just do it.”

Common failure modes

Not documenting the stage transition date. This is the single most common error. Without a documented date for when application development began, the auditor has to pick one. They will pick a later date than you would, which means fewer months of capitalized costs.

Capitalizing preliminary stage costs. Proof-of-concept work, vendor evaluations, feasibility studies — these are all expensed under ASC 350-40, no matter how expensive they were. Some organizations try to argue that a $200K proof of concept was “really application development.” Auditors see through this immediately.

Forgetting that training is never capitalized. Even training that happens during the application development stage is expensed. This catches organizations that embed training costs in their project budgets and capitalize the lot.

Treating all enhancements as CapEx. A refactor that improves performance but doesn’t add new functionality is maintenance — it’s OpEx. The temptation to capitalize large refactoring projects is strong, especially when they take months. But ASC 350-40 is clear: without significant new functionality, it’s expensed.

Not distinguishing internal-use from external-use software. ASC 350-40 applies only to internal-use software. If you’re building software for sale or as part of a SaaS product, different rules apply (ASC 985-20 or ASC 606). The rationale should be explicit about the software’s intended use.

Over-capitalizing to improve the P&L. It’s tempting. A higher CapEx ratio makes the current period look better. But aggressive capitalization creates future amortization charges and audit risk. Capitalize what genuinely qualifies, write honest rationales, and let the numbers land where they land.

Getting started

This week: Pull up the list of projects your organization capitalized last year. For each one, ask: does a written rationale exist with documented stage transition dates? If the answer is no for most of them, that’s your starting point.

This month: Write rationales for every currently active capitalized project. Yes, they’re already in flight — that’s fine. Capture the current state and identify which stage each project is in right now.

This quarter: Make rationale writing part of the stage transition. When a project moves from preliminary to application development, the rationale gets written. When it goes live, the rationale gets closed out. Review the first few with your finance team to calibrate.

The CapEx/OpEx Discipline — Classification is the prerequisite. This play picks up where that one stops — turning a correct classification into a defensible financial position.
R&D Investment Documentation — The same project can generate both a CapEx rationale and R&D documentation. They serve different purposes but draw from the same source material.
Writing CapEx rationales (IFRS) — If your organization reports under IFRS rather than US GAAP, the IAS 38 edition covers the six recognition criteria approach.
Investment Framing — The business case that justified the project is an input to the CapEx rationale. If you framed the investment well, the rationale practically writes itself.