Accounting for AI Companies: R&D Costs, Cloud Compute, Revenue Recognition & Why Human Review Still Matters 

Introduction

If you are building an AI company in 2026, your product may be cutting-edge. Your books almost certainly are not.

Most AI founders treat accounting as a task they will deal with later. The problem is that financial decisions made in the first two to three years create compounding consequences: misfiled R&D credits, misstated revenue, a chart of accounts that cannot separate training costs from production costs, and financial statements that make investors squint during due diligence.

Standard US GAAP was not designed with AI companies in mind. The rules that govern research costs, software development, revenue from subscriptions, and cloud infrastructure were written for a different era. They still apply, but applying them to model training, token-based billing, GPU fleets, and milestone-based enterprise contracts requires a level of judgment that generalist bookkeepers and automated accounting platforms are not equipped to deliver.

This guide works through the four areas where AI companies face the greatest accounting complexity: R&D cost classification, cloud compute cost treatment, revenue recognition under ASC 606, and the R&D tax credit opportunity under IRC Section 41. It also addresses something many competitors consistently gloss over: why none of this works without a qualified human reviewer who understands how these frameworks intersect.

Countsure works directly with AI companies and technology businesses across the United States, providing outsourced accounting, tax preparation, and financial reporting services built around the real complexity these businesses face.

Key Takeaways

• R&D expense vs. capitalize: Under ASC 730, most AI research costs are expensed as incurred. Capitalization under ASC 350-40 currently requires moving into the application development stage, though ASU 2025-06 (effective for annual periods beginning after December 15, 2027; early adoption permitted) replaces that three-stage model with a simpler trigger: management has authorized and committed to funding the project and completion is probable.
  
• Cloud bills are not one line item: GPU and TPU costs for training belong in R&D expense or on the balance sheet as capitalized development. Inference costs serving paying customers belong in cost of revenue. Lumping them together distorts both your P&L and your gross margin.
  
• ASC 606 is not optional: AI companies using token-based, usage-based, or prepaid-credit pricing models must recognize revenue as performance obligations are satisfied, not when cash is received. Getting this wrong creates restatement risk.
  
• IRC Section 41 is a major opportunity: Cloud compute costs qualify as rental or lease costs of computers under IRC Section 41(b)(2)(A)(iii), making GPU training runs potentially eligible for the R&D tax credit. Many AI companies leave this money on the table.
  
• Form 6765 Section G applies to tax year 2026 returns filed in 2027, not current filings: Pre-profit AI startups using the payroll offset election under IRC Section 41(h), and companies with QREs of $1.5 million or less and gross receipts of $50 million or less claiming on an original return, are generally exempt from completing Section G. For those who do complete it, AI-only platforms are unlikely to produce the required project-level documentation.
  
• OBBBA changes matter for 2026: Section 174A restores immediate R&D expensing, but the accompanying reversion of Section 280C(c) to the pre-TCJA rule means you cannot claim both a full Section 174A deduction and a full Section 41 credit for the same expenditures. You either reduce the 174A deduction by the credit amount, or elect a reduced credit under Section 280C(c). A CPA should model both options before you file.
  
• Multiple frameworks overlap: A single AI development program can simultaneously touch ASC 730, ASC 350-40, ASC 350-30, ASC 985-20, and ASC 606. Applying the wrong one, or only one of them, produces errors.
  
• Human review is not optional: AI accounting tools can accelerate data entry and classification. They cannot make the legal and technical judgments the IRS requires for R&D credit claims, and they cannot evaluate contract modifications under ASC 606 with the nuance an audit demands.
  

Why Standard GAAP Rules Don’t Quite Fit AI Companies

The core challenge for AI accounting is that a single development program can simultaneously involve activities governed by at least four different accounting standards, none of which was designed with machine learning in mind.

When an AI company trains a model, the work might involve data purchased from a third party (governed by ASC 350-30), cloud compute time rented from AWS or Azure (which could fall under ASC 350-40 or ASC 730 depending on purpose), engineering salaries (classified by development phase), and software embedded in a product the company will eventually sell (potentially governed by ASC 985-20). The revenue that results from that product sits under ASC 606.

Getting the classification right at each stage requires a clear understanding of what the company is actually building, why it is building it, and how the resulting capability will be monetized. Many AI founders cannot answer those questions in accounting terms, which is where accounting problems begin.

The frameworks, briefly:

ASC 730 covers research and development costs. It mandates that R&D expenditures be expensed as incurred, with no capitalization pathway when the purpose of the development is R&D itself.

ASC 350-40 covers internal-use software. Under current guidance, costs in the preliminary project stage are expensed, costs in the application development stage can be capitalized, and post-implementation costs are expensed. Note: ASU 2025-06, effective for annual periods beginning after December 15, 2027 (early adoption permitted), removes this three-stage framework. Under the updated model, capitalization begins when management has authorized and committed to funding the project and it is probable the project will be completed. AI companies should plan for this transition and consider early adoption.

ASC 985-20 covers software that is licensed to customers or deployed on the customer’s side (where the customer takes control of the software). It does not apply to AI products delivered as hosted services or API access, where the customer never takes possession of the underlying software. Those arrangements are internal-use software under ASC 350-40. Most costs under ASC 985-20 are expensed until technological feasibility is achieved, which in practice occurs very late in the development cycle.

ASC 350-30 covers general intangibles, including data assets acquired from third parties.

ASC 606 governs revenue recognition across all customer contracts.

These do not replace each other. They coexist, and the right treatment for any given cost depends on the nature and purpose of the work, not on a simple label the company assigns to a budget line.

How Should AI Companies Account for R&D Costs?

What Counts as R&D Under ASC 730?

Under ASC 730, research and development includes any planned search or critical investigation aimed at discovering new knowledge, and any translation of that knowledge into a new or improved product, service, process, or technique. The operative word is “planned.” If your team is running experiments with no guaranteed outcome, that work is almost certainly R&D under US GAAP.

For AI companies, this typically covers early-stage model experimentation, architecture selection, training runs conducted to test capability hypotheses, data labeling and annotation for training purposes, and model evaluation before a decision to productize.

All of these costs are expensed as incurred under ASC 730. There is no capitalization pathway, regardless of how large the investment is or how confident the team is that it will succeed. This is a point that many AI founders find counterintuitive: spending five million dollars on GPU training for a research-stage model produces no asset on your balance sheet under GAAP.

When Can You Capitalize AI Development Costs?

Capitalization becomes available when a project transitions from research into committed development for an internal-use product. Under current ASC 350-40 guidance, this is triggered when the project enters the application development stage and it is probable the software will be completed and used as intended. However, ASU 2025-06 (effective for annual periods beginning after December 15, 2027, with early adoption permitted) replaces the three-stage model: capitalization will begin when management has authorized and committed to funding the project and completion is probable, without requiring a formal stage designation. Companies adopting early or planning ahead should update their capitalization policies accordingly.

What that means in practice: engineering time spent building the infrastructure to serve a model already proven to work, integrating a trained model into a hosted service or API, or developing the delivery layer for the AI capability can potentially be capitalized. This applies whether the product is internal or customer-facing, as long as the customer accesses the capability through a hosted interface and does not receive or control the underlying software. Such products are internal-use software under ASC 350-40, not ASC 985-20.

The transition is not automatic. It requires a documented determination that the project has crossed from preliminary investigation into committed development. Finance and engineering teams need to make this call together, with supporting documentation, because the IRS and external auditors can and do challenge capitalization decisions that lack this foundation.

For software that is licensed to customers or deployed on their side (governed by ASC 985-20), the capitalization trigger is technological feasibility, which in practice typically occurs very late in the development cycle, meaning most costs are expensed. However, most AI companies delivering products as hosted services or API access do not fall under ASC 985-20 at all. Before applying the technological feasibility test, confirm whether ASC 985-20 or ASC 350-40 governs your product.

Which Standard Governs Which Scenario?

This table should sit on your CFO’s desk, not buried in a filing cabinet. Every major spending decision should be mapped to one of these rows before the invoice is coded.

Cloud Compute Costs: The Line Items That Can Make or Break Your Books

Cloud compute is the largest variable cost for most AI companies, and it is consistently one of the most poorly tracked. A single AWS, Azure, or Google Cloud bill in a month of heavy training can contain expenses that belong in R&D, in cost of revenue, in capitalized development, and in general operating expenses, all on the same invoice.

Treating the entire bill as a single operating expense is the default approach for companies without a structured accounting framework. It is also wrong, and the consequences compound over time.

Training vs. Inference: Two Very Different Financial Categories

The single most important distinction in cloud compute accounting for AI companies is the difference between training costs and inference costs.

Training costs are GPU and TPU expenses incurred when building, fine-tuning, or improving a model. If the model being trained is still in the research stage, these costs generally fall under ASC 730 and are expensed as incurred. If the company has crossed into committed application development for an internal-use product, training costs tied to that specific product may be capitalizable under ASC 350-40.

Inference costs are GPU expenses incurred when serving predictions to paying customers in production. These are not R&D costs. They are the direct cost of delivering your product or service. Under GAAP, they belong in cost of revenue, which directly affects your gross margin calculation.

Investors, lenders, and acquirers all look at gross margin. An AI company that accidentally books inference costs as operating expenses appears to have better margins than it actually does. This is not a rounding error. It is a material misstatement that creates problems in due diligence and, once corrected, tends to require a conversation no founder wants to have.

How to Split and Tag Your Cloud Bills

The practical solution is a tagging policy that your engineering team applies to every workload before it is provisioned. Each cloud resource should be tagged with at minimum: project name, development stage (research, development, production), and cost category (training, inference, storage, dev environment).

This is not an accounting task. It is an engineering operations discipline that finance teams must request and then verify monthly. Most AI companies do not have this in place, which means their accountants are making educated guesses at month-end rather than coding from documented evidence.

A clean chart of accounts for an AI company might include separate lines such as the following:

Cloud Compute: Model Training (R&D Expense), Cloud Compute: Inference and Production Serving (Cost of Revenue), Cloud Compute: Development Environments (Operating Expense), Capitalized Model Development Costs (Balance Sheet, Intangible Asset).

The detail that goes into those categories changes your income statement, your balance sheet, and your R&D tax credit calculation all at once. This is why sloppy cloud bill management is never just a bookkeeping inconvenience.

Hardware, GPUs, and ASC 360

When an AI company purchases GPU hardware outright, that hardware is capitalized as property and equipment under ASC 360 and depreciated over its useful life, typically three to five years.

Cloud compute arrangements may also require analysis under ASC 842 if the contract gives the company the right to control identified physical assets. Many AI companies with long-term cloud capacity reservations have embedded lease obligations they have never identified.

Data Acquisition and Licensing: An Overlooked Accounting Complexity

The training data a company acquires is one of its most significant assets, but many AI companies do not treat it as one on their balance sheet.

Data purchased from a third-party vendor for a specific identified purpose may qualify as an intangible asset under ASC 350-30, subject to amortization over its useful life. Data generated internally through labeling, annotation, or user interactions is generally expensed as incurred.

Externally acquired data that sits on the balance sheet as a capitalized intangible affects your asset base, your reported net worth, and potentially your 409A valuation. If that same data is expensed, it reduces reported profits in the period of acquisition and disappears from the balance sheet entirely.

There is a further complication: if data is acquired for a model still in the R&D stage under ASC 730, the acquisition costs may be treated as R&D expense rather than capitalized, regardless of whether the data meets the ASC 350-30 criteria. The purpose of the model determines the accounting treatment of its inputs. This conclusion requires a technical accounting determination, not a spreadsheet judgment call.

Revenue Recognition for AI Companies: The ASC 606 Challenge

Revenue recognition is where AI company accounting gets genuinely complex. ASC 606, the five-step revenue recognition framework under US GAAP, was designed for contract-based revenue relationships. AI companies frequently operate under pricing models that strain every step of that framework.

The ASC 606 Five-Step Framework for AI Companies

Step 1 is identifying the contract with a customer. For AI companies, this means evaluating whether a terms-of-service click-through constitutes a contract, how to handle usage agreements with enterprise clients that include performance milestones, and whether a prepaid credit purchase creates a contract at inception.

Step 2 is identifying the performance obligations in the contract. An AI company might promise access to a model, a certain number of API calls, a specific response-time SLA, and ongoing model improvements. Each of these may constitute a separate performance obligation that must be evaluated individually before revenue is allocated.

Step 3 is determining the transaction price. This is where token-based and usage-based pricing creates real complexity. When a customer pays upfront for a pool of usage credits, the transaction price is not simply the amount paid. It is the amount the company expects to earn, adjusted for the probability that some credits will never be used (breakage), the variability of consumption, and any constraints under the significant-reversal guidance in ASC 606-10-32-11 through 32-13.

Step 4 is allocating the transaction price to performance obligations. If a contract includes both a seat-based subscription and API call overage fees, those components must be separated and the transaction price allocated to each based on standalone selling prices.

Step 5 is recognizing revenue when each performance obligation is satisfied. For AI companies, this typically means recognizing revenue as the customer consumes the service, not when they pay for it.

This creates a direct operational challenge: AI companies must track consumption in real time, maintain accurate deferred revenue balances, and apply variable consideration estimates consistently across periods. For a company without robust revenue operations tooling and a qualified accountant reviewing the outputs, this is where the books start to diverge from reality.

For a deeper look at how ASC 606 applies specifically to AI companies, the Countsure guide on ASC 606 for AI companies walks through the performance obligation and variable consideration questions in detail.

What Usage-Based and Token-Based Pricing Means for Your Books

The shift from flat-rate subscriptions to token-based or usage-based pricing is one of the most significant accounting changes facing AI companies. Under a traditional annual SaaS subscription, revenue recognition is comparatively mechanical: recognize one-twelfth of the contract value each month.

Under a token-based model, where a customer pays $0.002 per API call, cash in the bank does not mean revenue earned. Revenue is earned only as the customer consumes the service. If a customer loads $5,000 in prepaid credits and uses $1,800 in the first month, you recognize $1,800 in month one, regardless of when the payment arrived.

For early-stage AI companies with limited consumption history, estimating usage patterns for variable consideration purposes requires judgment that many accounting platforms cannot apply automatically. The risk of significant reversal must be assessed for each estimation method, and that assessment changes as more data becomes available.

Prepaid Credits, Minimum Commitments, and Contract Modifications

Contract modifications deserve special attention. When a customer upgrades from a pilot to production, adds seats, or renegotiates pricing, ASC 606 requires an evaluation of whether the modification is a separate contract, a prospective modification, or a cumulative catch-up adjustment. Getting this wrong produces restatable revenue, which is the kind of thing that surfaces during a Series B due diligence review and cannot be quickly explained away.

The R&D Tax Credit Opportunity Under IRC Section 41

The R&D tax credit is one of the most valuable tax incentives available to AI companies, and it is one of the most consistently underutilized. Under IRC Section 41, companies that conduct qualified research activities can claim a dollar-for-dollar credit against their federal tax liability.

For a company with zero tax liability (common for early-stage AI businesses losing money), eligible startups can elect to offset up to $500,000 per year in payroll taxes instead, including FICA. This is cash in hand during a period when cash is everything.

What Qualifies as a Qualified Research Expense for AI Companies?

The IRS applies a Four-Part Test to determine whether research activities qualify. The work must have a permitted purpose (developing a new or improved business component), involve technological uncertainty, be conducted through a process of experimentation, and be technological in nature.

AI development satisfies this test remarkably well. Training models to test capability hypotheses, iterating on architectures to resolve performance uncertainty, and running controlled experiments to evaluate alternative approaches are precisely the activities Section 41 was designed to reward.

Qualified research expenses (QREs) for AI companies can include:

Wages paid to machine learning engineers, data scientists, software engineers, and researchers who spend time on qualifying activities. These are typically the largest component of any R&D credit claim.

Supplies used in the research process.

Contract research expenses paid to third parties who conduct qualifying research under your direction.

Cloud computing costs, which the IRS classifies as rental or lease costs of computers under IRC Section 41(b)(2)(A)(iii) and Treasury Regulation Section 1.41-2(b)(4). GPU training runs on AWS, Azure, or Google Cloud qualify as QREs when they are directly attributable to qualifying research activities.

Cloud Compute as a Qualified Research Expense

The inclusion of cloud compute as a QRE is one of the most important developments in R&D tax credit practice for AI companies. A company spending $500,000 per month on GPU training can potentially include a significant portion of that in its QRE calculation, producing a credit that directly offsets tax or payroll liability.

The qualification requirement is that the compute must be directly attributable to qualifying research, not to production inference or general business use. This brings us back to the tagging discipline discussed earlier: if you cannot separate training compute from production compute in your cloud bills, you cannot accurately compute the QRE.

This is not a hypothetical problem. Many AI companies have cloud bills that are unsegregated by purpose, which means their R&D credit claims either leave money on the table by excluding cloud costs entirely, or they include too much and create audit exposure. Neither outcome is acceptable.

The OBBBA Change and Form 6765 Section G in 2026

The One Big Beautiful Bill Act restored immediate expensing for domestic R&D under Section 174A, beginning in 2025. AI companies can now fully deduct qualifying R&D expenditures in the year incurred, rather than amortizing them over five years as was required from 2022 through 2024. However, OBBBA also reverted Section 280C(c) to the pre-TCJA rule, which creates an important constraint: you cannot claim both a full Section 174A deduction and a full Section 41 credit for the same expenditures. In practice, you either reduce your 174A deduction by the amount of the credit, or make a reduced-credit election under Section 280C(c). Which approach produces a better outcome depends on your effective tax rate and projected taxable income. A CPA should model both scenarios before you file.

For smaller AI businesses, there is also a retroactive opportunity worth reviewing: companies with average annual gross receipts of $31 million or less were eligible under OBBBA to apply the Section 174A immediate expensing rules retroactively to tax years 2022 through 2024 by amending prior returns. The general deadline for those amended returns was July 6, 2026, which has now passed. If your business qualified and did not file by that date, consult a tax professional about whether the statute of limitations on those years is still open and any remaining options.

Form 6765 Section G transitions from optional to required starting with tax year 2026. Returns covering tax year 2025, which are the returns currently being filed, do not yet require Section G. Importantly, certain filers are exempt even after Section G becomes mandatory for tax year 2026 returns. Businesses that elect the payroll offset under IRC Section 41(h) are not required to complete Section G. Neither are businesses with QREs of $1.5 million or less and gross receipts of $50 million or less, provided the credit is claimed on an original return rather than an amended one. Many pre-profit AI startups using the payroll offset fall into the exempt category, so confirm your filing status before building Section G compliance infrastructure around a requirement that may not apply to you.

For filers who do complete Section G, it requires documenting each business component, describing the qualifying research activities, identifying the employees involved, and breaking down their time between direct research, supervision, and support. AI-driven tax platforms that compute the R&D credit through a questionnaire-based workflow are typically not producing this level of documentation. Regardless of what tools are used to compute the credit, the taxpayer bears full responsibility for the accuracy of the claim on examination. The use of an automated platform does not shift that risk or provide insulation from IRS scrutiny.

For more on how income tax provisions interact with these credit calculations, the Countsure guide on ASC 740 income tax provisions covers the accounting treatment for temporary differences and deferred tax assets that arise from R&D credit claims.

The Payroll Offset Benefit for Qualifying Startups

AI companies that are pre-revenue or pre-profit can still benefit from the R&D credit through the payroll offset election under IRC Section 41(h). Qualifying startups (generally, companies with less than five years of gross receipts and less than $5 million in gross receipts in the credit year) can elect to apply up to $500,000 per year of their R&D credit against their Federal Insurance Contributions Act (FICA) payroll taxes.

This is a meaningful cash benefit. A 10-person AI team with a combined payroll of $1.5 million in annual salaries can generate a payroll tax liability in the range of $115,000 on the employer side. If the R&D credit exceeds that amount, the full payroll offset is used, and excess credits carry forward.

Many AI founders are unaware this option exists. Many who are aware of it are not claiming it because their bookkeeping systems do not track the labor cost by research activity in sufficient detail to support the credit calculation.

Stock-Based Compensation and Other AI Company Complexities

AI companies compete for talent in one of the tightest labor markets in the world, making equity compensation a central tool. Under ASC 718, stock options, restricted stock units, and other share-based awards must be measured at fair value on the grant date and recognized as compensation expense over the vesting period.

For AI companies issuing options, this requires a 409A valuation at each grant cycle to establish the fair market value of the company’s common stock. A company that grants options without a current valuation creates both tax risk for employees and an ASC 718 compliance problem for the company.

Engineering headcount in AI companies is typically concentrated in roles that touch qualifying R&D activities. For Section 41 purposes, the relevant measure is taxable W-2 wages, not ASC 718 book expense. This distinction matters for equity compensation: nonqualified stock option (NSO) exercises generate taxable W-2 income and can be included in the QRE wage base. Incentive stock option (ISO) exercises generally do not generate W-2 income at exercise and are therefore excluded from QREs unless a disqualifying disposition occurs. Payroll records and tax data, rather than the stock compensation ledger, drive the wage component of an R&D credit claim.

Why Human Review Still Matters (Maybe More Than Ever)

There is a certain irony in an AI company relying on AI tools to manage its own accounting. Automated bookkeeping platforms are genuinely useful for transaction processing, bank reconciliation, and basic financial statement generation. They are not equipped to make the legal and technical judgments that determine whether a research activity qualifies under IRC Section 41, which accounting standard applies to a given AI spend scenario, whether a contract modification under ASC 606 should be treated as a new contract or a prospective adjustment, or whether a capitalization determination is defensible under GAAP.

As the article on AI in accounting and outsourcing discusses, automation accelerates data processing, but it does not replace the interpretive judgment that accounting professionals apply to complex financial situations.

What Form 6765 Section G Requires That AI Cannot Deliver

The mandatory Form 6765 Section G requirement for 2026 is perhaps the clearest demonstration of why human review cannot be eliminated from AI company accounting. Section G asks taxpayers to document each business component for which they are claiming the credit, describe the qualified research activities conducted in connection with that component, identify the employees involved, and break down their time between direct research, supervision, and support.

Completing this accurately requires someone who understands both what the IRS is looking for under the Four-Part Test and what the engineering team was actually doing. AI-driven tax platforms that compute the R&D credit from a questionnaire typically cannot produce this documentation without a qualified preparer reviewing the project descriptions, interviewing the relevant technical staff, and applying professional judgment about whether each activity meets the prong-by-prong requirements.

Regardless of what tools are used to compute the credit, the taxpayer bears full responsibility for the accuracy of the claim on examination. The use of an automated platform does not transfer that risk, provide a reasonable-cause defense, or insulate the taxpayer from penalties if the IRS challenges and disallows the credit.

The Judgment Calls That Only a CPA Can Make

Beyond the R&D credit, there are accounting decisions across every major area of AI company finance that require human judgment:

Determining which development stage a project has reached under ASC 350-40.

Evaluating whether a cloud contract creates an embedded lease under ASC 842.

Assessing whether the significant-reversal constraint applies to a usage-based revenue estimate under ASC 606.

Deciding how to treat data purchased from a third-party licensor under ASC 350-30 when the data is used across multiple models.

Structuring a chart of accounts that simultaneously supports the R&D credit, COGS separation, deferred revenue tracking, and capitalized intangible asset accounting.

These are not decisions that can be automated, nor decisions that should be made by a generalist bookkeeper unfamiliar with an AI company’s cost structure.

The Countsure team brings together CPAs with US GAAP training, experience with technology company financial reporting, and familiarity with the specific accounting issues AI businesses face. For AI companies looking to build accounting infrastructure that scales, the earlier a qualified team is engaged, the less expensive the corrections.

Common Accounting Mistakes AI Companies Make

Treating the entire cloud bill as an operating expense. This collapses training costs (R&D), inference costs (COGS), and development environment costs (operating) into a single line. The result is an inaccurate income statement and a missed R&D credit opportunity.

Recording prepaid credits as revenue at payment. When a customer purchases a block of usage credits, cash arrives upfront. Under ASC 606, it is a contract liability (deferred revenue), recognized only as the customer consumes the service.

Failing to document the capitalization trigger. Under current ASC 350-40 guidance, this requires a documented determination that the project has moved from the preliminary stage into application development. Under ASU 2025-06 (effective after December 15, 2027; early adoption permitted), the trigger shifts to management authorization and committed funding with probable completion. Either way, a contemporaneous written record is essential. Without it, the capitalization decision is not defensible under audit.

Missing the Section 41 payroll offset election deadline. The election to apply R&D credits against payroll taxes must be made on a timely filed original tax return. Companies that discover this benefit after the return is filed may lose the payroll offset for that year.

Using an outdated 409A valuation for option grants. Options granted on an outdated 409A can create below-market pricing issues that trigger adverse tax consequences under IRC Section 409A for employees, compounding the ASC 718 expense problem on the company side.

Not evaluating contract modifications under ASC 606. Pilots converting to production agreements, renegotiated pricing, and usage tier changes all require evaluation under ASC 606. Many AI companies record modifications without analysis, accumulating a deferred revenue balance that does not reflect actual obligations.

Conclusion: Getting AI Accounting Right Requires Human Precision

The accounting complexity facing AI companies plays out in financial statements that investors scrutinize, tax returns the IRS can examine, and due diligence packages that acquirers review. Getting it wrong creates restatements, missed credit opportunities, audit exposure, and the kind of surprises that stall fundraising rounds.

ASC 730, ASC 350-40, ASC 606, and IRC Section 41 collectively provide a comprehensive foundation for managing AI company finances. GAAP, even if it was not designed with AI in mind, can be applied to AI development costs and revenue models with the right structure and expertise.

What no amount of automation can replace is the judgment required to apply these standards correctly to a real AI company’s cost structure and revenue model. That requires a qualified CPA who understands both the accounting standards and the business.

Countsure provides outsourced accounting, tax preparation, financial reporting, and R&D credit support to AI companies and technology businesses across the United States. Whether you are building your accounting infrastructure from scratch, correcting a classification problem discovered in due diligence, or preparing for your first external audit, our team is built to handle the complexity AI companies generate.

Get in touch with our team to start building an accounting foundation your business can grow on.

Frequently Asked Questions

1. What is the difference between ASC 730 and ASC 350-40 for AI companies?

ASC 730 governs research and development costs and requires that all R&D expenditures be expensed as incurred, with no capitalization pathway. ASC 350-40 governs internal-use software development and allows capitalization of direct costs once a project moves into the application development stage under current guidance. Note that ASU 2025-06 (effective for annual periods beginning after December 15, 2027, with early adoption permitted) will replace the three-stage model with a simpler authorization-and-commitment trigger. Companies should monitor this transition. For AI companies, the key question is whether work constitutes R&D under ASC 730 or committed development of an internal-use product under ASC 350-40. The same program can move between frameworks as it progresses.

2. Can AI companies capitalize model training costs?

It depends on the purpose, development stage, and delivery model of the product. If training is conducted to test capabilities or explore architectures, costs are expensed under ASC 730. If training supports a committed development project for an internal-use product, some costs may be capitalizable under ASC 350-40. For products delivered as hosted services or API access, the standard is ASC 350-40 (internal-use software), not ASC 985-20. ASC 985-20 applies only when the software is licensed to or deployed on the customer’s side. Under current ASC 350-40 guidance, capitalization requires reaching the application development stage; under ASU 2025-06 (effective after December 15, 2027), the trigger will shift to management authorization and committed funding.

3. How does ASC 606 apply to AI companies selling usage-based or token-based products?

Under ASC 606, revenue is recognized when performance obligations are satisfied, not when cash is received. For usage-based and token-based models, this means revenue is recognized as the customer consumes the service. Prepaid credits create contract liabilities (deferred revenue) that are reduced as credits are used. Variable consideration, including estimated usage and breakage, must be evaluated against the significant-reversal constraint to determine how much revenue can be recognized in each period.

4. Do GPU training costs qualify for the R&D tax credit under Section 41?

Yes, generally. Under IRC Section 41(b)(2)(A)(iii), amounts paid for the right to use computers in the conduct of qualified research qualify as qualified research expenses. The IRS and Treasury Regulation Section 1.41-2(b)(4) have applied this provision to cloud computing costs, including GPU and TPU time rented from providers such as AWS, Azure, and Google Cloud. The compute must be directly attributable to qualifying research activities, and the research itself must pass the IRS Four-Part Test.

5. What changed for AI company R&D credits in 2026?

Two significant changes apply in 2026. First, OBBBA restored immediate expensing for domestic R&D under Section 174A, reversing the five-year amortization requirement that applied from 2022 through 2024. However, OBBBA also reinstated the pre-TCJA version of Section 280C(c), which prevents claiming both a full Section 174A deduction and a full Section 41 credit for the same expenditures. You either reduce the 174A deduction by the credit amount, or elect a reduced credit under Section 280C(c). Which approach is more beneficial depends on your effective tax rate; a CPA should model both. Second, Form 6765 Section G becomes mandatory for tax year 2026 returns (filed in 2027), though businesses using the payroll offset election and those with QREs of $1.5 million or less and gross receipts of $50 million or less are generally exempt.

6. What is the payroll tax offset benefit for AI startups?

Under IRC Section 41(h), qualifying small businesses can elect to apply their R&D credit against their employer Federal Insurance Contributions Act (FICA) payroll tax liability, up to $500,000 per year. A qualifying business generally has less than five years of gross receipts and less than $5 million in gross receipts in the credit year. This benefit is particularly valuable for pre-profit AI companies that have significant R&D activity but no income tax liability against which to offset the credit directly.

7. Why can’t an AI-only accounting or tax platform handle all of this?

AI-driven accounting and tax platforms are effective at processing transactions, generating schedules, and producing first drafts of calculations. They are not equipped to make the legal and technical judgments required to determine whether a research activity qualifies under the IRS Four-Part Test, evaluate which accounting standard applies to a given AI spend scenario, assess the significant-reversal constraint for variable consideration under ASC 606, or produce the project-level narrative documentation that Form 6765 Section G requires. Regardless of which tools are used to compute the credit, the taxpayer bears full responsibility for the accuracy of the claim on examination. The use of an automated platform does not transfer that risk or provide insulation from IRS scrutiny.

8. When should an AI company engage an outsourced accounting firm?

As early as possible, and certainly before the first significant fundraise. The capitalization decisions, revenue recognition policies, R&D credit documentation practices, and chart of accounts structure put in place at the seed stage create the financial reporting foundation that investors, auditors, and lenders evaluate at every subsequent stage. Correcting misclassifications retroactively is significantly more expensive than establishing the right structure from the outset. Most AI companies that engage a specialized accounting team after discovering a problem in due diligence wish they had engaged earlier.

Related Blogs

• Outsourcing Accounting for Startups and CPA Firms: A Complete Guide
  
• A Beginner’s Guide to Understanding US GAAP and Why It’s Essential for Financial Reporting
  
• Best Practices for Consistent and Transparent Financial Reporting