Your Software CapEx Split Is a Management Estimate. It Should Be Evidence.

TL;DR: Most software capitalization splits are a management estimate dressed up as a number. They come from Jira tickets, quarterly surveys, and a spreadsheet nobody can re-run, and none of it is primary support an auditor will accept. The fix is to stop asking people what they built and read it from the code itself.

The number ships. The evidence never does.

Here is how software capitalization works at most companies. Finance needs a CapEx and OpEx split for the quarter. Finance asks engineering. Engineering asks Jira. Jira returns tickets that are proxied, partial, and quietly gamed. Someone rounds to a familiar percentage, the number ships, and the close moves on.

Three quarters later an external auditor asks one question: how was that split derived? The room goes quiet, because the honest answer is a blend of story points, a survey, and a controller’s judgment. As one finance lead put it to me: “We just round to 40% CapEx. Always have.”

Under IAS 38 and ASC 350-40, capitalized software cost is meant to rest on evidence of the work performed. A text field in a ticketing tool, on its own, rarely clears that bar.

The three ways teams report CapEx, and why each one breaks

Ticket-based. Story points are a negotiation tool, not a ledger. Labels drift, tickets get reopened, scope shifts mid-sprint. The percentage a controller signs rests on fields that were never meant to be accounting records.

Survey-based. Asking engineers each quarter what they worked on produces best-effort recollection, which is a management estimate, not a measurement. It burns engineering days every close, misses contractors and offshore teams entirely, and returns a different answer depending on who you ask and when. “I genuinely don’t remember what I shipped in March” is the usual result.

Spreadsheet-based. The moment FP&A needs to restate a prior period, for a new capitalization policy, an acquisition, or an R&D credit study under IRC Section 41, the work starts from zero. A spreadsheet has no rewind button. You spend weeks of finance time and still cannot defend the number.

Read it from the code instead

Your repository already holds the record of what engineering actually did: every commit, every diff, every file touched, every refactor, the ownership and dependency graph, and the complexity of each task. That is the primary support finance has been approximating with surveys all along.

So classify the work at the source. Navigara reads the repository directly and classifies every unit of work the moment it lands, as capitalizable development or operating expense, against your written policy. No timesheets, no survey forms, no ticket-hygiene project. The split reflects real engineering effort and complexity rather than commit count.

This is the same principle behind everything we build: engineering should be measured from the artifact it produces, the code, not from what people remember about it. It is how we score output as Engineering Throughput Value, and it is what turns a capitalization split from a guess into something you can hand an auditor.

Restate any quarter, going back years

Because the source of truth is your git history and not a snapshot of someone’s timesheet, you can apply today’s capitalization policy to last year, the year before, or the year of an acquisition. Policy changed? Re-run it. Auditor wants Q3 2024 under the new rules? Re-run it. M&A reconciliation across two separate code histories? Re-run it. Restatements under IAS 8 and ASC 250 stop being a fire drill and become a query, with the underlying evidence intact.

Every hour pinned to a SHA

This is the part auditors actually care about. Each cell in the report drills down to the commits, the diffs, and the exact policy rule that classified them. When someone asks why a line item is CapEx, the answer is not “engineering told us.” It is a specific change and a signed policy version.

It is also built for where the standards are going. Under ASU 2025-06, ASC 350-40 replaces the old stage-gate model with a principles-based threshold, and the same engine reports against either basis. Coverage is 100% of contributors, including the bots, vendors, and contractors that surveys quietly drop. Variance against the ledger stays under your materiality threshold. SOC 2 Type 2 covers data security today, and SOC 1 Type 2 is on the roadmap for the ICFR-relevant controls.

From a guess to a system of record

The status quo is a report built from what people remember: engineers losing one to two days a quarter, contractors missing from the totals, no way to restate, and errors surfacing at year-end instead of at commit time. The alternative is a report derived from your repository, produced automatically, and defensible down to the SHA.

If you own the capitalization number, that is the difference between hoping the audit goes well and knowing it will. See how automated CapEx and OpEx reporting works, or bring your policy manual and a repository to a 30-minute walkthrough and leave with a real CapEx report derived from your own commits, under your own policy.