Loading…
Loading…
Most software capitalization trackers sort by development stage. Here is what happens to the spreadsheet when that column stops carrying meaning.
Open the spreadsheet your team uses to track capitalized software development cost. Somewhere in the first few columns there is one called Stage, or Phase, or something close to it. Every row is tagged with a value from a short list, and a formula further right decides whether that row is expensed or capitalized based on the tag.
That single column is load bearing. It is the axis the whole file is organised around, and it is the reason the file exists in a spreadsheet rather than in the ERP.
This article is about what that column does to a system, and what happens to the system when the column changes. Your accounting policy is a matter for your accountants. The data model is a matter for whoever has to rebuild the file every quarter.
Software development cost is not one thing. Some of it is exploration, some of it is building the thing you decided to build, and some of it is keeping the thing running afterwards. Those are treated differently, so somebody has to decide which bucket each cost falls into.
The stage column is how that decision got encoded. It converts a judgement into a category, and once a cost is categorised, a formula can act on it. That is a reasonable design. It is also the point where the process leaves the system of record.
Your ERP holds the payroll run, the contractor invoice, and the infrastructure bill. What it does not hold is the reason a particular slice of that payroll run belongs in one bucket rather than another. That reason lives in the head of whoever tagged the row, and the tag is the only surviving trace of it.
Three problems follow from a design where the determination lives in a tag applied by hand.
The evidence is the tag. If someone asks why 60 percent of an engineer's quarter was capitalized, the answer available in the file is the tag. Not the tickets, not the commits, not the sprint the work sat in. The tag was probably right. It is just hard to show why.
The allocation does not survive scale. With 20 engineers on two projects, tagging is an afternoon. With 200 engineers across 30 projects, several of which run concurrently and some of which get cancelled halfway, tagging becomes a monthly programme of work that produces no output other than the tags themselves.
Reconciliation is manual by construction. The schedule lives in the spreadsheet, the journal lives in the ERP, and nothing connects them. They agree because someone checks that they agree. When they disagree, finding out why means reading two documents side by side.
The stage model is not permanent. Guidance in this area is moving, and one of the things under revision is the staged framing that most trackers are built around.
Confirm the specifics and the timing with your accountants, because that is their call and not ours. What we can say from the systems side is narrower and more useful: if the categories change, a tracker organised around the old categories does not get edited. It gets rebuilt.
That is the difference between a data model and a formula. A formula that maps stage = "application development" to capitalize = TRUE encodes a specific vocabulary. Change the vocabulary and every row, every formula, and every pivot downstream of it needs revisiting. A data model that records what the activity actually was, and applies policy rules on top, only needs the rules changed.
The shape that survives a change in categories has three properties.
It records activity, not conclusions. The base layer is what happened: this engineer, this project, this sprint, these tickets, this period, this cost. That is a fact, and facts do not go out of date when guidance changes.
Policy is a separate layer. The rules that turn activity into a treatment sit above the activity data and are configured, not hardcoded. When the rules change, you change the rules. The history stays intact and stays queryable under both the old rules and the new ones.
Evidence is attached, not implied. Each amount points at the record it came from. Not a tag someone applied, but the project system entry, the payroll line, the sprint. When the question comes, the answer is a link.
None of that requires abandoning the ERP. The ledger is good at holding the asset and running the amortization. The gap is the layer in front of it: the rules, the allocation, and the record of why an amount is what it is.
You do not need a project to find out whether this applies to you. Three questions get most of the way there:
If the answers are yes, recollection, and start again, the tracker is doing work a system should be doing.
Not sure where your process sits?
Seven questions, three minutes. Score your capitalization process and see the gaps.