Software purchase order: regaining control of SaaS spend

A product team needs a new subscription, calls its international vendor, hands over the department's corporate card, and the tool is live within the week. No purchase order crosses that transaction. Finance does not see the entry on the day it happens, because a SaaS invoice paid by card does not carry an order number on the line. It surfaces, weeks later, inside the card statement, unable to say which project it belongs to. Survey data cited by IBM on SaaS sprawl counts 48% of enterprise applications with no named owner monitoring and auditing usage, security, licenses and renewals. That number describes precisely the gap: the tool runs, nobody owns it, and the cost is only discovered when the month closes.

The company does not have a budget problem. It has an execution problem. The root of a software purchase without a purchase order is not missing budget; it is the absence of a purchase order mandate at the exact point where the purchase happens. When that point exists and is central, the subscription is only contracted after it is approved, budgeted and recorded. What remains to show is why the purchase order matters precisely when the license is already running, how a single central buying point closes the procedural gap the decentralized path keeps open, and what the procurement team of a large company builds today, concretely, to close that gap.

The cost of buying software without a purchase order in a large company

Buying software without a purchase order creates a specific kind of spend that finance discovers late, in a block, unable to reconcile it. On the default path each area pays for its own software with the department card, with no catalog, no approved vendor and no reference value. The sum of those subscriptions is the shadow software spend, the shadow IT software that stays legitimate in use and invisible in control.

The cost has three layers, and the first is the most obvious. The forgotten subscription, the seat nobody uses and the renewal a team signs without reviewing it become recurring expense that runs through the year unseen. The second layer is price. Whoever buys alone does not negotiate with volume and holds no reference value, so they pay the full vendor catalog. The third is currency and the structure of the operation, because much essential software is international and the invoice lands in a foreign currency carrying an embedded cost layer that the area that signed it does not size up. The first layer can be attacked with inventory alone. The last two depend on centralizing contracting at the point where the order enters.

This is where the metric that settles the discussion arrives: the total cost of a foreign SaaS, which is almost always higher than the price on the vendor's proposal. The point of control does not exist to shrink the toolbox. It exists so that every item enters with a number, an owner and a reviewed price on the side of whoever pays. Control of unauthorized software spend starts at this point.

Why the purchase order matters when the subscription is already running

The software purchase order is an old instrument and a precise mechanism. It exists to turn the intention to spend into a recorded commitment before payment, with value, currency, cost center and term all defined. In software that role carries a weight almost no other purchase has, because the decisive moment is not the first transaction. It is the continuity.

The subscription goes live and starts renewing in silence. The user re-approves nothing every month. The risk is not the initial purchase, which at least has a conscious request behind it; the risk is the recurring line that keeps living after the contract turns, the automatic renewal that consumes budget the team has already forgotten. The silence is the risk. When no purchase order ties that cost to an owner and an approved budget, the vendor's calendar decides whether the expense continues, not the company's budget cycle.

An active purchase order, with its value and its expiry date, changes that math. Renewal stops being automatic by omission and starts depending on a new approval. The mandate cannot arrive later, at the close. It must exist first, at the instant the order crosses the front door. That is the change in behavior that SaaS procurement governance demands.

The single central buying point closes the gap a purchase order alone cannot reach

A written purchase order that is not executed is paper. The instrument only becomes a control when there is a single, mandatory place through which every software contract passes. At that point the purchase order stops being a recommendation and becomes a condition: without an approved order number, the tool does not enter the contracting queue.

On the default decentralized path that place does not exist. Each area owns its own card, its own vendor and its own flow, and a policy stating that every purchase needs a purchase order applies to a process with nowhere to enforce it. That is the difference between a rule and a point where the rule is actually applied. Centralizing acquisition at a single physical point, on the side of the company that consumes the software, is what converts the mandate into execution. Rule without a point is not executed.

Concentrating the purchase at one gateway delivers the traceability the scattered path never gave: every order enters with a number, every payment leaves against a number, and every renewal confronts the previous number. The correct comparison is always against the default path, never against another provider. The choice is between a purchase that passes one central approval point and a purchase that happens across dozens of points with no mandate at all.

The image below shows the two routes side by side for the same software request: the path without a purchase order, in which payment leaves without approval, and the path with a purchase order at the point of control, in which spend is only released after it is approved, budgeted and recorded.

The controls a central buying point puts under the procurement desk

Concentrating contracting at one point is not simply creating a queue. It is giving procurement instruments that, scattered across an area and a card, simply do not exist. When all of a large company's software contracts through the same point, four controls come to apply to every single item.

The first is approval authority: who requests, who authorizes, and how much each level may approve are defined and recorded before the order leaves. The second is budget, with the check, at order time, of whether allocation still remains for one more license before the subscription is signed. The third is renewal, with the alert that forces a new decision before the line renews in silence. The fourth is invoice and currency, because the local invoice that reaches finance is issued in reais and in local currency, with tax and exchange calculated per transaction, instead of the area discovering the currency effect later. Every subscription now has an owner.

For a company on the Lucro Real regime, the standard Brazilian income tax regime for large enterprises that credits PIS/COFINS, the domestic invoice also enables recovery of that credit, the 9.25% that a path without a domestic fiscal document tends to leave behind. For a company on the Lucro Presumido regime, the simplified Brazilian regime in which taxable income is presumed by law, the benefit is not the credit; it is the invoice in reais, the exchange rate lock and the operating simplification that a per-area card does not offer. None of this is the center of this piece, which is governance and purchase order discipline, but it shows how the point of control also unlocks levers used to reduce international software costs without reopening the whole purchasing policy.

How a large company's procurement team builds the control today

Turning software spend without a purchase order into a governed operation does not start with buying the largest platform on the market. It starts with five sequential decisions that the procurement team makes and implements together with finance. First the policy, then the platform.

1. Establish the written mandate: every software contract and every renewal passes through an approved purchase order, with no exception by area or by card.
2. Designate a single execution point: one central, physical gateway for software contracting through which any request must pass.
3. Tie renewal to the decision cycle: make the license expire along with the purchase order, so that renewal depends on a new approval.
4. Give visible allocation: check at the order whether budget remains before releasing the subscription, so that spend only leaves against a number.
5. Reconcile by number each month: match every invoice that reaches finance to its corresponding purchase order, instead of hunting the origin of an entry at the close.

The column below summarizes the default state and the single gateway state, for a one-page read.

That design is executable because it does not rely on watching each area from the outside. SaaS procurement governance becomes a consequence of the entry point, not a monthly policing effort.

The behavior that changes in the contracting client

Adopting this control is, before anything, a change in the behavior of whoever buys the software, not an exercise by whoever contracts today. The team that used to sign with its own card learns to route its request into the single gateway, with the vendor already mapped and the price already known. The practical difference shows at the first renewal: the tool does not renew itself. It asks permission.

For software procurement in a large company, the apparent cost of a mandate like this, which seems to add a step to every order, pays for itself in the other direction. Whoever requests a license stops hunting for an approval buried in a card and gains one that finance recognizes. Whoever pays stops making course corrections at the close and sees the spend on the day it is approved.

A representative number helps size the situation. A company that contracts a few dozen SaaS contracts and renewals per quarter, part of them international, and without a purchase order, tends to carry a permanent plateau of orphan subscriptions and a renewal swing that shows up only in the monthly reconciliation. When the same contracting enters through a single point, what was a problem discovered at month-end turns into a known line of decision. The values here illustrate a typical corporate spend scenario; they are not the account of any one specific company.

The market context confirms the direction. In August 2026 an official announcement began allowing buyers to require a mandatory purchase order before registering a subscription in a relevant cloud marketplace, with guidance messages steering the buyer before payment, a sign that control over software spend is moving to the exact point where the purchase happens. It is not a recommendation to imitate that feature. It is corroboration that treating the purchase order as a control and the guidance as a policy is the direction the market itself already follows. The complete reference appears in the final section.

Frequently asked questions

What is software spend without a purchase order?

It is the contracting of software, usually a subscription or a renewal, that happens without an approved purchase order. On the default path it enters through each area's card, with no order number. No approved number exists here. Finance only notices the spend when the card statement closes.

Is each area's card the problem?

The problem is not the card itself. The problem is that the card does not force a purchase order at the point where the subscription is made. The PO mandate and a single central buying point exist so that the per-area card stops being the uncontrolled acquisition path.

Is a policy that requires a purchase order enough?

A policy works only when a single point exists through which contracting must pass. Without that point, every area keeps its own flow and the rule has nowhere to be enforced in practice. The written mandate and the execution point go together.

Is software spend governance the IT team's job or finance's?

It is a joint decision of procurement, finance and IT leadership, because it involves who requests, who approves and who reconciles. The design usually starts in the procurement team and needs finance to match every invoice to a purchase order.

References and further reading

The definition of SaaS sprawl and the figure of 48% of applications with no named owner, with decentralized procurement cited among the causes, come from the reference entry by IBM on SaaS sprawl. The market context on mandatory purchase orders in a cloud marketplace comes from the official AWS Marketplace announcement of August 2026, used only as a sign that control over software spend is migrating to the point of purchase. The two blog posts cited in the body, on calculating the total cost of a foreign SaaS and on reducing international software costs, are linked in the section where each supports the argument.

How to take software purchase governance to the next procurement meeting

Software spend without a purchase order is not resolved by a platform installed overnight. It is resolved by the sequence of decisions that a procurement team can already validate at the next meeting, starting with the smallest and cheapest step: mapping how many active subscriptions and renewals today carry no purchase order behind them.

With that inventory on the table, the decision trigger is the same for every line. If a subscription is active and renewing without a purchase order, it is proof of the hole in the process, not a case to normalize in a hurry. Once the written policy is approved, the following step is to name the single point through which all contracting passes, so that the purchase order stops being a statement and becomes the entry requirement. Then, tie renewal to the expiry of the order and verify allocation before releasing any request.

The Nexforce Marketplace answers exactly this need on the buying side: it is the single contracting point through which software enters with an invoice in reais, in local currency, and the approval authority, budget and renewal controls that the default path lacks, on a procurement platform that integrates invoice and card processing. The concrete next step is to take the inventory of software purchased without a purchase order to the meeting and decide, from that inventory, which gateway the company will adopt. It is that small, executable gesture that turns the written governance policy into real spend control. That gesture closes the hole.