Skip to content
Software Capitalization

Software Capitalization

Software capitalization is the accounting practice of recognizing eligible internal development costs as capital assets on the balance sheet rather than expensing them immediately on the income statement. Under ASC 350-40 (US GAAP) and IAS 38 (IFRS), companies may capitalize costs incurred during the application development stage of internal-use software, which directly improves reported EBITDA and net income for the period.

AndonPulse automates this process end-to-end: it reads the full history of your engineering tasks from your Issue Tracker, determines which tasks qualify for capitalization and for how long, attributes that time to the responsible engineers, and delivers a ready-to-use monthly report for your finance team — without requiring engineers to fill in timesheets.

How Capitalization Eligibility Is Determined

AndonPulse uses a rule-based engine to evaluate each task at every point in its history. Rules are tailored to your workflow; AndonPulse applies them continuously as tasks move through your process.

Capitalization Rules

We customize and support everything for you according to your specific request. Your workflow, terminology, and accounting needs differ from others — so we work with you to define and tune capitalization rules that match how your team actually works. There is no one-size-fits-all setup; we help you get the right rules in place and keep them updated as your process evolves.

Each rule is composed of two parts:

  1. Conditions — a set of field values that must all be true at the same time for the rule to fire. Conditions can be based on any tracked field: task type, status, labels, sprint, component, custom fields, or any combination thereof. A rule can be as minimal as a single status check, or as precise as matching multiple fields simultaneously.

  2. Credited person — which role on the task is credited when the conditions are met. This can be any person-type field: Assignee, Reviewer, Tester, Executor, or a custom role.

When all conditions of a rule are satisfied simultaneously, the system attributes the elapsed time to the person in the designated role.

Example rules:

ConditionsCredited Person
Status = “In Progress”Assignee
Status = “In Review”Reviewer
Task type = “Engineering” AND Status = “In Progress” AND Label = “capitalizable”Assignee
Task type = “Engineering” AND Status = “In QA” AND Label = “capitalizable” AND Blockers NOT CONTAINS “Waiting for response”Tester
Task type = “Design” AND Status = “In Progress”Executor

Your organization is not locked into any specific field combination. If your workflow only uses statuses to distinguish capitalizable work, a rule as simple as “Status = In Progress → credit Assignee” is perfectly valid. If you need finer control — for example, capitalizing only tasks in a specific component or sprint — we can add the right conditions to your rules.

For time to be attributed, a task must satisfy all conditions of at least one rule simultaneously. The moment any condition in a rule stops being true (e.g., the status changes, a label is removed), that rule stops firing and time accumulation for it ceases.

Rule changes are applied retroactively. When a rule is added or updated, AndonPulse automatically recalculates the full history of all tasks against the updated rule set. The capitalization report for all past months is refreshed to reflect the new configuration — no manual re-processing is needed. Finance teams can iterate on their accounting policy with our support and immediately see the corrected numbers for prior periods.

How Time Is Measured

AndonPulse does not rely on manual time entries. Instead, it reconstructs a precise timeline of every issue by replaying every changelog event ever recorded in the Issue Tracker — status changes, assignee changes, reviewer assignments, label additions and removals, and more.

For each moment in time, AndonPulse knows the full state of the task: its type, status, label set, and who is assigned in each role. By comparing consecutive states, it derives exactly how long each configuration was active. This is then passed through the capitalization rules to produce a duration for each rule match.

Working Days Only

Only Monday through Friday calendar days are counted. Time that falls on Saturday or Sunday is automatically excluded. This applies regardless of whether the task was actively changing state over the weekend.

The 8-Hour Daily Cap

Each employee is capped at 8 hours of capitalizable time per calendar day. This reflects the standard working day assumption used in most accounting policies.

If an employee’s total attributed time on a given day exceeds 8 hours, all allocations are scaled down proportionally so the daily total equals exactly 8 hours.

Example:

Carol is credited on three tasks on the same day: 4 hours on Task A, 3 hours on Task B, and 2 hours on Task C — totalling 9 hours. Since 9 hours exceeds the 8-hour cap, each allocation is multiplied by 8/9 ≈ 0.89:

  • Task A: 4 h → 3.56 h
  • Task B: 3 h → 2.67 h
  • Task C: 2 h → 1.78 h
  • Total: 8.00 h

This ensures the total capitalizable hours reported never exceeds a standard workday, regardless of how many tasks were active.

Edge Cases

Employee Works on Multiple Tasks Simultaneously

When an engineer is credited for two or more tasks at the same time — for example, they are the Assignee on Task A while also being the Reviewer on Task B during an overlapping window — AndonPulse splits the overlapping interval equally among all concurrent tasks.

Example:

Alice is the Assignee on Task A (capitalizable) and the Reviewer on Task B (capitalizable) from 10:00 to 11:00.

Each task receives 30 minutes of attributed time for that hour, not 60 minutes each.

This prevents double-counting and ensures the total capitalized time never exceeds actual calendar time worked.

Some Tasks Are Capitalizable, Others Are Not

The proportional split described above applies to the total concurrent task count — but only capitalizable intervals are included in the final report.

Example:

Bob is the Assignee on Task C (capitalizable, status “In Progress”) and Task D (non-capitalizable, status “In Progress”) from 14:00 to 16:00.

The 2-hour window is split equally: Task C gets 1 hour, Task D gets 1 hour. Only Task C’s 1 hour appears in the capitalization report. Task D’s time is discarded.

The time split is fair — Task D still “consumes” half of Bob’s day — but the non-capitalizable task never appears in the report.

Task Fields Changed After the Work Was Done

AndonPulse tracks field values at the exact moment in time when work occurred, not the current snapshot in the Issue Tracker.

If a project manager retroactively removes a capitalizable label, or the task type is changed, or an assignee is corrected, these changes only affect the periods after the change was made. Historical work — work performed while the task was validly capitalizable — remains in the report.

Example:

Task E had the capitalizable label from January 1 to January 20 and was worked on from January 10 to January 15. On February 5, the label was removed.

The work done January 10–15 remains in the January report because the task was capitalizable at that time. No retroactive correction is applied.

Conversely, if a label is added retroactively, only the period after the label was added counts — the system does not back-fill.

Employee Has a Day Off or Is on Sick Leave

AndonPulse derives work time from task state durations in the Issue Tracker, not from HR systems or attendance records. It has no direct knowledge of vacations, sick days, or public holidays.

If a task remains in a capitalizable state while an employee is away, that calendar time contributes to the duration calculation. In practice, the 8-hour daily cap mitigates over-reporting significantly: even if a task spans an employee’s absence, they can receive no more than 8 hours per working day.

For precise payroll-aligned reporting, finance teams should cross-reference the monthly report against HR absence records and adjust as needed.

Weekends and non-working days are excluded automatically as described above.

Task Remains in an Eligible Status Across Multiple Days

A long-running task that stays in an eligible status for weeks is handled naturally. Each working day within that period produces its own allocation entry. The 8-hour cap is applied per day independently, so a 10-day task yields at most 80 capitalizable hours for the credited employee.

Finding and Using the Capitalization Report

Navigating to the Report

  1. Log in to AndonPulse.
  2. In the left-hand navigation, click Capitalization.
  3. You will see a list of available months, ordered from most recent to oldest.

Downloading the Report

Click Download next to any month to receive a CSV file with a summary view aggregated at the monthly level. Columns:

ColumnDescription
MonthReporting period (YYYY-MM)
Employee IDIssue Tracker account identifier
NameEmployee full name
EmailEmployee email address
Capitalizable WorkTask identifier and title, e.g. [Engineering task] PROJ-123: Implement OAuth login
Capitalizable HoursTotal hours attributed to this employee for this task in this month

Interpreting the Numbers

  • Capitalizable Hours are always ≤ 8 per employee per day across all tasks combined.
  • The same employee can appear on multiple rows in the same month if they contributed to multiple capitalizable tasks.
  • The same task can appear on multiple rows if different employees were credited (e.g., the Assignee during development and the Reviewer during review).
  • Hours are reported to two decimal places and represent calendar time, not logged effort.

Audit Trail

AndonPulse provides a Details view where you can see capitalized time broken down by day for any month, grouped by issue or by employee. This lets finance or audit teams verify how hours were attributed without leaving the application. For deeper investigations, cross-reference with your Issue Tracker’s change history.

Last updated on