What Does a Technology Company’s Capitalized Software Spending Mean for Earnings and Cash Flow?

Capitalizing development costs postpones an expense, it does not eliminate the cost or the cash outflow. Eligible costs become an asset. Generally, these costs flow through to earnings through amortization. This can increase current operating profit. When comparing companies, I suggest starting with the difference between capitalized development costs and the related amortization charges to determine how much of the apparent margin advantage comes from expense timing.^[1][2]

I don't view the capitalization itself as suspicious. As you evaluate software development costs, you need to determine if the expenses are being capitalized according to the relevant provisions of US GAAP. What bothers me is how different companies, in effect, compare different activities to calculate operating profit (i.e. how they treat different time periods for expensing development costs), and how those companies compare themselves to others. You can compare companies without declaring either of them wrong. The rules I discuss are rules of US GAAP.^[1][2]

First, find out which software rules apply

“Internal-use” doesn’t always refer to an employee’s back-office application. Software a company uses to deliver a service to the customer via the Internet or some other network can also fall under “internal-use” ASC 350-40. Software sold to customers would be covered under ASC 985-20. The major determinant is whether the software is sold to customers, not whether it generates service revenue.^[1][2]

Under the legacy internal-use rules, preliminary evaluation costs are expensed. If the preliminary evaluation is complete, and management provides an authorizing and committing funds, completion and intended use are assumed, then eligible costs for software application development are capitalized. Eligible costs include the compensation of employees and service providers directly related to software development. Routine maintenance and training are charged to expense.^[1][2]

As of October 7, 2026 ASU 2025-06 becomes effective. Project-stage gating is removed and the standard requires authorized, committed funding and probable completion and intended use. There could be significant development uncertainty that could impact the probability assessment. Novel, unproven functionality would create development uncertainty. The amendment is effective for annual periods beginning after December 15, 2027, including interim periods within them. Early adoption is permitted. As of June 2026 Freshworks’ quarterly filing still reflects it hasn’t adopted the standard.^[1][4]

For software developed for sale, capitalization runs from technological feasibility to general release. Feasibility requires more than management’s confidence; a detailed program design or working model must establish that the product can meet its specifications. The window can be quite short. Based on Teradata’s 2025 filing, its window from working model to release was quite short, and qualifying external use development costs were insignificant and expensed. I don’t think that means Teradata’s developers were charged less than their opportunity cost.^[2][6]

The expense comes back after deployment

For internal-use software, amortization begins when it’s ready for its intended use, generally after substantial testing is complete. The cost is spread over its estimated useful life, usually on a straight-line basis. External-use software starts amortization at general release; its annual charge is the greater of a revenue-based calculation or straight-line amortization over the remaining economic life. The revenue calculation compares current product revenue with current plus anticipated future product revenue.^[2]

The useful-life estimate matters because a longer life spreads the same cost across more periods, lowering the annual charge. I’d find that more persuasive for durable software than for functionality already approaching replacement. Abandonment or obsolescence can also bring the expense forward: internal-use assets can require impairment under the applicable long-lived-asset rules, while external-use software is subject to a net-realizable-value limit.^[2]

Movements into and out of the balance sheet (acquisitions and disposals) are normally treated separately. Additions in excess of amortization result in a buildup of deferred costs (including development costs). The presence of this buildup indicates that current period revenue was generated by development costs. Spending on development is normally expensed in the period in which it occurs. The spending is either expensed, represented by a reduction in the balance, or it is waiting to be spent, which is reflected on the balance sheet.^[2][3]

Replace the expense timing, not the company’s reporting

Picture me in an imagined comparison session, with two filings open and a spreadsheet column labeled “better margin.” One company’s development additions are tucked into the property-and-equipment note; the other expenses most development as incurred. I’m annoyed at my own tidy ranking. Before choosing a winner, I replace that column with a bridge showing what each margin actually includes.

Freshworks’ fiscal 2025 filing gives us a reproducible example. It reported $13.205 million of operating income, $18.990 million of capitalized internal-use software costs, and $7.410 million of related amortization. Revenue was approximately $838.8 million. Its software amortization was included in cost of revenue, so it was already reducing reported operating income.^[3]

^[3]

The amortization add-back is $11.580 million, or about 1.38 percentage points of revenue. The add-back of amortization is relevant. The operating income already charges the expenses from prior development, so subtracting current additions would double-count the charges and leave them in both the comparison period and the current period. Here we replace old amortization with current additions. I’d agree that is a useful sensitivity analysis and a check on the prudence of Freshworks’ reporting, but it in no way supports the claim that a peer has identical products, development needs, or investment returns.^[3]

Matching the inputs is the most important consideration. Internal software development costs shouldn’t be grouped with amortization of purchased software or sales commission add-backs. If the disclosures lump those assets and you can’t differentiate the relevant amounts, you can’t determine the adjustment. A related software impairment might also need to be removed. In this case, we would assume that Freshworks opted for immediate expensing. Show that adjustment separately, rather than bury it in amortization.^[2]

Cash follows a separate trail

Don’t include the $18.990 million of additions in a cash calculation. Freshworks capitalized some of its software costs with stock compensation, which creates an asset with no current cash outflow; other payments and accruals might create differences. For earnings you need qualifying total additions. For cash you need actual payments. I’d also keep those separate rather than force a tidy reconciliation that the disclosures don’t support.^[3]

Payments to develop capitalized owned software usually appear in investing cash flow, and payments to develop expensed software usually appear in operating cash flow. Teradata, for example, shows capitalized software payments in its investing activities. Therefore, an operating cash flow comparison may favor a company that capitalizes software more, even if classification has not reduced the total cash outflow. Amortization is a non-cash expense, and is added back to operating cash flows using the indirect method. No one pays for the development a second time because amortization begins.^[2][6]

But not every capitalized implementation payment belongs in investing. When a customer incurs implementation costs for a cloud arrangement that is a service contract, those cash flows follow the hosting fees’ classification, generally operating. That’s why I’d check what the asset represents before drawing a conclusion from a line labeled “software” or “implementation.” The label alone won’t settle it.^[5]

For Freshworks’ historical example, I’d carry both the reported 1.57% margin and the 0.19% sensitivity into a peer comparison. Then I’d investigate the remaining differences: development scope, adoption status, useful lives, and whether the software is still earning its keep. If an apparent profitability advantage disappears after the timing adjustment, I wouldn’t credit it to operating efficiency without additional evidence.^[3]