CapEx vs. OpEx for Engineering Time: A Guide for Tech Teams

Sooner or later, someone will ask what fraction of your engineering spend is R&D. It might come as a diligence questionnaire before a funding round, or from a tax advisor who thinks you're leaving relief on the table. At most startups the honest answer is a guess, followed by a painful week of reconstructing a spreadsheet from Jira tickets and memory.

Which is a shame, because the underlying question never changes: whose hours, on what. Answer that from records you already keep, and everything downstream becomes your accountant's problem, in the good sense. This post covers what the split means for engineering time and why it's worth money twice over, then the practical part: collecting the evidence as a byproduct of normal work instead of a forensic project after the fact.

CapEx and OpEx in one minute

Operating expenses (OpEx) hit your profit-and-loss statement the month you incur them. Salaries and rent, mostly. Money out, profit down.

Capital expenditure (CapEx) buys an asset. The cost lands on the balance sheet and gets depreciated or amortized over the asset's useful life, so the hit spreads across years instead of landing all at once.

For a software company, the asset you're building is the code, and the cost of building it is engineering time. There's no lab and no materials line. R&D cost is payroll. Under IAS 38 (the standard in the EU, Poland included), development costs that meet the capitalization criteria go on the balance sheet as an asset instead of hitting the P&L immediately. US GAAP has an equivalent for internal-use software, ASC 350-40.

The rough intuition, with the actual judgment belonging to your accountant: building new product capability looks like development, while keeping the existing product alive (bug triage, support work) looks like an operating expense.

Why you should care, twice

Reason one: reported profit. Capitalizing development changes EBITDA and smooths reported earnings. If your company is being valued or diligenced, "we expensed everything" and "we capitalize qualifying development" describe the same cash but very different-looking businesses.

Reason two: tax relief. Many jurisdictions run enhanced R&D tax regimes, and they all rest on per-person, per-project time evidence. Poland's ulga B+R (an enhanced deduction for qualifying R&D personnel costs) and IP Box both require exactly that to support a claim; it's specifically what the tax office asks to see. The UK runs its own R&D relief. The US now requires §174 research costs to be capitalized and amortized rather than deducted immediately. Rates and criteria differ everywhere and change often, which is why you won't find any quoted here. The shape of the requirement is the constant: someone will want hours, by person, by project.

Standard disclaimer, and we mean it: none of this is tax or accounting advice. Confirm treatment with your own advisor before relying on any of it.

The evidence problem

Most companies don't fail on the accounting. They fail on the data. Auditors and tax offices want contemporaneous records: hours logged as the work happened, attributable to a person and a project. A spreadsheet reconstructed from memory in March, covering the previous year, is exactly the kind of evidence that falls apart under examination.

Your accountant decides what counts as capex. The question you own is more basic: does a trustworthy record of who worked on what exist at all?

Classify the work, not the hours

The classic failure mode is asking engineers to make an accounting call every time they log an hour ("was that capitalizable development or maintenance?"). They don't know, and they're right not to care. So they guess, and the data is garbage.

The fix is structural: classification belongs on the work, not on the hours.

• Engineers log time against the project and work item they're actually working on. That's the entire ask, and it's the same timesheet they'd keep anyway.
• Whoever owns reporting classifies the projects and work items, separately and later. A project carries a default category, and an individual work item can override it (a "Bug triage" item inside a development project gets flipped to OpEx).
• Classification never blocks logging, and it isn't frozen at entry time. Reclassify a work item next month and every hour ever logged against it, past and future, reports under the new category the next time you run the report.

Where this lives in SquadBear

Under Time tracking → Settings → Time categories. A new workspace starts with no categories at all; one click seeds a preset pair (CAPEX/OPEX, Billable/Non-billable, or R&D/Routine), or you define your own. You set a project's default in its Category field and per-work-item overrides in the project's Work items panel. Categories get archived rather than deleted, so historical reports keep their labels forever.

At month-end, the Reports tab groups hours by category (and by user, project, or work item), filters to a single category or to Unclassified, and exports CSV. Hand that file to finance. They apply your capitalization policy and rates to clean totals, and the accounting judgment stays with the people qualified to make it.

A worked example

Northlake's twelve engineers logged 1,000 hours in July: 700 on "Platform v2", a project with a CAPEX default (90 of those hours sat on a "Bug triage" work item overridden to OPEX), plus 300 on "Maintenance & support", which defaults to OPEX. Grouped by category, the report reads 610 capex hours and 390 opex hours. That puts 61% of July's engineering time in the candidate-capitalizable pile, per person, receipts attached. Nobody on the team thought about accounting even once.

If your AI assistant is connected, month-end is a sentence:

"Pull July's engineering hours grouped by category, give me the CSV, and flag any work items that still have no category."

What we deliberately don't do

There's no money math (hours times rates stays in finance's own model) and no tax-form output. And nothing gets capitalized automatically: a human still applies judgment to the classified hours. SquadBear's job is making sure the hours exist and are attributable, not deciding what they mean.

Start before someone asks

Contemporaneous evidence can't be backfilled; by the time the request arrives, the record either exists or it doesn't. Start free and seed the CAPEX/OPEX preset in one click, or ask the demo to run the July report and see the split on sample data.

Related reading: the velocity blindspot, on what else your board can't see about where the hours went.