Congratulations! You’ve just unlocked one of the more mysterious quests in software leadership: figuring out how much of your team’s work can be capitalized. You didn’t ask for this. You probably didn’t even know it was a thing. But here we are.
Accounting and engineering are domains that rarely overlap, but since software development is a major cost center for most companies, that disconnect has real implications. Explaining engineering practices to non-technical people and defending your R&D investments is not an easy task.
You and your counterparts in finance are ultimately working toward the same goals, even if you’re approaching the problem from different angles. That goal is to ensure your company is in the best position for the future by building great products while being financially responsible.
That balance is why your CFO might be so eager about software capitalization. They want the books (cool accounting slang 😎) to reflect that your R&D costs are about ensuring a bright future.
That gets us back to your quest: figuring out how much development work can be capitalized.
The most common approach to solving software capitalization is timesheets. Unfortunately, that often means extra overhead for engineering teams and frustrating manual work for you. Traditionally, this means repeated, manual effort to gather data and piece together some story that makes sense to both engineering and finance. You end up playing translator between two worlds and still get stuck doing half the data entry.
Individuals writing down their hours isn’t, however, what is required. What is? A system.
The good news is that your developers already leave behind a rich trail of breadcrumbs: Git commits, issue tracker updates, PRs, branch names, commit messages, and so on. These artifacts tell a detailed story of who did what and when. Swarmia uses this existing data to stitch together a picture of where effort has been allocated.
This is the part that your finance counterparts may not immediately understand, and if you want to replace timesheets, you’ll need to explain how developers work. The picture below can help you explain how all those breadcrumbs come together.
Armed with this understanding, you can help your finance team see why developer artifacts are actually more reliable than timesheets:
Most importantly: this approach aligns with how your teams actually work. Plus, less interruptions to flow is never a bad thing.
Once you have buy-in, the hard part is done. So let’s go over the easy part: how Swarmia’s software capitalization works in practice.
At the core of Swarmia’s software capitalization feature is a Full-Time Equivalent (FTE) model. This model gives you a structured, quantifiable way to understand how engineering effort is distributed across projects without resorting to manual time tracking.
Swarmia automatically consolidates data from your Git repositories and issue tracker. Every developer’s activity — pull requests, commits, comments, code reviews, and more — is captured and translated into an FTE estimate. That effort is then intelligently allocated across projects based on where the work is happening.
The model also accounts for periods of inactivity. If a developer is out of office or not actively contributing, their allocated effort is reduced accordingly. You can even sync time off data directly from your HR system to keep things accurate. This happens behind the scenes, with no manual tagging or time entry required.
While this model is designed to support software capitalization, its benefits go beyond finance. It gives you a clear view of where your engineering time is going, which is helpful for planning, resourcing, and spotting potential imbalances in project focus.
To get started, you’ll define the rules determining what counts as capitalizable work. This typically involves setting up filters in Swarmia that align with your existing issue tracker setup, such as labeling capitalizable epics or categorizing work under specific initiatives.
This is a great moment to bring in your finance team. Collaborating on the criteria ensures that both sides are aligned and that the reports meet your company’s accounting standards. As a rule of thumb, work towards significant improvements and new features are capitalized while keeping things up and running is not.
Once your rules are in place, everything else runs on autopilot. You can invite team leads or finance stakeholders to review and adjust the data if needed. When it’s time to report, you can export results monthly or yearly — or set up automated delivery so the right people get the correct data as soon as the reporting period ends.
You can finally answer the big capitalization question with confidence. Thanks to Swarmia’s evidence-based approach, you’ll be armed with actual data instead of vibes. Your reports are rooted in real, observable activity.
They’re built on the engineering practices you already have in place without asking your team to fill out timesheets or log their souls in Jira.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
