Managing SaaS spend well means answering five questions with data that reconciles: what actually got charged, what you're contractually committed to, what's been assigned to people, what's genuinely being used, and what decision each renewal deserves. Zluri handles each of these as its own layer, built on the same underlying data. This is the map of how they fit together.
Ask an organization what it spends on SaaS and you'll usually get one number, sourced from wherever was easiest to pull. Ask where that number came from and it dissolves quickly: it's the finance system's view, or the contract spreadsheet's view, or someone's estimate, and those three sources rarely agree with each other.
That's because "spend" isn't one fact. It's five related facts that have to reconcile: the transactions that actually hit your cards and bank accounts, the commitments (contracts, subscriptions, perpetual purchases) those transactions are supposed to trace back to, the licenses those commitments purchased, the usage those licenses actually get, and the renewal decisions where all of it either gets corrected or locked in for another term.
Zluri manages each layer with its own dedicated mechanics, and this piece is the map: what each layer does, how they connect, and where to go deeper on each one.
Layer 1: Transactions, the Ground Truth of What Got Charged
Everything starts with actual money movement, and actual money movement arrives unlabeled. A corporate card line reading "GSUITE_billing_8842" doesn't announce itself as Google Workspace, and a spend total built on unreconciled transactions is confidently incomplete.
Zluri pulls transaction data from connected finance systems (Intuit QuickBooks, NetSuite, Zoho Books, Zoho Expense, Expensify, and others) or through manual CSV upload where no live integration exists. Every transaction then moves through an explicit recognition process:
- Recognised transactions have been matched to a specific application and confirmed as genuinely SaaS-related. Only these count toward the spend dashboard.
- Unrecognised transactions are either not yet mapped or not SaaS at all, and they're deliberately held out of spend totals until mapping happens, so an unidentified charge never silently distorts a figure.
- Archived transactions are confirmed non-SaaS or deliberately excluded from reporting.
Mapping scales through prioritized Transaction Rules (a well-built rule maps every current and future transaction matching a pattern, with full accuracy), followed by Zluri Mapping AI, which runs after every user-created rule and picks up patterns rules didn't catch. It's on by default and can be disabled entirely for organizations that want a fully deterministic, rules-only system.
Two more mechanics keep the ground truth trustworthy. Multi-currency transactions convert into the organization's default currency using the exchange rate in effect on each transaction's actual date, drawn from two decades of historical rate data, not today's rate applied retroactively. And Payment Methods tracks the cards and accounts behind the transactions, with proactive expiry notifications so a lapsing card doesn't silently interrupt billing.
Layer 2: Commitments, What the Transactions Trace Back To
Every legitimate SaaS charge traces back to a commitment, and Zluri models three genuinely different kinds rather than one generic "contract" record:
Contracts carry fixed start and end dates and build toward a discrete renewal decision. Their structure runs deeper than a price and a date: explicit agreement types (Master, Service, SOW, and True Up, which records mid-term expansions as their own traceable events), a document checklist that attaches the actual paperwork proving an agreement's terms, and a bulk PDF upload pipeline where AI-parsed drafts only go live after human review. Full mechanics in how Zluri handles SaaS contract management.
Subscriptions bill on a recurring cycle with no hard end date, which means their risk profile is entirely different: not a missed renewal date, but an unreviewed plan quietly billing forever. Zluri's subscription model handles that with cost amortization options tuned to recurring cycles, precedence rules for when a plan change leaves two license entities active at once, and Auto Adjust, which keeps license quantity synced to what the vendor's own API reports. Full mechanics in how Zluri handles subscription management.
Perpetuals are one-time purchases with no expiry and no renewal decision, tracked separately precisely so they never generate an irrelevant renewal reminder years after being fully paid.
Getting the classification right at the data-model level is what keeps every downstream reminder and report relevant rather than noisy.
Layer 3: Licenses, Where Purchased Meets Assigned Meets Used
Three numbers should describe every license commitment: what was purchased, what's been assigned to someone, and what's genuinely being used. The gaps between those three numbers are where money and risk quietly accumulate: 100 seats purchased, 85 assigned, 60 actually used.
Zluri's license layer tracks both seat-based licenses (priced per person, assignable to an individual) and quantity-based licenses (priced against a vendor-defined metric like messages sent), and runs a continuous optimization engine over the seat-based ones: flagging licenses that are unassigned, still attached to deprovisioned users, unused across a configurable window, or underused against a configurable threshold. Findings flow into optimization playbooks, including the consent-first Request to Forego flow that asks employees before revoking, and savings get reported honestly, with potential savings, estimated wastage, and realized savings kept as three deliberately separate figures.
The full mechanics (the optimization categories, the usage-score model, exclusion rules, and the reclamation workflows) are in how Zluri handles software license management.
The Thread Connecting Every Layer: Cost Versus Spend
The single most consequential design decision across all of this is that Zluri tracks Cost and Spend as two deliberately separate figures.
Cost is a projection derived from commitment terms: rate multiplied by active licenses, recalculated as counts change. Spend is what actually got billed, pulled from the recognized transactions in Layer 1. When they diverge (a contract projecting one monthly figure while real transactions show another), the gap itself is the signal: a license count changed without a corresponding invoice update, or billing simply doesn't match the contracted rate.
Most tools collapse these into one number, which means a billing discrepancy has nowhere to show up. Keeping them separate is what lets a mismatch surface before it compounds across a full term, and it's only possible because the transaction layer underneath is reconciled rather than assumed.
Layer 4: Renewals, Where Everything Converges
The renewal is the moment every other layer exists to inform. A structured notification sequence (renewal warnings at 30, 15, and 7 days, payment-due alerts, a monthly digest, cancel-by sequences for contracts with separate cancellation deadlines) routes each alert to the specific accountable owner: app, IT, or finance.
But timing is the easy half. What makes a Zluri renewal an informed decision rather than a default is what arrives with the alert: the timestamped history of how the license count actually grew (including True Ups recorded as their own events), the optimization data showing how many of those licenses are unassigned, unused, or underused, and the Cost-versus-Spend check confirming the number being renewed matches what's actually been billed. That's what turns "renew the same 100 seats" into "renew 78, because that's what the usage data supports."
Full mechanics in how Zluri handles SaaS renewal management.
Attributing All of It to the Right Team
Spend isn't just an application-level total; it has to roll up to whoever's actually responsible for it. Each application carries its own chargeback setting: cost attributed to licensed users only, to all active users regardless of license, or by a custom split configured for that app. Mapped transactions distribute proportionally by whichever rule applies, then aggregate to the department level, which is what makes a team's spend figure a deliberate allocation rather than an arbitrary one.
Why It Has to Be One System
Each layer alone produces a number; only together do they produce a trustworthy one.
Transactions without commitment records are charges nobody can trace to an agreement. Commitments without license-level tracking are contracts nobody can right-size. License optimization without reconciled spend underneath means acting on projected numbers that may not match what's actually billed. And renewals without all three arriving together default to what happened last time.
That's the design logic of Zluri's spend management model: not four features, but four layers of the same reconciliation, each one checkable against the others. The deep dives cover each layer's full mechanics: transactions and spend, contracts, subscriptions, licenses, and renewals.
Frequently Asked Questions
How is this different from what a finance system already does?
A finance system sees invoices and payments, but it can't connect a charge to an application, a license count, a usage level, or a renewal decision. Zluri's model reconciles the financial layer against the commitment, license, and usage layers, which is where discrepancies, waste, and renewal leverage actually become visible.
Why does Zluri keep Cost and Spend as separate numbers instead of one spend figure?
Cost is a projection from commitment terms; Spend is what was actually billed, from reconciled transactions. Collapsing them into one number gives a billing discrepancy nowhere to appear. Keeping them separate surfaces mismatches (a license change without an invoice update, billing that doesn't match the contracted rate) before they compound across a full term.
What happens to a transaction Zluri can't identify?
It sits in the Unrecognised state, deliberately excluded from spend totals until it's mapped to an application, either manually, through a transaction rule, or by the mapping AI. Holding unidentified charges out of the dashboard is what keeps the headline spend figure trustworthy rather than silently padded with guesses.
Do contracts, subscriptions, and perpetual licenses really need different handling?
Yes, because their risk shapes differ. A contract's risk is a discrete renewal decision on a known date. A subscription's risk is an unreviewed plan billing indefinitely. A perpetual has no renewal at all. Modeling them identically produces reminders that fire when they shouldn't and stay silent when they matter, which trains people to ignore the entire notification system.
Where does license optimization fit into spend management?
Optimization is the layer that compares what's assigned against what's actually used, flagging unassigned, undeprovisioned, unused, and underused licenses continuously. Its findings feed renewal decisions and reclamation workflows, and its savings figures stay honest because they're checked against reconciled spend rather than projections alone.
.svg)
