How Do You Book a Capitalized Software Journal Entry

Key Takeaways

• Under US GAAP (ASC 350-40), internal-use software costs are capitalized only during the application development stage, the middle of three stages; costs in the preliminary project stage and the post-implementation/operation stage are expensed as incurred.
• Under IFRS (IAS 38), development costs are capitalized once six specific criteria are met, including technical feasibility and probable future economic benefit; research costs are always expensed.
• The capitalization entry debits a software asset account (Capitalized Software, an intangible or fixed asset) and credits cash, accounts payable, or accrued payroll, depending on the cost type.
• Amortization begins once the software is substantially complete and ready for its intended use, not when the capitalization entry is first recorded, and runs on a straight-line basis over the asset’s estimated useful life (commonly 3 to 7 years, a judgment call finance teams should document).
• Cloud and SaaS hosting arrangement implementation costs are capitalized under a related but distinct part of ASC 350-40 (as updated by ASU 2018-15), presented outside the software intangible asset and amortized over the hosting contract term instead of a separately estimated useful life.
• The most common mistakes are capitalizing training or post-go-live maintenance costs, delaying the amortization start date past the in-service date, and applying ASC 985-20 (software to be sold, leased, or marketed) rules to what is actually internal-use software.

Booking a capitalized software journal entry looks straightforward on the surface: debit an asset, credit cash. In practice, most of the work happens before the entry is ever recorded, in correctly identifying which development stage a cost belongs to and which standard governs the project in the first place.

Internal-use software (the system your own finance, operations, or engineering teams use to run the business) falls under ASC 350-40 in US GAAP and IAS 38 in IFRS. Software your company develops to sell, lease, or market to customers as a standalone product falls under a different, narrower standard, ASC 985-20, which this article touches on only briefly since it is not the focus here. Getting that classification wrong at the outset cascades into every entry that follows.

A quick overview: this article walks through what qualifies as capitalized software under ASC 350-40 and IAS 38, the three stages of internal-use software development and what to capitalize at each, the journal entries for recording capitalization and subsequent amortization with worked examples, how cloud and SaaS hosting implementation costs are treated differently, and the mistakes that most often need correcting after the fact.

What Qualifies as Capitalized Software Under ASC 350-40 and IAS 38

Not every dollar spent on software development qualifies for capitalization. Both frameworks start from the same underlying idea, that only costs tied to creating a probable future economic benefit belong on the balance sheet, but they express the test differently.

• ASC 350-40 (US GAAP, internal-use software): Costs qualify for capitalization only once the project has moved past the preliminary planning stage, management has authorized funding, and it is probable the project will be completed and used to perform its intended function. Internal-use means the software is not intended to be sold, leased, or marketed externally.
• IAS 38 (IFRS, intangible assets): Development costs qualify for capitalization only when the entity can demonstrate all of the following: technical feasibility of completing the asset, intention to complete it, ability to use or sell it, how it will generate probable future economic benefits, availability of adequate technical/financial/other resources to complete development, and the ability to reliably measure the expenditure attributable to the asset during development. Research costs (the earlier, more exploratory phase) are always expensed as incurred under IFRS, with no exception.
• ASC 985-20 (US GAAP, software to be sold, leased, or marketed): This is a separate, narrower standard for software your company develops as a product for external customers. It uses a different trigger point (technological feasibility) and different capitalization mechanics. If your project is customer-facing product software rather than an internal system, ASC 985-20 governs it instead of ASC 350-40, and the entries below should not be applied without adjusting for that standard.

Costs that typically qualify for capitalization (once the relevant stage/criteria test is met):

• External direct costs: Fees paid to third-party developers, consultants, or contractors, and the purchase price of software licenses or code acquired from a vendor.
• Payroll and payroll-related costs: Compensation and benefits for employees directly associated with, and who devote time directly to, the development project (a project manager, developers, and QA staff working on the build, for the hours actually spent on it).
• Interest costs: Capitalized interest on funds borrowed to finance the development project, where material, following the same interest capitalization guidance applied to other qualifying self-constructed assets.

Costs that do not qualify, regardless of stage:

• General and administrative costs and overhead not directly attributable to the project.
• Training costs for end users.
• Data conversion costs (other than the costs to make old data usable by the new system, which have their own narrow treatment).
• Costs incurred after the software is substantially complete and ready for its intended use.

The Three Stages of Internal-Use Software Development and What to Capitalize at Each

ASC 350-40’s central organizing idea is that internal-use software development moves through three stages, and the capitalization rule flips depending on which stage a cost was incurred in. IAS 38 does not use the same three-stage labels, but the practical effect (expense early-stage costs, capitalize once the project clears defined recognition hurdles) lands in a similar place.

• Stage 1, Preliminary Project Stage: Conceptual formulation of alternatives, evaluating alternatives, determining existence of needed technology, and final selection of alternatives. All internal and external costs incurred here are expensed as incurred, because the project has not yet been authorized and it is not yet probable it will be completed and used as intended.
• Stage 2, Application Development Stage: Design of the chosen path, including software configuration and interfaces; coding; installation of hardware; and testing, including parallel processing. This is the stage where qualifying external direct costs, directly-associated payroll costs, and applicable capitalized interest are recorded as an asset rather than an expense. Capitalization in this stage begins once the preliminary project stage is complete and management has committed to funding the project, and it ends when the software is substantially complete and ready for its intended use.
• Stage 3, Post-Implementation/Operation Stage: Training and application maintenance. All costs here are expensed as incurred, including data conversion costs (with narrow exceptions), user training, and ongoing maintenance once the software is live.

One nuance worth flagging explicitly: subsequent upgrades or enhancements that add genuinely new functionality are evaluated against this same three-stage test again, as if they were their own smaller project. Routine bug fixes and patches that do not add functionality are expensed, not capitalized, even though they technically happen “during” what looks like an application development effort.

The Journal Entry to Record Capitalized Software Costs

Once costs are confirmed to fall in the application development stage (or meet the IAS 38 development-cost criteria), they get recorded to a software asset account instead of an expense account. The credit side depends on how the cost was actually incurred: cash paid directly, a payable recorded for a vendor invoice not yet paid, or accrued payroll for internal developer time.

Illustrative example (for illustration only, not a real transaction): A company is building an internal order-management system. During the application development stage in a given month, it incurs $150,000 in third-party developer fees (paid by wire) and $80,000 in payroll costs for internal engineers who worked directly on the build (recorded as accrued payroll, not yet paid).

The entries:

• Debit: Capitalized Software Asset (Internal-Use Software) - $150,000
• Credit: Cash — $150,000

(recording the third-party development fee)

• Debit: Capitalized Software Asset (Internal-Use Software) - $80,000
• Credit: Accrued Payroll Liability - $80,000

(recording directly-associated internal payroll costs incurred during the application development stage)

If the same company had also incurred, in that same period, $12,000 of planning and needs-assessment costs still in the preliminary project stage, that $12,000 would not appear in either entry above. It is expensed directly:

• Debit: Software Planning Expense (Preliminary Project Stage) - $12,000
• Credit: Cash / Accounts Payable - $12,000

Under IAS 38, the mechanics of the capitalization entry are the same (debit an intangible asset, credit cash/payables/accrued payroll), the difference is upstream, in confirming all six IAS 38 development criteria are met before the debit is recorded at all, rather than confirming which of the three ASC 350-40 stages the cost falls in.

The Journal Entry for Amortizing Capitalized Software

Amortization begins when the software is substantially complete and ready for its intended use, which is not necessarily the same date the last capitalization entry was posted, and is often earlier than the date every planned feature has shipped. Both ASC 350-40 and IAS 38 require straight-line amortization over the asset’s estimated useful life unless another systematic method better reflects the pattern of economic benefit consumption, though straight-line is by far the most common approach in practice.

Useful life is a judgment call, typically set somewhere in the 3-to-7-year range depending on the software’s expected functional life, the pace of technology change in that system, and company accounting policy. This estimate should be documented and applied consistently, and revisited if facts change materially (a planned system replacement, for instance).

Illustrative example (for illustration only, not a real transaction): Continuing the order-management system above, assume total capitalized costs of $1,200,000 were recorded by the time the software went live, and the company’s policy sets a 5-year useful life with no residual value. Monthly straight-line amortization is $1,200,000 ÷ 5 years ÷ 12 months = $20,000 per month.

• Debit: Amortization Expense (Capitalized Software) - $20,000
• Credit: Accumulated Amortization, Capitalized Software - $20,000

(monthly amortization entry, recorded from the in-service date through the end of the estimated useful life)

If the software is later determined to be impaired (for example, it is replaced early by a new system and its carrying value exceeds its recoverable amount), the excess carrying value is written off in a separate impairment entry, typically:

• Debit: Impairment Loss, Capitalized Software - [carrying value less recoverable amount]
• Credit: Accumulated Amortization (or directly against the asset) - [same amount]

Impairment testing and the applicable recoverability tests differ in detail between ASC 360 (for long-lived assets held and used, which internal-use software typically falls under) and IAS 36 under IFRS; a technical accounting resource should confirm the specific test and triggering events before this entry is finalized for a real impairment.

How Cloud and SaaS Hosting Implementation Costs Are Treated Differently

A large share of enterprise software today is not internally built and installed on-premise, it is a hosted, cloud-based (SaaS) arrangement where the customer never takes possession of the underlying software. ASC 350-40, as amended, addresses this directly, and the treatment differs from internally-developed on-premise software in a few important ways.

• Scope trigger: This guidance applies when a cloud arrangement is a hosting arrangement that is a service contract (the customer does not obtain the right to take possession of the software running the hosted service, and could not run it on its own infrastructure or a third party’s without significant modification).
• What gets capitalized: Implementation costs incurred during an application development stage analogous to the three-stage framework above, such as configuration, customization, integration with existing systems, and coding, installation, and testing directly tied to standing up the hosted service. Costs incurred during preliminary planning and after the service is ready for its intended use (training, post-go-live support) are still expensed.
• Where it sits on the balance sheet: Unlike internally-developed software, these capitalized implementation costs are not recorded as a software intangible asset. They are presented as a prepaid expense or other asset, reflecting that the company is paying for access to a hosted service, not acquiring software it owns.
• Amortization period: Instead of an independently estimated useful life, the capitalized implementation costs are amortized straight-line over the term of the hosting arrangement, including renewal periods that are reasonably certain to be exercised. This ties the expense recognition period to the contract, not to a separate useful-life judgment.

Under IFRS, cloud/SaaS implementation costs are evaluated under IAS 38 and related interpretive guidance, and the analysis often reaches a similar conclusion, that configuration and customization costs on a hosted arrangement frequently do not meet the definition of a separable intangible asset and are expensed unless they create a distinct asset the entity controls. This is an area with more judgment and more room for divergence between GAAP and IFRS outcomes than the core internal-use software rules, and it should be reviewed against the specific contract terms rather than treated as a blanket rule.

Common Mistakes to Avoid When Capitalizing Software Costs

• Capitalizing post-implementation costs: Training, ongoing maintenance, and minor bug fixes incurred after go-live are Stage 3 costs and should be expensed, not added to the software asset, even when the invoice arrives from the same vendor that built the system.
• Missing the correct amortization start date: Amortization should begin when the software is substantially complete and ready for its intended use, not when the last capitalized invoice is paid, not when a formal “go-live” ceremony happens weeks later, and not delayed to align with a fiscal year boundary.
• Not distinguishing internal-use software from software to be sold: Applying ASC 350-40’s capitalization triggers to a product the company is building to sell to customers (which falls under ASC 985-20 instead) produces the wrong capitalization start point and the wrong cost population.
• Capitalizing costs from the preliminary project stage: Exploratory research, vendor evaluation, and needs assessment performed before management has authorized and committed funding to the project should be expensed, even if the project is ultimately approved and built.
• Treating all payroll on the project as capitalizable: Only the payroll and payroll-related costs of employees who are directly associated with, and who devote time directly to, the development project qualify. Time spent by the same employees on unrelated work, or overhead-type project administration, should not be swept into the capitalized total.
• Applying an internal-use software useful life to cloud hosting implementation costs: Because SaaS implementation costs amortize over the hosting contract term, not an independently estimated software useful life, using the wrong amortization period understates or overstates expense in a way that will surface at the next contract renewal or audit.
• Not documenting the useful life estimate: Because useful life is a judgment call within GAAP and IFRS, both frameworks expect it to be supportable and applied consistently across similar projects, not selected after the fact to hit a target expense number.

GAAP vs IFRS Differences Worth Flagging

• Recognition trigger: ASC 350-40 organizes the analysis around three defined stages tied to project authorization and completion of preliminary evaluation. IAS 38 organizes it around six specific capitalization criteria (technical feasibility, intention, ability to use or sell, probable future economic benefit, resource availability, reliable measurement) that must all be demonstrated before development costs are capitalized.
• Research costs: IAS 38 explicitly and always expenses research-phase costs, with no capitalization path. ASC 350-40’s preliminary project stage functions similarly in effect but is framed as a stage of a single internal-use software project rather than a formally separate “research” category.
• Reversal of expensed research/preliminary costs: Neither framework allows previously expensed preliminary/research costs to be reinstated as an asset later, even once the project clears the capitalization threshold.
• Interest capitalization: Both frameworks permit capitalizing interest costs incurred to finance a qualifying software development project, though the specific mechanics for computing the capitalized amount follow each framework’s general interest capitalization guidance (ASC 835-20 under US GAAP; IAS 23 under IFRS).

Where a company reports under both frameworks (a US GAAP parent with an IFRS subsidiary, for example), it is common to see the same software project capitalized on slightly different dates or for a slightly different cost population under each standard. That is not necessarily an error, it reflects the frameworks’ genuinely different recognition tests, and should be reconciled explicitly rather than forced to match.

How Bluecopa Simplifies Capitalized Software Accounting and Amortization Tracking

Capitalized software is one of the easier balance sheet items to get right in a single month and one of the easiest to lose track of over several years, because it depends on classifying costs correctly at the point of entry and then carrying a consistent amortization schedule forward every close, often for five to seven years, across multiple in-flight projects at different stages.

Bluecopa’s platform, powered by SamyxAI, supports this as part of the broader continuous close process rather than as a standalone spreadsheet exercise. Capitalization thresholds and stage classification rules (what counts as preliminary project stage versus application development stage, for instance) can be encoded as policy through Samyx Build, so costs are routed to the correct expense or capitalized-asset treatment consistently across projects and reporting periods, rather than relying on a controller remembering the rule each time a new development project starts. Once an asset is capitalized, Bluecopa can maintain the amortization schedule automatically, generate the recurring amortization entry each period, and keep the capitalized-software subledger reconciled to the general ledger balance as part of the standard close checklist, with a visible audit trail supporting the classification and useful-life judgment behind each project.

For finance teams also managing the broader R2R process this asset sits inside, related reading includes bank reconciliation automation and financial close automation (internal link placeholders, verify against the live sitemap before publishing).

Frequently Asked Questions

1. Is software capitalization mandatory under GAAP and IFRS, or is it a choice?

It is not optional once the recognition criteria are met. Under ASC 350-40, qualifying application-development-stage costs must be capitalized, not expensed by preference. Under IAS 38, development costs meeting all six criteria must be capitalized; there is no accounting policy election to expense them instead.

2. What account is capitalized software recorded to on the balance sheet?

Internally-developed, internal-use software is typically recorded as an intangible asset (or, in some companies’ charts of accounts, as a specific fixed-asset category), commonly labeled “Capitalized Software” or “Internal-Use Software,” separate from purchased off-the-shelf software licenses and separate from cloud hosting implementation costs, which are presented as a prepaid or other asset instead.

3. When does amortization of capitalized software start?

Amortization starts when the software is substantially complete and ready for its intended use, which is a specific date to identify and document, not the date the last invoice was paid or an arbitrary period-end.

4. What useful life should we use for capitalized software?

There is no single mandated number; a range of 3 to 7 years is common in practice, based on management’s estimate of the software’s expected functional life. This is a judgment call that should be documented, applied consistently to similar projects, and revisited if circumstances materially change.

5. Are SaaS subscription implementation costs treated the same as internally-developed software?

No. Cloud/SaaS hosting arrangement implementation costs are capitalized under a related but distinct part of ASC 350-40 (as amended by ASU 2018-15), presented outside the software intangible asset (typically as a prepaid or other asset), and amortized over the hosting contract term rather than an independently estimated useful life.

6. Does ASC 985-20 apply to the journal entries described in this article?

No. ASC 985-20 governs software a company develops to sell, lease, or market to external customers as a product, and uses a different capitalization trigger (technological feasibility) and mechanics. This article addresses internal-use software under ASC 350-40 (and its IFRS counterpart, IAS 38); ASC 985-20 is a separate, narrower standard that should be applied on its own terms if that is the actual fact pattern.