How to Build a Finance Department Internally Developed Software Capitalization Tracking Process That Keeps ASC 350-40 Compliance Intact

Software development spending is one of the most judgment-intensive areas finance teams manage. Unlike purchasing a physical asset with a clear invoice, internally developed software moves through distinct phases, and the accounting treatment changes meaningfully depending on which phase a cost falls into. Under ASC 350-40, the guidance governing internal-use software, only costs incurred during the application development stage are eligible for capitalization. Preliminary project stage costs and post-implementation costs are expensed as incurred. That boundary sounds clean in a textbook but becomes blurry fast when engineers are iterating, vendors are issuing invoices, and project managers are describing work in terms that do not map neatly to accounting stages.

Without a deliberate tracking process, finance teams often discover the problem at audit time, when an auditor asks for support on a capitalized balance and the documentation trail is thin or inconsistent. The good news is that a structured approach is achievable without exotic software or large headcount additions. What it requires is clear ownership, documented stage gates, and a consistent routine for collecting and reviewing data.

Start With a Written Capitalization Policy That Defines Your Stages

The foundation of any defensible process is a written policy that translates ASC 350-40 into language your engineering managers, project coordinators, and HR business partners can recognize. The policy should define what constitutes the preliminary project stage at your company, what signals that a project has entered application development, and what triggers the post-implementation cutoff. It should also establish a minimum project size threshold below which costs are expensed outright. Many companies set this threshold based on expected total project cost or expected useful life. Without a threshold, the capitalization process absorbs small projects that generate more administrative cost than accounting benefit.

The policy should be formally approved by the CFO or controller, stored in a central policy library, and revisited at least annually. When accounting standards or interpretive guidance evolves, the written policy is what auditors will review first to understand how management approached its accounting judgments.

Design a Stage Gate Documentation Workflow

Once the policy exists, the process needs a mechanism to capture when each project moves from one stage to another. A simple stage gate form, completed by the project sponsor or IT finance liaison at each transition, accomplishes most of what auditors want to see. The form should capture the project name, a brief description of the work being performed, the date the team determined the application development stage began, and the name of the finance reviewer who concurred.

For projects that pause or restart, the form should allow for a new stage determination rather than assuming the prior classification carries forward. Projects sometimes return to the preliminary stage when scope changes materially, and documentation of that re-evaluation protects the company from capitalizing costs that should be expensed.

Consider routing these forms through the same project management system your engineering teams already use, whether that is a ticketing tool, a project portfolio tracker, or even a shared folder with version control. The goal is to put the documentation where the work happens, not to create a parallel administrative burden that people skip under deadline pressure.

Build a Cost Collection Routine Around Pay Periods or Invoice Cycles

The mechanics of collecting capitalizable costs vary by company, but the most common sources are internal labor, external consultant invoices, and cloud hosting fees directly tied to development activity. For internal labor, the process typically involves asking employees or their managers to allocate time to specific projects and stages on a timesheet or equivalent tool. Finance teams should establish a regular cadence, aligned with payroll periods, for pulling that allocation data and calculating the capitalizable portion.

For external costs, the accounts payable team needs guidance on tagging invoices that relate to capitalized projects at the time of coding. A simple project code field in the ERP, mapped to a capital work-in-progress account, is often sufficient. The key is that the tagging happens at entry, not retroactively at close, because retroactive reclassifications generate reconciling items that are hard to explain and easy for auditors to question.

Cloud computing arrangements deserve particular attention because the accounting depends on whether the company is hosting software it controls or accessing a third-party hosted solution. ASC 350-40 was updated specifically to address implementation costs for cloud arrangements, and those costs have their own stage-based capitalization rules. Finance teams managing SaaS implementations should apply the same stage gate documentation approach and confirm that the asset classification reflects the nature of the arrangement.

Establish a Monthly Review for the Capital Work-in-Progress Balance

Capitalized software costs accumulate in a capital work-in-progress account until the asset is placed in service, at which point it transfers to an intangible asset account and amortization begins. A surprising number of companies allow the work-in-progress balance to grow without regular review, which creates two problems. First, projects that have been placed in service or abandoned are not cleared promptly, overstating assets. Second, the useful life and amortization method are not established until well after the project concludes, compressing the amortization period.

A monthly review of the work-in-progress balance, led by the controller or a senior accountant, should confirm that every project balance still reflects active capitalization-eligible work, that projects placed in service during the period have been transferred and placed on an amortization schedule, and that any abandoned projects have been written off with appropriate documentation. This review does not need to be lengthy. A prepared aging report and a brief conversation with the IT finance liaison is usually sufficient to clear most items.

Prepare an Audit-Ready Rollforward at Every Close

The deliverable that ties the entire process together is a rollforward schedule for internally developed software. This schedule should show the beginning balance for each project, additions during the period by cost category, transfers to placed-in-service status, write-offs for abandoned projects, and the ending balance. It should reconcile to the general ledger balance and be supported by the underlying stage gate forms, time allocation reports, and vendor invoices.

Keeping this rollforward current at every close, rather than preparing it only for annual audits, reduces the year-end preparation burden significantly. It also means that if an auditor raises a question about a specific project, the finance team can respond within a day rather than spending a week reconstructing a trail.

Building this process takes some upfront coordination between finance, IT, and project management, but the structure it creates pays ongoing dividends. Capitalized software balances become a line item that management understands and can explain, rather than a bucket that grows until someone looks closely. That transparency is exactly what auditors and senior leadership expect from a well-run finance function.