Most companies capitalize software development costs from estimates of how engineers split their time. Auditors challenge it because it can't be verified. We build the basis from the code itself — every dollar traced to a source record.
Software capitalization is one of the few places where a technology question lands directly on the balance sheet. Capitalize too aggressively and you overstate assets and earnings; expense everything and you understate them. The rule (ASC 350-40) is well understood. What's missing, almost everywhere, is defensible evidence for the one judgment that drives the number: which engineering work was development, and which was research or maintenance.
Under ASC 350-40, internal-use software costs fall into three stages, and the stage determines the treatment:
The rule is not the problem. The problem is the boundary. Real engineering work doesn't announce which stage it belongs to, and a single sprint routinely mixes new development with maintenance and exploration. The capitalization number is only as good as your ability to draw that line — and prove where you drew it.
Walk into most finance teams and the capitalization basis traces back to a spreadsheet: engineers (or their managers) estimate what percentage of their time went to capitalizable projects, and that allocation is applied to payroll. It is self-reported, retrospective, and effectively unverifiable.
Auditors know this, so it draws scrutiny — and in a review or a transaction, a basis built on estimates is a soft spot. The exposure cuts both ways: under-capitalizing quietly depresses earnings, and over-capitalizing inflates assets you may later have to impair. Either way, "we asked the team how they spent their time" is not the answer a CFO wants to give when the basis is questioned.
The engineering work already left a record. Every change is a commit, attributed to a person, attached to a part of the system, at a point in time. Read together, that history shows what was actually built, by whom, and when — not what a year-end estimate says.
We read commit history, code ownership, and project structure, then attribute engineering effort to specific bodies of work and map each to capitalizable development or expensed maintenance. The output is a basis tied to evidence: a defensible number, with every dollar traceable to a source record an auditor can follow — the same discipline you already apply to revenue and every other material number.
AI and machine-learning work has made the boundary harder, exactly as its share of engineering spend has climbed. Model experimentation often looks like research and should be expensed. Data-pipeline, integration, and productionization work often qualifies as development. Ongoing retraining is usually maintenance. Drawn from estimates, that split is guesswork; drawn from the actual work, it is defensible. With AI now a large line on the engineering budget, the allocation moves both the balance sheet and reported margins — see our read on the true cost and exposure of AI in your systems.
Every other material number on your statements has an evidence discipline behind it. The engineering work behind software capitalization has left a complete record the entire time — it has simply never been read. We read it, and translate it into a basis you can defend.
Under ASC 350-40, application-development-stage costs (coding, configuration, direct testing) are generally capitalized; preliminary-stage and post-implementation (maintenance, training) costs are expensed. The difficulty is proving which engineering effort actually fell in the development stage.
Because most of it is built from timesheets and management estimates of how engineers split their time — self-reported and hard to verify. A basis tied to commit history and code ownership is far easier to defend.
Some of it. The same development-vs-research-and-maintenance logic applies, but AI blurs the lines: experimentation looks like research, pipeline and integration work often qualifies as development, and retraining is usually maintenance. Getting the split right now moves both the balance sheet and reported margins.
We read commit history, code ownership, and project structure to attribute engineering effort to specific work, then map it to capitalizable development vs. expensed maintenance — every dollar tied to a source record.
No. We are not your auditor and we issue no accounting opinion. We provide the independent, evidence-based read of the engineering work that your finance team and auditors use as the factual basis for treatment.
We read the engineering work behind your software and translate it into a capitalization basis your finance team and auditors can stand behind.
Get a Read →