Your Software Capitalization Process Is Solving a Problem GAAP Doesn't Require
The tell is usually tickets
I had recently joined a company and got wind they were re-imagining their capitalization process. The plan: track capitalized software at the Jira ticket level.
Before I’d seen a single spreadsheet, I knew what was coming.
The company had inherited three distinct approaches from its history. The oldest: a blanket capitalization percentage applied per headcount. Each engineer’s salary was capitalized at 80% for individual contributors, 40% for managers. Auditors had flagged it as insufficient, not because it lacked precision, but because there was no asset tracking at all. No connection between the capitalized dollars and specific initiatives, no amortization logic, no traceability. The flag was right. The response wasn’t.
The CTO and CFO assembled a project team. Finance sent the technical accountant and the head of internal controls. Tech sent a Jira administrator who had built a time-tracking process at an acquired company.
I wasn’t officially on the project, but had tackled similar problems before. Before the first project team meeting, I set up time with the Jira admin. I offered to walk through the accounting standard. What it actually required and where the flexibility was.
He stopped me halfway through: “I don’t need to know how capitalization works, I just need someone to tell me what to build in Jira.”
In the first project team meeting, he walked through his process: granular, engineer-by-engineer, and never implemented for more than fifty people. The team agreed it was too detailed. They landed on story points as the right altitude. Then they focused on consolidating 5 separate Jira instances and automating the monthly reports.
Every intervention asked the same question: how do we track this better?
That’s the wrong question.
GAAP doesn’t care about your timesheets. But most companies assume it does.
The accounting standard is deliberately broad. It requires that you track capitalizable costs at the asset level, apply a reasonable useful life, and begin amortization when the asset is in use. It doesn’t require a per-ticket accounting of every engineer’s time.
Nobody in that room had read the standard.
Focusing on tracking engineering effort carried real costs.
The overhead is visible to most CTOs. I’ve seen this take 400 to 500 hours per quarter at companies with around 400 engineers. Team leads filling out forms, finance chasing submissions, accounting reconciling outputs that don’t quite line up. It shows up as drag every quarter, every month, every sprint.
But the bigger risk was the audit surface they were building.
More tracking looked like more evidence. More evidence looked like more protection: spreadsheets, signoffs, documented workflows, a paper trail for every dollar. The team saw rigor and assumed that was the same thing as defensibility.
It isn’t. More evidence means more evidence to defend.
And then there are the IT general controls. Reliance on Jira for a process with material impact on financial statements means Jira is now a financial system. Subject to SOX change controls, access management and data retention requirements.
You’ve handed your auditors a thread attached to a tool your engineering team treats as a productivity system. Pull it and you’re not demonstrating rigor. You’re surfacing every place your Jira hygiene has ever slipped.
There may be other reasons to track engineering time. Capacity planning, burnout monitoring, understanding your “keep the lights on” spend: these are legitimate uses. But they serve a management decision, not an accounting requirement.
Don’t let GAAP take the blame for that overhead. It’s self-inflicted pain from tracking at the wrong altitude. And the wrong altitude had a second consequence that was harder to see.
At this company, product managers and designers were doing capitalizable work during the application development stage. Their time met the standard’s definition. They just weren’t in the cost basis. Not because of a policy decision to exclude them. Because the Jira tickets didn’t track product manager work. When the team was busy optimizing the Jira workflow, no one thought to include the product team.
When we got the blessing from our auditor to add them, the CFO took the increase in capitalized software and added it directly to the technology budget. 10% more. Millions of dollars, available the whole time, hiding in a tooling choice that had quietly become a policy decision.
That’s the gap. Overhead in the form of precision GAAP doesn’t require. Foregone upside from latitude it always offered.
AI is making one thing structurally different: questioning a process no longer requires a crisis.
Before, you inherited a process, optimized it, and only reopened the foundational question when something broke badly enough. The cost of asking “what does this actually need to do?” was too high relative to the friction you’d already normalized.
That cost has dropped.
Capitalized software is one example. The pattern holds for controls, for products, for any process that calcified before anyone re-read the original obligation. Trace it back to the actual requirement. The latitude was always there. It just wasn't in the process anyone handed you.
I’m Clare Hawthorne. I founded OxerLine Advisory to fix friction at the seam between technology and the business. If this is something you’re facing, let’s chat.