Classifying engineering time as capex or opex
How SquadBear tags projects and work items so finance can turn logged hours into evidence
This is for a CTO or CFO who needs to know which engineering hours count as R&D, and where that split actually comes from in SquadBear — not for an accountant, who already knows the rules and just needs the data.
What "R&D cost" means for a software company
For most software companies, R&D cost is payroll. There's no lab, no materials line — the asset being built is the code, and the cost of building it is the time engineers spend on it. Which means the question that matters isn't "how much did R&D cost" in the abstract, it's always the more specific one: whose hours, on what. Answering that requires knowing, per person, which project and work item they worked on, and whether that work counts as development.
Why classification matters
Two independent reasons, both hinging on the same underlying data:
- Accounting. Under IAS 38 (the EU and Poland's standard), development costs that meet the capitalization criteria go on the balance sheet as an asset and get amortized, rather than hitting the P&L as an expense the month they're incurred — it changes EBITDA and smooths reported profit. US GAAP has an equivalent for internal-use software, ASC 350-40.
- Tax relief. Poland's ulga B+R (an enhanced deduction for qualifying R&D personnel costs) and IP Box both require per-person, per-project time evidence to support a claim — that's specifically what the tax office asks for. The UK has its own R&D relief regime; the US requires capitalizing (amortizing) §174 research costs rather than deducting them immediately. Each of these has its own qualifying criteria and rates, which change — this page deliberately doesn't quote any, so it doesn't go stale. Talk to your advisor about which apply and how.
The evidence problem
Auditors and tax offices want contemporaneous, per-person, per-project hours — not a spreadsheet reconstructed from memory after the fact. A retroactive estimate is exactly the kind of evidence that fails an audit; logged time, recorded as the work happened, is the evidence itself.
How SquadBear models it
Classification runs on a single, tenant-defined axis of time categories. A new workspace starts with none; under Time tracking → Settings → Time categories you add your own, or seed a ready-made pair with one click — CAPEX / OPEX is one preset (Billable / Non-billable and R&D / Routine are the others). Everything below uses the CAPEX/OPEX preset as its running example, but the mechanism is identical whatever categories you define.
A category applies in two places: a project-level default (a category, or unset) and an optional work-item-level override that can also be left unset, in which case it inherits the project's default. Set the project default when you create or edit a project (field "Category"); set a work item's override in the project's Work items panel, per work item.
Categories are never deleted, only archived — an archived category stops appearing for new assignment but keeps labeling the hours already logged against it, so historical reports stay intact.
Classification never blocks logging — people log time against whatever project and work item they're actually working on regardless of whether it's classified yet; classifying is a separate, later step for whoever owns the reporting. It's also not locked to the moment the hour was logged: classification lives on the project and work item, not on the individual time entry, so if you reclassify a work item next month, every hour ever logged against it — past and future — reports under the new classification the next time you run the report.
At review time, the Reports tab (alongside Week/Month/Team under Time tracking) groups by category, as well as user, project and work item, filters to a single category or to Unclassified, and exports CSV.
Month-end workflow
Filter the report to the month, group by category, export CSV, and hand it to finance — they apply their own capitalization policy and rates to the totals. SquadBear's job stops at giving them clean, per-person, per-project hours; the accounting judgment stays theirs.
Worked example
In July, Northlake's 12 engineers logged 1,000 hours combined: 700 on "Platform v2" (of which 90 were on the "Bug triage" work item, overridden to Opex — the rest, 610 hours, inherits Platform v2's Capex default) and 300 on "Maintenance & support" (Opex, the project's default). Grouping the July report by category gives 610 capex hours and 390 opex hours — 61% of July's engineering hours are capitalizable. Northlake's finance lead takes that split and applies the company's own capitalization policy to it; nothing about the 61% figure came from SquadBear doing accounting — it came from clean hours, grouped correctly.
What SquadBear deliberately doesn't do
No money math — hours-times-rate stays in finance's own model, not SquadBear's. No tax-form output. No automatic capitalization decision — 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.
Legal context above is current as of mid-2026 and will drift — verify current treatment with your advisor rather than this page.