Why software ownership is the problem behind the problems
Ask a finance team "who owns this tool?" about any subscription and you'll usually get a pause, then a name, then a correction. The person who signed up left last year. The card it's on belongs to someone in marketing. The admin login is in a password manager nobody has opened since the migration. That pause is software ownership, or rather the lack of it, and it sits underneath most of the software admin problems finance deals with.
Missed renewals, invoices that never arrive, leavers who still have access, tools bought twice by two teams: these look like separate problems. They aren't. Each one happens because no single person was responsible for that tool, so nobody noticed. Fix software ownership and most of the rest gets a lot easier.
Key takeaways
- Software ownership means one named person is accountable for each tool: its users, its cost, its renewal and its invoice.
- Across Cledara's customers the median company pays for 32 software tools, and the top quarter pay for 48 or more. That's too many for finance to own alone.
- The owner should be the budget holder for the team that uses the tool, with finance and IT in clear supporting roles.
- Ownership decays. People change roles and leave, so the owner field needs maintaining like any other record.
- A one-page ownership model, applied once, prevents most surprise renewals and missing invoices.
How software ownership got lost
Not that long ago, IT bought software. There was a procurement process, a licence agreement and a server. If you wanted a tool, you asked IT, and IT owned it in every sense: the contract, the admin login and the renewal.
Then software moved to the browser and started accepting credit cards. Anyone could start a subscription in a couple of minutes, and plenty of people did. That's a good thing (teams got the tools they needed without waiting), but it moved buying across the whole company while the idea of an owner stayed behind in IT.
So the person who set up the tool became the owner by accident. They never agreed to track its renewal or forward its invoices. When they moved teams, nobody handed the tool on. When they left, their card got cancelled and the tool went down, or worse, kept quietly billing a card nobody checked. We see this pattern in companies of every size. An operations lead we spoke to recently described tools scattered across staff with different owners, and said missed renewals and duplicate subscriptions had happened more than once.
What goes wrong when nobody owns the tool
The symptoms are familiar to anyone who has run month-end. They're all downstream of the same gap.
- Renewals fire without a decision. The notice period passes because the reminder went to someone who left, and you're tied in for another year.
- Invoices go missing. The invoice sits behind a login that only one person has. Finance chases, the person is busy, VAT goes unreclaimed and the books close late.
- Leavers keep access. With no owner to remove them, former employees stay in tools for months, and you keep paying for their seats.
- Teams buy the same thing twice. Two departments each sign up for an e-signature tool because neither knew the other had one.
- Finance can't get in. We regularly hear from finance teams who can reach the admin area of only a small fraction of their applications. Everything else needs a favour from a colleague.
Every one of these costs money, and every one of them costs time, which is the part people underestimate. Hours spent chasing a colleague for an invoice are hours not spent on the forecast.
Who should own software in a growing company
The answer is the budget holder for the team that uses it. Finance owns the process. IT owns security and access. The team lead owns the tool.
That split works because it puts the decision with the person who knows whether the tool is still useful. Finance can see that a design tool renews in March, but only the head of design knows whether the team still uses it, whether 14 seats is right, and whether the pricing tier makes sense. Asking finance to make that call is asking them to guess.
Here's the model in one table. It's deliberately short; the point is that every tool has exactly one name in the first row.
| Role | Owns | Does not own |
| Application owner (team lead or budget holder) | Whether the tool is still needed, seat count and tier, confirming the renewal decision, approving new users, making sure the invoice reaches finance | Payment, accounting codes, security review |
| Finance | The list of tools, renewal dates and notice deadlines, budget and price checks, payment and invoice matching, approving the owner's renewal decision | Deciding whether a tool is useful, managing user access |
| IT or operations | Security and compliance review, who has access to what, removing leavers, SSO and integrations | Budget decisions, renewal negotiation |
| Everyone else | Requesting tools through one route, telling the owner when they stop using something | Signing up for tools on personal cards |
If you only have time to do one thing after reading this, add an owner column to whatever list you keep of your software, and fill it in.
How to assign software owners in five steps
This takes an afternoon for most companies, and it pays back the first time a renewal comes around.
- Build the list from payments, not memory. Pull twelve months of card and bank transactions and list every vendor. Cledara data shows the median company pays for 32 software tools, with the top quarter at 48 or more, and most people guess lower than the real number.
- Name one owner per tool. Default to the budget holder for the team that uses it. If two teams use it, pick the one that pays. No shared ownership; shared means nobody.
- Write down what the owner is responsible for. Use the table above or your own version. Send it to every owner once, in plain words.
- Give owners a reminder they'll actually see. A renewal reminder 90 days out, sent to the owner and to finance, is the single most valuable automation in software management. Our renewal management guide has a full timeline.
- Maintain it. When someone changes role or leaves, reassign their tools the same week. An owner field that was accurate a year ago is a liability, because people trust it.
Ownership and the leaver problem
The leaver case deserves its own paragraph because it's where ownership gaps get expensive fastest. When a tool owner leaves, three things happen at once: their reminders stop being read, their card stops working, and their admin access becomes a locked door. If the tool was paid on a card in their name, the subscription fails or is quietly moved to someone else's card without the renewal terms being looked at.
This is one reason we built Cledara around a virtual card per subscription rather than per person. The card belongs to the tool, so when the owner changes, the payment doesn't break. It's also why Cledara keeps the owner against each tool and lets you reassign in one place when someone moves on. We've written more about the costs of unmanaged offboarding in our piece on the true cost of shadow IT.
Where this is heading
I think software ownership is about to get a lot less painful, for a simple reason: the repetitive part of it is exactly the kind of work machines are now good at. Collecting an invoice from a vendor's billing page, removing a leaver from every tool they had, flagging a paid seat nobody is using: none of that needs a human, and none of it needs the owner's attention.
What still needs a human is the decision. Is this tool worth renewing? Do we need the higher tier? That's the bit the owner is for, and it's a much better use of a team lead's time than hunting for a PDF. Cledara Agent already does the collecting and the removing inside 8,000+ SaaS and AI tools, with the owner approving each change (or setting a standing approval for routine jobs). The owner stays accountable. They just stop doing the admin.
So name your owners this week. Give them the short list of responsibilities, a reminder they'll see, and a system that does the chasing for them. Finance gets its hours back, and the next renewal becomes a decision rather than a surprise.