Finance & AccountingFree
Software Cost Capitalization Memo Template
Every engineering hour dated against the capitalization threshold, with the evidence for each boundary named and the schedule that follows from it.
Most software capitalization runs on one number nobody can source. Engineering cost 2.9 million, engineering is roughly sixty-five percent build, so 1.9 million goes on the balance sheet. It ties to the ledger, it survives most reviews, and it is not an accounting policy. The policy is a date per project and a treatment per hour. The only reason the percentage exists is that producing the dates means reading the sprint records against the approvals, and nobody wants to.
So this produces the dates. Each project gets the day management authorized and committed the funding, the day completion and use became probable, and the day the software was ready for its intended use. Each boundary carries the artifact that proves it: the minute, the spike close-out, the deployment record. PCAOB AS 1105 is blunt about why the artifact matters, because more of the same evidence cannot make up for evidence of poor quality.
Then the same hours get sorted a second time, because book and tax now disagree by design. Software development counts as a research expenditure under section 174A, and the domestic part is deductible when incurred while the foreign part amortizes over fifteen years. So an engineering hour needs a country as well as a date. The revenue policy pack is where the resulting policy lives, and the ASC 606 contract memo is built the same way, evidence first.
Two errors that hide each other
Fenmore Logistics, a fictional freight brokerage, spent 21,600 engineering hours in FY2026 at a blended 136 dollars, so 2,937,600 in total. It has been capitalizing sixty-five percent of that, or 1,909,440. Sorted by the actual boundaries, 11,600 hours qualify: 7,420 on the dispatch rebuild after the board committed funding on 14 April, and 4,180 on the carrier portal after the integration spike closed on 19 June. That is 1,577,600, so capitalization was overstated by 331,840.
The flat rate makes a second error in the other direction. Only the dispatch rebuild went live, on 6 November, so correct FY2026 amortization is two months on 1,009,120, or 33,637.33. The flat method amortizes the whole balance from mid-year and books 190,944, which is 157,306.67 too much. The two errors offset, so the balance sheet looks plausible while pretax income is overstated by 174,533.33. That same figure is the gap in net capitalized software, because it is one error seen twice.
The tax sort uses the same 11,600 hours and a different key. 9,840 were worked in Ohio and 1,760 by a contract team in Lisbon. Under section 174A the domestic 1,338,240 is deducted in full this year. Under section 174 the foreign 239,360 goes to a capital account and amortizes over fifteen years from the midpoint, so 7,978.67 lands in FY2026. Book charges 33,637.33 against a tax charge of 1,346,218.67, and the 1,312,581.33 difference carries 275,642.08 of deferred tax.
How it works
Add the approvals
The board or steerco paper that funded each project, and the release or deployment records.
Add the sprint records
A ticket or sprint export with dates, however rough. Epic names and assignees are enough.
Add engineering cost
Cost by person or role, and where each person works, which the timesheet never asks.
Read the variance
The supported rate, the rate you have been using, and what the difference does to income.
What you get
- A dated capitalization threshold per project, with the artifact that proves each date named
- Every sprint hour placed on one side of that date, or expensed with a reason
- The capitalization rate your evidence supports, against the rate you have been booking
- An amortization schedule that starts per project, on the day each went into service
- The same pool split domestic and foreign, because tax deducts the two differently
- A memo the auditor can test line by line, rather than accept or reject
Common questions
Is a flat engineering percentage acceptable if the percentage is reasonable?
A percentage is a result, not a basis. Defending it means producing the underlying dates and hours, and once those exist the percentage is redundant. At Fenmore the supported rate was 53.70 percent against the 65 percent in use, and that gap put 331,840 on the balance sheet that belonged in expense.
The stage model is being removed. Does a dated memo still work?
It works better. The update took the stage scaffolding away and left the two conditions standing: management has authorized and committed to funding, and completion is probable. Significant development uncertainty delays the start. Those are dates with evidence behind them either way. One registrant's quarterly filing puts the effective date at fiscal years beginning after 15 December 2027, with early adoption allowed.
What gets expensed even after the threshold has been met?
Converting data from the legacy system, training, and anything after the software is ready for use. At Fenmore that was 1,240 hours of dispatch data conversion, 620 of training the operations desk, and 780 of defect work following the 6 November release. All of it sat inside a capitalizing project, and none of it capitalizes.
When does amortization start, and over how long?
When the software is substantially complete and ready for its intended use, per project, rather than when the balance reaches the ledger. Fenmore's dispatch rebuild went live on 6 November, so two months of a five-year life gives 33,637.33. The carrier portal was still in development at year end and amortizes nothing, which is where flat methods quietly go wrong.
How does the tax treatment differ from the book treatment now?
Software development counts as a research expenditure, and for tax years beginning after 31 December 2024 the domestic part is deductible when incurred while the foreign part goes onto a fifteen-year amortization. Book capitalizes either way, so one pool now produces two schedules and a deferred tax balance. Fenmore's came to 275,642.08.
What does the output actually look like?
A sheet with one row per work item carrying the project, the date, the treatment and the evidence reference, then the capitalization and amortization schedules built off those rows. A memo per project stating each boundary date, the artifact behind it and the conclusion. The balance sheet substantiation pack proves the resulting balance monthly.
Does this cover cloud subscriptions, or software we sell?
Implementation work on a hosting arrangement follows the same threshold and the same evidence, so it runs through this unchanged. Software built to be sold is a different subtopic with a technological-feasibility trigger, and the memo says so rather than guessing. Physical assets belong in the capex request instead, and a leased asset schedules separately in the lease accounting pack, the same way this schedules a capitalized one.
Software Cost Capitalization Memo Template
Fill in the form and your workspace opens with the work already underway.