When the Financial Plugin Needs Another Plugin to Function

There is a class of conversation I have had often enough with agency CFOs that I now recognise it within the first two minutes. The CFO has just signed off the renewal of a Marketplace financial plugin. The plugin promised cost-rate tracking, project budgets, billing rates, even portfolio rollups. Six months later, it is still not producing useful margin reports. The CFO asks the engineering side what is going on. Engineering says the plugin doesn’t see the team’s worklogs because the team hasn’t moved off native Jira time-tracking yet. The CFO discovers, sometimes for the first time, that the financial plugin was never going to read the team’s worklogs on its own.

The financial plugin needs another plugin to do the work it was sold to do. It needs the agency’s time-tracking to live in a specific companion plugin’s UI. Until that happens, the financial plugin is a dashboard with no inputs.

This is not a bug. It is the architecture, by design, of several leading financial plugins on the Atlassian Marketplace. It is the single biggest source of the “why didn’t our financial plugin work” conversation I have ever heard at agency level.

How the architecture works in practice

Most agencies, before any financial tooling, log hours in Jira’s native time-tracking field. An engineer opens a ticket, clicks “Log work”, types “3h” and a description, hits save. The worklog lives in the issue. It is queryable through Jira’s REST API. Anyone with the right permission can see it.

The leading financial plugins on the Marketplace have, in many cases, decided not to read those native worklogs. Instead they built their own data plane — their own timesheet UI, their own approval workflows, their own data store — either inside their own time-tracking plugin or as a tightly-coupled integration with a specific time-tracking partner. The financial plugin reads from that data plane, not from native Jira.

This decision had business reasons on the vendor side: a paired time-tracking and financial product produces a higher per-user spend, deeper lock-in, and a richer data structure to build features on top of. It is a coherent strategic move at the vendor level. The cost of that decision lives at the customer level.

For the customer, the practical implication is that the financial plugin’s value is gated by every hour-logging team member migrating to the companion timesheet UI. Until that migration is done, the financial plugin reports something close to zero data. After it is done, the agency has two new operational realities to live with: a per-user time-tracking subscription, and a workflow where engineers log hours through a different surface than the one they have been using for years.

What the migration actually involves

The marketing version of the migration sounds like “just have the team start using the new timesheet”. The operational version is about six weeks of work for an agency of any size, with a long tail of edge-case fixes for another month or two.

In the agencies I have watched go through this, the migration breaks down roughly as follows. Two weeks of evaluation, configuration and pilot with a small team. Two weeks of rollout to the wider team, with workshops, written instructions and a mandatory cut-off date for the old time-tracking. Two weeks of handling the edge cases — engineers who logged half their hours in the old surface and half in the new, integrations with downstream tools that broke, subtle reporting differences that surface as everyone reconciles their first month-end on the new system.

For a 100-person agency this is roughly 200–400 person-hours of operational time. At an internal rate of £100 an hour blended, that is £20K–£40K of actual people-cost on the migration alone. None of that appears on the financial plugin’s invoice.

The longer-tail cost is cultural. Engineers who liked the simplicity of native Jira time-tracking are now logging hours through a busier UI. Project managers who could glance at issue worklogs in Jira to see status now have to context-switch to the companion plugin. The line of friction between “the team gets work done” and “the team logs the work” widens, and the rate of mis-logged or unlogged time often gets worse, not better, in the first quarter on the new system.

The full TCO at three common sizes

The financial plugin’s sticker price is the small line in the total. Plug in real Marketplace pricing and the picture changes.

For an agency of 50 production staff, the financial plugin alone runs about £110 a month at typical Marketplace rates. The companion time-tracking plugin runs about £195 a month. Combined: £305 a month, or £3,650 a year. Add the migration cost — six weeks of operations work plus team disruption, modelled honestly — and the first-year TCO is closer to £15–18K. The financial plugin’s subscription is roughly 10% of the first-year cost.

For 100 staff, the same maths runs to about £610 a month combined (£385 timesheet + £225 financial), or about £7,300 a year. First-year migration cost £20–40K. Total first-year TCO: roughly £25–40K. Subscription is again a fraction of total.

For 200 staff, the combined subscription runs about £1,020 a month, or about £12,200 a year. Migration of 200 hour-loggers is significantly costlier — we have seen it land between £40K and £70K in real outcomes. First-year TCO: roughly £45–65K. Subscription is about 20% of total.

Across all three sizes, the financial plugin’s sticker price is the small share of the first-year cost. The bigger share is the migration of the team to the companion timesheet, and the operational disruption that comes with it. A renewal conversation that focuses only on the subscription line misses where the money actually went.

Where this leaves the CFO

Three patterns I have watched consistently in the conversations after a CFO realises the architecture.

The first pattern is acceptance. The migration has happened, the team is on the companion timesheet, the financial plugin is producing reports. The combined stack is more expensive than expected but the agency lives with it. The remaining question is whether the financial plugin’s reports are answering the questions the CFO actually has — pre-sold contract tracking, overhead allocation, three project types, role-mismatch detection, manager view. In every case I have seen, the answer is no. The plugin gives cost-rate-times-hours per project. It does not give margin including overhead, it does not separate Development from Support from Internal, and it does not surface where margin is actually moving.

The second pattern is reversal. The migration was painful, the financial plugin is in place, the reports are not what the CFO needs. The agency keeps the time-tracking plugin (the team is on it now) and looks for a separate analysis layer that reads worklogs from any source — native or plugin — and adds the analysis that the financial plugin does not deliver. This is the position from which most agencies arrive at Saldo, ironically: not as a replacement, but as the layer the financial plugin’s architecture made impossible to build into the plugin itself.

The third pattern is avoidance. The CFO discovers the architecture before signing the renewal, or before signing the original contract. The agency stays on native Jira time-tracking, looks for an analysis layer that reads native worklogs directly, and skips the migration cost entirely. This is rarer because most CFOs do not discover the architecture until well into the engagement, but it is the position with the lowest total cost of ownership by a wide margin.

There is also a fourth, less common pattern: agencies that signed the financial plugin and the companion timesheet, completed the migration, and then discovered — eighteen months in — that the team has been steadily logging fewer hours than it works. The companion timesheet’s extra friction has compressed the worklog volume by between 8% and 12%, which means the cost-rate-times-hours number the financial plugin reports is systematically lower than the cost the agency is actually carrying, and the “margin” the plugin reports is correspondingly inflated. The fix in this fourth pattern is not a different tool. It is rebuilding the team’s relationship with hour-logging, which is a slow piece of cultural work that has nothing to do with the tooling that triggered it.

What we built around this on Saldo

Saldo’s architecture was a deliberate response to having watched these conversations from the inside. We built Saldo to read worklogs from any source: native Jira time-tracking, any time-tracking plugin’s worklogs, or a mixed environment where part of the team is on one and part on the other. The agency’s choice of how the team logs hours stays with the agency.

The connection is read-only. We pull worklogs, issues, epics and statuses through the standard Jira REST API. We do not write back to Jira, and we do not require any plugin to be installed on the Jira side. The setup is fifteen minutes once the credentials are in hand. The team continues logging hours exactly the way they do today.

This is not the only valid architecture — there are agencies whose operational reality genuinely benefits from a unified timesheet plugin, and the maths can work out fine for those agencies. But for the much larger group of agencies whose first encounter with the architecture was discovering it mid-engagement, the read-only-on-top-of-native pattern is the lower-cost path.

What to ask before signing a financial-plugin renewal

If you are about to renew a Marketplace financial plugin, three questions worth asking before the signature.

The first question is structural: does this plugin read native Jira worklogs, or does it require our team to log hours through a specific companion timesheet? The answer determines whether the plugin’s value depends on a migration the agency may or may not have completed. Most financial plugins’ documentation answers this directly if you know to look for it — the integration matrix or supported worklog source list is the right page.

The second question is forward-looking: what does the migration cost in operational time? Six weeks of operations work for a 100-person agency is the reasonable estimate. If your team is mid-migration today, the cost is already spent and the question is whether the plugin’s analysis layer is worth keeping. If the migration has not started, the cost is in front of you and the plugin’s subscription line understates the commitment.

The third question is about gaps the plugin does not address even after migration: pre-sold contract tracking, overhead allocation, three project types, role-mismatch detection, manager view. If those gaps map to margin patterns your agency feels — and at most agencies above 50 staff they do — the financial plugin alone is not the end of the procurement journey.

The honest version of this article: the architecture matters more than the price. A £225-a-month financial plugin that needs a £385-a-month companion plugin and a six-week team migration is a different commitment from a £2,499-a-month flat-fee analysis layer that reads what the team is already logging. Comparing them on subscription alone misses where the money is actually going.

If you are looking at the renewal page right now and the architecture surprised you, see your own saldo is the next step we would offer. A 15-minute demo on your live Jira reads whichever worklog source your team is on today — native, plugin or a mix — and gives you the real margin on two recent projects by the end of the call. No card details up front, no follow-up if it does not land.