The single largest line on an autonomy developer's income statement is usually research and development, and the accounting choice behind it shapes how the whole business reads. Under U.S. GAAP, research and development costs are expensed as incurred: the cash spent building a self-driving stack is recognized as an expense in the period it is spent, not parked on the balance sheet as an asset and written off slowly over later years. The practical effect is that a pre-revenue autonomy company reports large, recurring losses that map almost one-to-one to how fast it is burning cash on engineering, and it carries no internally generated R&D asset that a future write-down could threaten.

The contrast that matters is capitalization. Software development costs can, in narrow circumstances, be capitalized rather than expensed once a project clears a threshold: technological feasibility for software to be sold, or the application-development stage for internal-use software, at which point future economic benefit is judged probable. Capitalized costs then sit on the balance sheet and amortize over the product's useful life. The decision is not cosmetic. Capitalizing pulls cost off the current income statement and spreads it forward, flattering near-term operating results; expensing front-loads the pain. So when an autonomy company that has spent years and billions on a driving system still expenses everything, it is implicitly telling you the product has not crossed the line where GAAP would let it record an asset.

Research and development costs are expensed as incurred, and consist primarily of personnel costs, hardware and electrical engineering prototyping, cloud computing, data labeling, and third-party development services. To date, the Company has not capitalized software development costs related to the continued development and commercialization of the Aurora Driver at scale.— Aurora Innovation, Inc. (AUR), Form 10-K for fiscal year 2025, source

What the policy reveals about an autonomy filer

Aurora Innovation (AUR), the self-driving-truck developer behind the Aurora Driver, makes the point in its 2025 Form 10-K. It reports research and development expense of $745 million for the year ended December 31, 2025, and states plainly that it has not capitalized software development costs for the Aurora Driver. Read against the company's stage, that is a coherent disclosure: a developer still scaling toward commercial driverless operations has not reached the accounting threshold that would let it treat its software spend as a long-lived asset, so the entire $745 million lands on the income statement. An investor reconciling Aurora's losses to its strategy can take that R&D figure as a fairly direct measure of the engineering effort consumed in the period, without worrying that capitalized costs are hiding burn off-statement.

The reason expensing dominates the sector is structural. Research and development for an autonomous driving system is, almost by definition, uncertain: the work is aimed at a capability that has not yet been proven to operate at scale, and GAAP's bar for capitalizing development cost requires probable future benefit and an established feasibility or application-development stage. For a company whose core product is still being validated on public roads, that bar is hard to clear, which is why personnel, prototyping hardware, cloud compute, and data-labeling costs are run straight through the P&L. The corollary is that two autonomy companies spending identical amounts on engineering will report identical R&D-driven losses only if both expense; if one capitalizes a slice of its software cost, its near-term operating loss looks smaller for an accounting reason, not an economic one.

It helps to separate the two kinds of software cost the standards treat differently. Software a company develops to sell, lease, or otherwise market is governed by one model, under which costs are expensed until technological feasibility is established and may be capitalized only after that point and before general release. Software a company develops for its own internal use is governed by another model, under which costs in the preliminary project stage are expensed and only costs in the application-development stage may be capitalized. An autonomous driving system can implicate either framework depending on how it is deployed, but both share the same gate: capitalization begins only once the project clears a feasibility or development-stage threshold that signals probable future benefit. A developer that has not crossed that gate expenses everything, which is why a pre-commercial autonomy company’s entire engineering spend typically runs through the income statement.

How to read it in a filing

The accounting policy lives in the notes to the financial statements, usually under a "Research and development" or "Software development costs" heading in the summary of significant accounting policies. Three things are worth checking. First, the policy sentence itself: "expensed as incurred" is the default; any language about capitalizing internal-use or to-be-sold software is the exception worth flagging. Second, the dollar figure: the annual R&D expense, read against headcount and prior years, is the cleanest available proxy for the pace of development spend. Third, consistency with stage: a company describing itself as pre-commercial that suddenly begins capitalizing software costs has made a judgment that the product is closer to generating revenue, and that judgment changes how its margins will print going forward. None of this is advice about the stock; it is how to make the engineering spend in an autonomy filing reconcile to a filed number rather than a slide.

The takeaway for reading the autonomy money story is narrow and durable. Expensing R&D as incurred is the norm across self-driving developers, it means reported losses track engineering burn closely, and it leaves no R&D asset on the balance sheet. A capitalization policy is the exception, and where it appears it signals a company's own conclusion that its software has crossed from research into a probable future benefit. Either way, the policy note, not the keynote, is where the spend reconciles.