AI spend attribution and the AI Tax
How AI sessions link to tickets and initiatives, why unattributed spend is shown rather than hidden, and what the AI Tax measures.
Updated 18 July 2026
Metering answers what AI cost. Attribution answers the harder question: what did the spend buy? EngLedger ties AI sessions to the tickets and initiatives they touched, reports the tied and untied portions separately, and expresses the total as the AI Tax, the AI line item next to the labour cost it belongs with. This page explains how each piece is made and what it does and doesn't claim.
From sessions to tickets
Requests through a person's access URL group into sessions, and each session is resolved against tickets using the strongest available signal:
- Explicit references: ticket keys mentioned in the session. When present these are authoritative.
- Nearby code activity: a commit, merged pull request or branch name from the same person within a few hours of the session, resolving to exactly one ticket. Ambiguity means no link: if the window contains several candidate tickets, EngLedger abstains rather than picking one.
- Worklog overlap: logged time spanning the session, as a final fallback.
A session that touched several tickets has its spend split across them in proportion to the time spent on each within the session, not duplicated onto all of them. Links are re-resolved as new commits, PRs and worklogs sync, so attribution improves over the following days as the surrounding evidence lands.
Attributed, unticketed, unattributed
Not every dollar can be tied to a ticket, and EngLedger reports that honestly instead of folding the remainder into a total. Spend lands in one of three buckets:
| Bucket | Meaning |
|---|---|
| Attributed | The session links to at least one ticket |
| Unticketed | The person is known, the ticket isn't |
| Unattributed | The spend can't be resolved to a person at all |
Unticketed spend isn't necessarily waste: research, exploration and ad-hoc questions are real work that never had a ticket. The reports break it down by session intent and flag the portion with code output nearby, so you can see how much of it looks like delivery work versus chat. The grand total always includes every bucket; attribution changes how spend is explained, never how much of it is counted.
This is the honest-numbers principle applied to AI: a smaller attributed figure you can defend beats a bigger one built by assuming every dollar near a ticket belongs to it.
Session intent
Alongside what a session was for, EngLedger classifies what kind of work it was: feature, bugfix, spike, chore, investigation or other. Where a session links to a ticket with a type, the intent comes straight from that type: a bug ticket means a bugfix session, deterministically. Where it doesn't, the session is classified automatically and carries a confidence score; the session intent report flags classifications below 70% confidence explicitly and tells you to treat them as indicative, rather than presenting every label at equal strength.
Intent is what turns spend size into spend mix: the governance overview's productive mix figure is the share of classified AI spend on feature and bugfix work, and the session intent report breaks spend down by intent and person. Like attribution, intent quality rides on ticket hygiene: typed tickets classify themselves.
Rolling up to initiatives
Ticket-level spend rolls up to initiatives through the same ticket grouping the labour ledger uses: epics expand to their child tickets, and an initiative's cost-split percentages apply to AI spend exactly as they do to labour cost. That symmetry is the point: an initiative's AI spend and labour cost are built from the same ticket set, so the two numbers are comparable rather than merely adjacent.
The AI Tax
The AI Tax is AI tooling spend as a percentage of your engineering cost for the period, trended month over month. A provider invoice says what AI cost in dollars; the AI Tax says what it cost relative to the engineering it supports, the form the board question actually takes. The dedicated report shows the monthly trend, month-on-month comparison and a per-person breakdown, and the spend report adds a forward forecast of spend itself.
The denominator is the engineering cost modelled by the effort model (rate × hours × overhead) so the AI Tax needs hourly rates in place. Without them the report says the metric is unavailable rather than inventing a denominator.
Where spend appears beside labour
AI spend sits next to labour cost wherever cost is reported: the cost report carries labour, AI tooling and their combined trend per person; initiative views show AI spend beside actual and capitalised labour cost; and the ticket lookup answers what any given piece of work cost in AI. The full report tour is on the AI Spend overview.
What the numbers mean
- Attributed spend is evidence-linked, not inferred: every link has a stated source, and ambiguous cases stay unattributed by design.
- Unticketed and unattributed spend are shown, not hidden. A high unattributed share is a data-hygiene finding, not an accusation.
- The AI Tax is a ratio of modelled costs, as good as your rates and effort data, and labelled unavailable when they're missing.
- Attribution says spend and delivery coincided; it doesn't prove the spend caused the delivery. The reporting keeps that distinction. See the AI governance model.