The software budget and the payroll budget are becoming one line

Open any company’s budget and you’ll find two lines that have never once spoken to each other. One says software: the licenses, the seats, the per-user SaaS that IT signs for. The other says people: the salaries, the headcount the finance team approves one req at a time. Two lines, two owners, two approval paths, two completely different sets of questions you ask before you say yes.

They were separate for one reason, and the reason was true for forty years: a tool and a worker were different kinds of thing. You bought the tool so a worker could use it. Now you can buy a thing that is the worker.

The software budget and the payroll budget are becoming one line. That’s not a slogan about the future of work, it’s a concrete claim about a spreadsheet, and it changes who approves what, what you ask before you buy, and what the word “procurement” even means. This post is about why those two lines were ever separate, what collapses them, and what breaks the day they touch.

Why the two lines were separate in the first place

Start with the dumb version, because we all lived in it. A tool is something a person operates. A spreadsheet doesn’t fill itself in; a CRM doesn’t make the calls; a design app doesn’t ship the design. The tool is leverage on a human’s hands. So the budget logic was clean: you bought capacity (the people) on one line, and you bought leverage on that capacity (the software) on another.

That separation made every downstream decision make sense. Software was bought per seat, because a tool’s value scaled with how many hands touched it. People were bought per role, because a worker’s value scaled with what they could decide and do. Software was IT’s call, does it integrate, is it secure, what’s the per-user price. People were the hiring manager’s call, can they do the job, do they fit, what’s the comp. The two lines never met because the two questions never overlapped.

A tool is leverage on hands. A worker is the hands. The budget split followed the work split.

And the split was load-bearing. It’s why software procurement and hiring are run by different functions, on different cadences, with different paperwork. You don’t interview a SaaS license. You don’t run a security review on a new analyst. The whole apparatus assumes the thing you’re buying is either a tool or a person, and for forty years, it always was.

Then the thing you’re buying stopped picking a side.

The thing that does the work is both

Here’s the shift, stated plainly. An agent is software, it’s a subscription, it runs in the cloud, it integrates over an API, IT can reason about it the way they reason about any other vendor. And an agent is also a worker, it does the job, not the tooling for the job. It reads the inbox and answers it. It doesn’t help someone build the report; it builds the report. It’s not leverage on a human’s hands. It’s the hands.

So which line does it go on?

The naive answer is “software, obviously, you pay for it monthly, it’s a vendor, file it under IT.” And that’s where most companies will start, because the billing looks like software. But watch what that does. The moment you file the agent under software, you’ve quietly hidden the most important fact about it: it’s not making someone faster, it’s doing a unit of work that used to require a hire. You’ll measure it like a tool, seats, uptime, integration, and you’ll completely miss the thing you’d ask about a worker: what did it accomplish, and was it good.

The other naive answer is “payroll, it does a job, treat it like a hire.” That’s closer to the truth and still wrong, because an agent has no salary, no ceiling, no single role. You can run one or a thousand, spin them up for an afternoon and down by dinner, point the same one at sales today and finance tomorrow. Payroll’s whole model, a person, a seat, a fixed cost, a fixed function, doesn’t fit a thing you provision like compute.

The honest answer is the uncomfortable one: it belongs on neither line, because the line that fits it doesn’t exist yet. The two budgets were separate because the work and the tooling were separate. An agent does the work with the tooling fused into one billable thing, so the two budgets fuse with it.

What a merged line actually measures

Once you accept that the agent sits on both lines, you have to decide what the merged line measures, and this is where it stops being an accounting curiosity and starts being a real change.

The old software line measured access: how many seats, at what price, with what uptime. The old payroll line measured capacity: how many people, in what roles, at what cost. Neither of those is the right question for a thing that does work and bills like a utility.

The merged line measures one thing the old two never could put together: cost against work done. Not “how many licenses do we hold” and not “how many heads do we have”, but “what did we spend, and what got accomplished for it.” A unit of outcome, a deal moved, a report shipped, a ticket truly closed, and what it cost to produce, whether the producer was a person, an agent, or a person and an agent together.

This is the part that breaks the old org. The software line never asked “was the work good,” because software doesn’t do work. The payroll line never asked “what did this cost per unit of output,” because you don’t bill a salaried person by the report. The merged line asks both, of the same thing, at the same time, and most companies have no function whose job is to answer it. The person who approves licenses can’t evaluate work quality. The person who evaluates work quality has never approved a vendor. The merge doesn’t just combine two budget lines; it demands a kind of judgment neither old owner was hired for.

So who approves the agent? That’s the real question hiding inside the budget question, and it’s where procurement breaks.

Where procurement breaks

Picture the two approval paths as they exist today, because the break is easiest to see as a collision.

To buy software, you go to IT and procurement. The questions are about the vendor: Is it secure? Does it integrate? What’s the per-seat price and the contract term? You are evaluating a tool you will hand to your people.

To hire, you go to the hiring manager and finance. The questions are about the worker: Can they do the job? What will they own? What’s the cost, and is the role worth it? You are evaluating capacity you will point at a problem.

Now someone wants to bring on an agent that drafts the outbound, qualifies the leads, and books the meetings. Which path? Run it through software procurement and you’ll vet it like a tool, security, integration, price-per-seat, and never once ask the question that actually matters: is its work good enough to put in front of a customer? Run it through hiring and you’ll evaluate the job-fit beautifully and have no framework at all for a “worker” that’s also a multi-tenant vendor with an API and a data-access surface.

Each path is half-blind to the agent, because each path was built to evaluate exactly one of the two things the agent is.

The naive fix is to pick a path and bolt the other path’s questions onto it. Make procurement ask “is the work good?” Make hiring ask “is it secure?” It doesn’t hold, for the same reason the budget lines don’t hold: you’ve got one function trying to do two jobs it was never structured for, with two sets of expertise that don’t live in the same room. The security reviewer can’t grade sales copy. The sales leader can’t read a data-access policy. Stapling the checklists together gives you a longer checklist, not a better decision.

The real fix is to stop treating “tool” and “worker” as the question. The question becomes: here is a thing that will do real work and spend real access, what does it accomplish, and can we trust it with what it touches? That’s one evaluation, not two stapled together, and it needs a place to happen that is neither the old software desk nor the old hiring desk.

The new procurement is a trust decision, not a purchase

So what replaces two approval paths? Not a third checklist. A different question, asked in a different place.

The old software question was can we afford the seats. The old hiring question was can this person do the job. The merged question is the one a manager asks about anyone they delegate to: what will you let it do without checking, and what must it always run past a human first?

That’s not a price negotiation. It’s a trust decision. You don’t grant a new agent the keys to the whole company on day one, the same way you don’t hand a new hire the authority to wire money in their first week. You start it on work where a mistake is cheap and reversible. You watch what it does. You read the output. And as it earns it, as the work proves good and the judgment proves sound, you widen what it’s allowed to touch without asking. Trust is a ladder you climb, not a switch you flip at signing.

This is why the merged budget line and the new procurement path are the same idea wearing two hats. The line measures cost against work done. The path decides how much autonomy that work has earned. Both of them are asking the same underlying thing the old two lines never had to: not “what does this tool cost” and not “what does this role cost,” but “is this thing doing good work, and can we trust it with more?” You only ask that about something that’s both software and a worker. Which is exactly what an agent is.

Suppose, to make it concrete, a company brings on an agent to handle a slice of its sales follow-up. Under the old model it would land on the software line as one more subscription, get vetted as a tool, and disappear into the SaaS sprawl. Under the merged model, it lands as work: it costs something, it produces something measurable, it’s granted a narrow, reversible scope to start, and it climbs, or doesn’t, based on whether the follow-ups it sends are ones you’d be proud to have sent. The cost and the quality and the trust are one decision, reviewed together, owned by someone who can see all three. That’s the line that doesn’t exist on today’s budget. It’s the line that’s about to.

The turn: the person who used to approve both

Here’s the part that isn’t about spreadsheets.

Somewhere in your company, two people have spent years saying yes and no on those two old lines. One vetted the tools, kept the stack sane, the vendors honest, the access tight. The other vetted the people, read the work, judged the fit, decided who got to own what. Both of them were doing a version of the same job all along: deciding what the company should let in, and how much it should trust it. The budget just split that judgment in half and handed each half to a different room.

When the two lines merge, those two halves of judgment have to merge too. And that’s not a loss of work, it’s a promotion of it. The question stops being can we afford the seat or can this person do the job, and becomes the harder, more human one: is this good work, and do we trust the thing that did it? That’s a taste decision. It’s the part of procurement and the part of hiring that a checklist could never reach, the read on quality, the read on trust, the willingness to say not yet, prove it on something smaller first. The merge doesn’t replace the people who held those lines. It finally asks them the only question that was ever worth asking.

The software budget and the payroll budget are becoming one line, and the person standing where they meet isn’t an accountant reconciling two columns. They’re the one deciding what the company is willing to trust with its work. That’s a better job than either of the two it replaces.

---

That’s part of what we’re building at Apollo, a place where the work an agent does, what it costs, and how much it’s trusted to touch all live in one view, because they were always one decision pretending to be two. If you’ve ever stared at a SaaS bill and wondered which of those line items was quietly doing a person’s job, you already feel the two lines starting to touch.