Five Things Financial Plugins for Jira Don't Do (and Why Agencies Feel Them)

There is a particular quality to the conversation an agency owner has with their CFO three months after a Marketplace financial plugin goes live. The plugin is reporting numbers. The numbers are not wrong, exactly. But the CFO cannot use them to answer the questions that mattered when the plugin was bought.

I have heard this conversation, in various forms, from agency owners across the UK, the EU and North America. The plugin is doing what its category is supposed to do. The agency’s questions sit just outside that category. The gap is not a flaw in any specific tool — it is a structural property of the financial-plugin category as it is shaped today.

This piece is the gap analysis. Five categories of analysis the leading Marketplace financial plugins do not deliver, mapped to the margin leak each one corresponds to. No specific vendor names. The general shape is the same across the category.

What financial plugins do well

Before the gap analysis, the credit they deserve. The leading Marketplace financial plugins handle the mechanical layer of project economics competently. They store cost rates per team member with a history of changes. They store billing rates per role or per project. They handle multiple roles per person with multiple rates over time. They roll up cost-rate-times-hours into a project budget actuals view. They support project portfolios, basic earned-value extrapolation, JQL-based custom filters and shareable permissions.

For an agency with twenty production staff, uniform project structure, a narrow gap between senior and junior cost, and an overhead line that does not move much from quarter to quarter, the financial plugin’s output is enough to run the business. The CFO can read the report, the project manager can read the report, the agency owner can read the report. The numbers describe the work and the work is uniform enough that the description is the answer.

The issue is the gap between that case and the case most mid-market digital agencies actually live in.

Gap 1: pre-sold contract budget

Financial plugins, almost without exception, model project budget as something the agency sets internally. The CFO or the project manager decides the project should consume, say, 200 hours of mid-developer time, sets that as the budget, and the plugin tracks how the actual worklogs compare to that planning lid.

This is a useful number. It tells the team whether they are within their internal plan. It does not tell the agency whether the project is profitable, because profitability lives in a different plane: the contract figure the client signed for. A project with 200 hours of mid-developer time as the internal budget might have been sold to the client for £25,000, or for £45,000, or on T&M with a £60,000 ceiling. The internal budget says nothing about the contract.

The margin leak this misses is the gap between the internal plan and the contract. A team that is “on budget” on internal terms can still be running a project that is unprofitable on contract terms, if the contract was priced for a smaller scope than the internal plan assumed. A team that is “over budget” on internal terms can still be running a project that is profitable, if the contract carries enough margin to absorb the overrun.

What an agency’s CFO actually needs to track is the plane the client signed for: the agreed scope, the role breakdown, the fixed price or T&M ceiling. Plotting actuals against that plane is what produces the margin number. Plotting them against the internal budget is what produces a planning report. They are different deliverables, and the financial plugin’s default is the second.

Gap 2: pro-rated overhead allocation

The second gap is the one most agencies find easiest to explain to their CFO and hardest to explain to engineering. The financial plugin computes labour cost per project: cost-rate-times-hours, summed up by project, compared against budget. It does not compute the overhead allocation that turns labour cost into total cost.

Overhead at a 100-person agency is rarely small. Office space, marketing, non-billable salaries (operations, finance, leadership, ops support staff), software stack, occasional consulting and training, recruiting costs — these often run between 25% and 40% of total cost at agency level. Every project benefits from this overhead, and every project should carry a share of it.

Most financial plugins either ignore overhead at the project level (treating it as a single line at the agency level), or push it into a manual spreadsheet allocation that someone updates monthly. The first approach makes project margin reports overstate by 25–40 percentage points; the second is rarely kept current and produces inconsistent results across the team.

What is needed is a programmatic allocation: distribute overhead across active projects proportional to revenue share, with a minimum-revenue floor for slow months. The maths is not complicated. It is just not what financial plugins were built to compute.

The margin leak this corresponds to is the difference between the labour-margin number the plugin reports and the real margin the agency’s P&L actually produces. At a healthy agency with overhead at 30%, the labour-margin report typically overstates real margin by 20–25 percentage points. A project that reads as 35% labour-margin is often 12–15% real margin once overhead is allocated correctly. CFOs who have seen the gap stop making capacity decisions on the labour-margin number; CFOs who have not seen the gap continue making capacity decisions on a number that is off by a factor of two or three.

Gap 3: three project types, one cost model

The third gap is structural to how financial plugins represent project work. They model every project the same way: budget, hours, cost-rate, billing-rate, actuals against budget. This is fine for a uniform Development engagement. It is not fine for the typical mid-market digital agency, which runs three different shapes of work under the same client.

Development engagements are fixed-scope or T&M, time-bounded, billed against the contract. Support engagements are recurring, retainer-priced, with a fixed monthly budget the agency commits to and the client pays for. Internal work — account management between projects, prospect development, internal training, team coordination — does not bill at all but consumes real money.

Each of these has a different cost model. Development’s margin is the contract-versus-actuals plane discussed in Gap 1. Support’s margin is budget-versus-actuals on a recurring envelope. Internal work has no margin in the project sense at all; it is overhead by another name and should be allocated as such. Treating all three through one budget-versus-actuals view produces consistent confusion at every level of the organisation.

The margin leak: a Support retainer that has quietly grown 30% beyond its original scope and is being silently subsidised by the Development engagements next to it. An Internal sub-project that has consumed 40% of an account director’s week without anyone noticing, because none of those hours were ever costed against a deliverable. A Development engagement that closes apparently healthy, with the post-launch tail of support work absorbed back into the build’s cost line and quietly compressing its margin by 10 percentage points.

Three shapes, three architectures. Most plugins offer one. Most agencies need three.

Gap 4: role-mismatch detection with variance attribution

The fourth gap is the one that produces the “why is this project losing money” conversation. The financial plugin reports project margin variance: the project landed three percentage points below the planned margin. Why?

The plugin’s answer is usually one of two flavours. First flavour: a single “over budget” flag with no further breakdown. Second flavour: a list of who logged the most hours on the project, sorted descending, with the assumption that the reader can mentally reconstruct what went wrong. Neither answer is the answer the CFO needs.

The answer the CFO needs is variance attribution by cause. A project margin can compress for three structurally different reasons. Wrong people on the project: a senior at high real cost is doing work that was budgeted at a junior’s real cost, and the variance shows up on the cost side without the budget knowing. Wrong rate applied: the role rate billed to the client is below the role’s real cost in the agency’s economics, often because the engagement was discounted on the price side without rebalancing the role mix on the cost side. Scope creep: the team is doing more hours than the budget priced because the client expanded the scope without a change order.

These three causes have three different fixes. Wrong-people problems are fixed by re-staffing or by re-pricing. Wrong-rate problems are fixed by raising the role rate at the next renewal, or by adjusting the role mix to be more honest about the senior involvement. Scope-creep problems are fixed by paper-trail discipline at the project-management level.

A financial plugin that reports “over budget” without attribution leaves the CFO to diagnose all three causes manually for every project. This is what financial controllers spend half their week doing in agencies that have a financial plugin and a margin problem at the same time.

Gap 5: manager view (PM vs finance separation)

The fifth gap is the one that has the longest implications for agency culture. Financial plugins, by default, present one truth to everyone with access. A project manager opening a margin report sees the same numbers the CFO sees: revenue, cost, margin, variance, attribution. An engineer with workspace access sees their hourly cost line in the system. Visibility, in plugin design, scales with permission level, but the content of the views does not.

This sounds neutral until the agency tries to use it. The CFO needs the full picture to make capacity, hiring and pricing decisions. The project manager does not need to know the margin number on the project they manage; they need to know the hours plan, the role overruns, the scope-creep risks — the metrics they can act on. Engineers do not need to know their own hourly cost; they need to know the work they are responsible for.

When the financial plugin shows the same view to all three, two cultural patterns develop. Project managers start optimising under margin pressure they cannot fully control: declining hours from the team, rushing reviews, deferring quality work that the budget cannot afford. Engineers start logging hours defensively, dropping the marginal half-hour of unpaid investigation that often pays for itself five times over. The financial plugin’s “transparency” produces a measurable degradation in the work it was bought to monitor.

What is needed is a structural separation of views. Project managers see hours, role overruns and scope-creep flags — the metrics they can act on. Finance sees money. Engineers see neither, by default. Same product, three lenses. This is not a permission-management problem; it is an information-design problem, and most financial plugins were not built to solve it.

The margin leak from missing this is harder to quantify than the previous four, because it shows up as a culture drift rather than a line-item leak. But the pattern is consistent: agencies that adopt margin transparency without role-appropriate views experience a 5–10% productivity drop in the first quarter and a long tail of trust erosion that takes another two quarters to repair.

What this means for agencies feeling the gaps

The five gaps above are not exhaustive. They are the five we hear most often in the first conversation an agency owner has after recognising that their financial plugin is producing reports they cannot use. None of them is unfixable; some are fixable by spreadsheet discipline, some by manual allocation, some by separate tooling. But the structural pattern is consistent: the financial-plugin category as it exists today addresses the mechanical layer of project economics and stops short of the analysis layer most mid-market agencies need.

What I would offer to an agency owner reading this: do not blame the plugin. The plugin is good at what it was built to do. The gap is between what it was built to do and what your agency needs from a financial layer. Mapping which of the five gaps map to recurring patterns in your own book of work is the diagnostic exercise. If three or more of them map, the plugin alone is not the end of the tooling story.

Saldo is the analysis layer I built around exactly these five gaps after running into them as CTO of my own 120-person agency for too long. A 15-minute demo runs against your existing Jira and reads worklogs from whatever source your team is on today — native Jira, any time-tracking plugin, or a mix — with the real margin on two recent projects in front of you by the end of the call. No card details up front, no follow-up if it does not land. The five gaps are why most agencies that adopt Saldo do so despite the higher subscription line. The gaps are why it pays back.