Why SaaS Cost Allocation Is a Growing Problem
Five years ago, software purchasing was simple. IT selected the tools, finance paid the invoices, and costs sat neatly in a single budget line. That era is over. Today, the average company spends $4,830 per employee per year on SaaS (up 21.9% year on year, according to Zylo's 2025 SaaS Management Index), and purchasing authority has spread to nearly every department. The result: finance teams are left trying to allocate costs across business units using spreadsheets, guesswork, and an uncomfortable amount of manual reconciliation.
SaaS cost allocation is the process of assigning software subscription expenses to the departments, teams, or cost centres that consume them. When done well, it drives accountability, improves budget accuracy, and gives department heads the visibility they need to make informed decisions about their tooling. When done poorly (or not at all), it creates blind spots that compound with every new subscription.
The shift from centralised IT to department-led buying
In most scaling companies, 70% of SaaS purchases now originate outside IT. Marketing buys its own analytics suite. Sales procures its own engagement tools. Engineering subscribes to developer platforms on a team credit card. This decentralisation is efficient for speed but catastrophic for cost visibility. When 82% of executives report significant increases in cloud and SaaS costs, the root cause is rarely a single runaway contract. It is dozens of independent purchasing decisions, each rational in isolation, that nobody aggregates into a single view.
What happens when nobody owns the cost
Without a formal allocation model, SaaS costs typically sit in one of two places: a catch-all "Software" line in the IT budget, or scattered across dozens of expense reports and corporate card statements. Both approaches create the same problems. Department heads cannot see their true cost of operations. Finance cannot produce accurate departmental P&Ls. Budgeting becomes guesswork because historical spend data is unreliable. And when renewal season arrives, nobody knows which team actually uses the tool, let alone whether it delivers value. Research suggests that shadow IT alone can inflate actual SaaS costs by 20 to 40% beyond budgeted amounts, precisely because these subscriptions are invisible to the allocation process.
Showback vs Chargeback: Which Model Is Right?
Before building an allocation model, you need to decide how costs flow through the organisation. The two dominant approaches are showback and chargeback, each with distinct trade-offs. The right choice depends on your company's maturity, culture, and appetite for change.
| Dimension | Showback | Chargeback |
|---|---|---|
| How it works | Costs are reported to departments but remain on a central budget | Costs are formally transferred to each department's P&L |
| Accountability level | Awareness only; no financial consequence for overspending | Full ownership; department heads are responsible for their software line |
| Implementation effort | Low to medium; requires a reporting layer but no GL changes | Medium to high; requires GL mapping, approval from finance leadership, and cross-functional buy-in |
| Best for | Companies introducing cost visibility for the first time, or where data quality is still improving | Organisations with mature financial processes that need departmental P&L accuracy |
| Risk | Departments may ignore reports if there is no financial consequence | Can create friction if allocation methodology feels unfair or opaque |
| Time to value | Weeks (generate reports from existing data) | 1 to 3 months (requires GL integration and stakeholder alignment) |
Showback: visibility without accountability
A showback model tracks SaaS consumption by department and presents cost reports, but no money actually changes hands between budgets. The central IT or finance team still owns the expense line. This approach works well as a starting point because it builds awareness without creating political friction. Department heads see their software costs for the first time, which often triggers voluntary optimisation: cancelling unused tools, consolidating duplicates, or renegotiating contracts. The limitation is that without financial consequence, some departments treat the reports as informational rather than actionable.
Chargeback: full P&L ownership by department
A chargeback model formally allocates software costs to each department's budget. The expense appears on their P&L, their budget utilisation metrics reflect it, and they are accountable for managing it. This is the model that drives lasting behavioural change because it ties software decisions directly to financial outcomes. The trade-off is implementation complexity: you need clean data, agreed allocation keys, GL integration, and executive sponsorship. If any of those elements are weak, the model will face resistance.
Hybrid models and when to use them
Most companies at the 100 to 500 employee stage benefit from a hybrid approach. Charge back tools that are clearly department-owned (Figma to Design, HubSpot to Marketing, Salesforce seats to Sales). Show back shared infrastructure tools (Slack, Google Workspace, Zoom) that serve the entire organisation. This gives department heads ownership of the costs they can actually influence while avoiding contentious debates about how to split a companywide Slack bill across 12 teams. Over time, as your allocation methodology matures, you can move shared tools into the chargeback model using headcount-based or usage-based keys.
Building a SaaS Chargeback Model: Step by Step
A chargeback model has four components: tool classification, allocation keys, reporting cadence, and GL integration. Get these right and the model runs itself each month. Get them wrong and you will spend more time defending the numbers than acting on them.
Step 1: Classify every tool as shared, department-owned, or hybrid
Start with a complete inventory of your SaaS subscriptions. For each tool, assign one of three classifications:
- Department-owned: Used exclusively by one team. Examples: Figma (Design), Salesforce (Sales), Marketo (Marketing). The full cost is allocated to that department.
- Shared: Used across the entire organisation with no dominant department. Examples: Slack, Google Workspace, Zoom. Costs are split using a predefined allocation key.
- Hybrid: One team is the primary user, but other teams have meaningful usage. Examples: Notion (Product owns it, but Marketing and Engineering use it too). Costs are split proportionally.
If you are running Cledara, this step is significantly easier because every subscription has its own virtual card, which means spend is already attributable to a specific tool. Cledara's expense code mapping lets you tag each tool with its department, cost centre, and GL code from the moment it is purchased.
Step 2: Choose your allocation keys
An allocation key is the formula that determines how shared or hybrid tool costs are divided. The right key depends on the tool and what best approximates actual consumption.
| Allocation Key | How It Works | Best For | Example |
|---|---|---|---|
| Per-seat / per-licence | Cost divided by number of active licences per department | Tools with named-user licensing | Salesforce: 40 Sales seats, 5 CS seats = 89% Sales, 11% CS |
| Headcount ratio | Cost split by each department's share of total headcount | Companywide tools with flat-rate pricing | Slack: Engineering is 30% of headcount, so Engineering bears 30% of the Slack cost |
| Usage-based | Cost split by actual consumption metrics (API calls, storage, active hours) | Tools with measurable per-user or per-unit usage data | AWS: allocated by compute hours consumed per team |
| Flat allocation | Equal split across all departments | Low-cost shared utilities where precision is not worth the effort | A $50/month password manager split equally across 5 teams = $10 each |
A practical rule of thumb: use per-seat allocation for any tool with named-user licensing, headcount allocation for flat-rate companywide tools, and usage-based allocation only when reliable consumption data is available. Do not over-engineer the model. A slightly imprecise allocation that everyone understands is better than a theoretically perfect formula that nobody trusts.
Step 3: Set up monthly allocation reports
With classifications and keys in place, build a monthly report that calculates each department's allocated SaaS cost. The report should include: the tool name, vendor, total monthly cost, allocation key used, each department's share (percentage and absolute amount), and a month-over-month trend. Distribute this report to department heads within five business days of month-end close, aligned with your existing budget reporting cadence.
If you are operating a chargeback model, these numbers need to reconcile with your GL. If you are running showback, the report can be lighter, but it must still be consistent and timely to maintain credibility.
Step 4: Integrate with your GL and budgeting process
For a chargeback model to function in practice, every SaaS transaction needs to flow into your general ledger with the correct department code, cost centre, and expense category. This is where most manual chargeback processes break down: someone has to review each transaction, look up the allocation, calculate the split, and post journal entries. At 50+ subscriptions, this becomes a full-time job.
Cledara's accounting integrations with Xero, QuickBooks Online, and NetSuite solve this by mapping each subscription to the correct GL code, department, and cost centre at the point of purchase. When the virtual card is charged, the transaction syncs to your accounting platform automatically, pre-categorised and pre-allocated. There is no monthly reconciliation sprint. For companies not on one of those platforms, Cledara's white-label accounting feature standardises your financial data in its own format, so the allocation logic still applies.
The final piece is connecting allocation data to your budgeting cycle. Cledara's Budgeted Spend feature projects future SaaS spend per department based on historical payment data. This means your next budget round starts with an accurate baseline rather than a best guess, and department heads can see projected overruns before they happen.
SaaS Cost Allocation Pitfalls
Even well-designed chargeback models can fail. Here are the most common mistakes and how to avoid them.
- Starting with chargeback before your data is clean. If your subscription inventory is incomplete or your usage data is unreliable, departments will challenge every number. Run a showback phase first to validate your data. Fix discrepancies before making the numbers consequential.
- Over-engineering allocation keys. A model with 15 different allocation formulas is a model that nobody maintains. Standardise on three to four key types (per-seat, headcount, usage-based, flat) and apply them consistently.
- Ignoring shared tools. If you only charge back department-owned tools, you miss 20 to 40% of total SaaS spend. Shared tools need an allocation method too, even if it is a simple headcount split.
- No executive sponsor. Chargeback changes how money flows through the organisation. Without a CFO or VP Finance championing the model, department heads will resist. Secure top-down support before rollout.
- Set-and-forget allocation. Teams grow, tools change, and new subscriptions appear every month. Review your allocation model quarterly. Add new tools, retire cancelled ones, and adjust keys when headcount shifts significantly.
- Pooled credit cards that obscure attribution. If five departments share one corporate card for SaaS purchases, untangling which team owns which charge is painful. This is one reason companies adopt virtual cards per subscription: spend is automatically attributable from day one.
How Cledara Automates Cost Allocation
Manual cost allocation works when you have 10 subscriptions. At 50 or 100, it becomes a bottleneck. At 200+, it is unsustainable. Cledara eliminates the manual work at every stage of the allocation process.
- Virtual cards per subscription ensure that every SaaS payment is automatically tied to a specific tool and team. No more pooled card statements to untangle. When your analytics platform charges $2,400 this month, Cledara knows it is HubSpot, it belongs to Marketing, and it maps to GL code 6200.
- Expense code mapping lets you assign each tool to the right expense category, department, and cost centre. This mapping is the foundation of your chargeback model, and Cledara enforces it from the moment a subscription is created.
- Accounting integrations with Xero, QuickBooks Online, and NetSuite sync transactions automatically with the correct categorisation. The monthly allocation report that used to take hours of spreadsheet work becomes a real-time view.
- Budgeted Spend forecasting projects future SaaS costs per department based on actual payment history. This gives finance teams an accurate baseline for budget planning and helps department heads spot cost overruns before they materialise.
- Accounting Records for companies not on a supported platform standardises financial data so allocation logic applies regardless of your accounting stack.
The net effect: Cledara customers report saving 13+ hours per month on SaaS administration tasks, and the average customer achieves a 23% reduction in overall SaaS costs once they have full visibility and control over their software spend. Book a demo to see how Cledara automates cost allocation for your organisation.
Downloadable Template: SaaS Cost Allocation Spreadsheet
To help you get started, we have built a free SaaS cost allocation template that you can use to implement a showback or chargeback model manually. The template includes: a subscription inventory sheet with classification columns, an allocation key reference table, a monthly allocation calculator with per-department breakdowns, and a summary dashboard showing spend by department over time.
Download the free SaaS cost allocation template here.
The template is a solid starting point for companies with fewer than 50 subscriptions. As your SaaS stack grows beyond that, the manual overhead of maintaining the spreadsheet typically outweighs the cost of automating the process with a purpose-built platform.




