Apportionments: what’s defensible
Apportionments don’t need to be perfect, but they do need to be explainable, consistent, and grounded in how the work was actually delivered. Here’s how to keep them robust without building a time-tracking regime.
The common mistake with apportionments is treating them as a purely accounting exercise. In practice, they should reflect how the team spent their time on qualifying activities versus non-qualifying delivery, BAU, support, sales/BD, and general management. HMRC doesn’t expect clairvoyance, but they do expect logic that’s coherent and evidenced.
Key principle: the more subjective an apportionment is, the more you should lean toward a conservative percentage and stronger supporting rationale.
What makes an apportionment “defensible”?
Defensible doesn’t mean “precise to the hour”. It means you can show (i) the basis used, (ii) why it matches delivery reality, and (iii) that it was applied consistently.
Defensible patterns
- Role-based splits grounded in work packages (e.g., “platform R&D stream” vs “client delivery stream”).
- Project-level allocation where responsibilities are clear and repeated over time.
- Percentages supported by simple artefacts: sprint scope, ADRs, test results, milestone plans.
- Conservative treatment for mixed or managerial roles.
Higher-risk patterns
- “Reverse-engineered” percentages from cost totals (starting with money, not activity).
- Uniform 80–90% across most staff with limited differentiation.
- Percentages that change materially year-to-year without an operational reason.
- Allocations not aligned to the narrative or AIF project scope.
Practical apportionment methods that work well
Below are four approaches that typically withstand scrutiny when applied thoughtfully. The “best” method depends on how your teams and projects are structured.
Work-package allocation
Allocate based on recurring work packages (e.g., “R&D stream” vs “delivery stream”), mapped to roles. Best where teams are organised by streams or squads.
Project responsibility split
If named individuals owned defined technical work on qualifying projects, apportion by those responsibilities (supported by sprint goals, technical notes, test outcomes).
Milestone time-boxing
Use milestone windows (e.g., 10 weeks of prototyping/testing) where the team was materially focused on R&D. Works well in engineering and product-led builds.
Lightweight sampled estimation
Where reality is mixed, do a short sampling exercise (e.g., 2–3 representative months) and apply a conservative annualised ratio with a clear write-up.
What to retain to support defensible apportionments
Apportionments should be grounded in evidence that is contemporaneous and traceable. HMRC generally doesn't expect you to document every second of every minute. However, you should be able to clearly demonstrate how the apportionments were derived, how this maps to qualifying workstreams and why it reflects how the team actually operated within the year.
Scope & work packages
Sprint goals, epic summaries, work-package definitions, or a simple stream map (R&D vs delivery).
Decision and iteration trail
ADRs, benchmark results, prototype iterations, test outputs, high-signal evidence of technical work.
Want us to sense-check your apportionments before filing?
We can review your apportionment logic against your project scope and evidence base, and suggest practical refinements that improve clarity and defensibility without adding process overhead.