Somewhere in your company right now, a purchase is stuck in an email thread. Someone asked for approval four days ago. Nobody knows whose turn it is. That wait is normal: across more than $30 billion of processed spend measured by Vertice in 2026, the intake stage of a purchase alone averages 10.3 days.

Cloud-based procurement software exists to end that thread.

The short answer

Cloud-based procurement software is a tool, hosted by the vendor and used through the browser, that runs your purchasing cycle in one place: purchase requests, approvals, purchase orders, deliveries, and spend reporting. Nothing installs on your servers. You subscribe, log in, and every purchase leaves an audit trail.

That last part is the real product. Not the forms. The trail.

Already on Jira or JSM? You may not need a new platform: Raley Procurement runs this whole cycle inside the tools you have.

What it actually does

Strip away the category jargon and the job list is short:

  1. Intake. An employee submits a purchase request on a form, not in a chat message. The request captures what, why, how much, and for which budget.
  2. Approval. The request routes to the right people automatically: by department, by amount, or by budget line. No forwarding. No "just following up" pings.
  3. Purchase orders. An approved request becomes a numbered PO, usually a PDF the supplier can act on.
  4. Receiving. Someone records that the goods or services arrived, so finance pays invoices against real deliveries.
  5. Reporting. Leaders see committed spend while it happens, not at month close.

If a tool does those five jobs, it qualifies. Everything else is packaging.

But doing the five jobs is the entry ticket, not the win. The value shows up in how well a tool does three specific things, and this is where products separate.

Where the value actually comes from

Any tool can render a request form. Whether purchasing gets faster and cleaner depends on three steps that happen between "I need this" and "the supplier has the PO".

Step 1: intake that captures decision-quality data

An approver needs five things to say yes quickly: what is being bought, how many, what it costs, why it is needed, and who is asking. A free-text email rarely carries all five, so the approver writes back to ask, and the request ages another day with every round trip.

Good intake fixes this in two ways. First, the form is structured, so a request cannot be submitted with the questions unanswered. Second, the form is customizable: each company adds the fields its own process needs, instead of bending its process to a vendor's fixed template.

The customization matters most to finance and accounting. A finance team will typically extend the request form with its own required fields, for example:

  • Cost centre as a dropdown of the codes finance actually uses, not a free-text box someone can mistype
  • GL account for the expense category the purchase books to
  • Project code when spend is tracked by program or client
  • Need-by date so urgency is stated up front instead of shouted later

One more thing good intake does: it collects every request into one queue. When requests arrive by email, chat, and hallway conversation, nobody can see the pipeline. When they arrive through one form into one queue, the pipeline is just a filter.

Step 2: coding each line the way finance books it

A purchase request is rarely one thing. It is three laptops, a monitor, and a dock: separate line items, sometimes booking to different codes. Tools built for finance let you attach the accounting context at line level, so cost centre, GL account, and project code travel with each line from request to purchase order, and can print on the PO itself.

This is dull work with an expensive failure mode. In Ardent Partners' Accounts Payable Metrics That Matter in 2025, a study of 212 AP professionals, 14% of invoices arrive as exceptions, and the main causes include coding errors, missing information, and missing purchase order data. Every one of those exceptions is a human pausing to investigate. Code the lines correctly at request time, and the invoice that arrives weeks later matches a PO that already carries the right codes. Finance stops re-keying and starts reconciling.

Step 3: approvals that route themselves

Approval is where purchases go to wait. In the same Vertice dataset, commercial approval averages 8.3 days and executive approval another 5.8, stage after stage, and the delays concentrate where the process is manual.

The fix is a routing matrix, not a faster inbox. A capable tool reads each request and routes it by the rules your company already has: by department, by budget, by product type, by spend threshold, or to a specific reviewer when the vendor is new. Small routine purchases clear in one step. The large or unusual ones collect every required sign-off in order, with each approver seeing only the requests that concern them and the requester watching status the whole way.

When several teams must weigh in on one purchase, this routing is the difference between a two-week email chase and a set of parallel reviews. It is also the strongest argument for running purchasing inside a request platform your company already operates, a case we make in full in why procurement belongs in Jira Service Management.

Do these three steps well and speed follows on its own. Requests arrive complete, so nobody chases context. Lines arrive coded, so finance stops correcting. Approvals route in parallel, so the wait shrinks to the slowest genuine decision, not the slowest inbox.

Why "cloud-based" matters

The older generation of procurement systems lived on company servers or inside heavyweight enterprise suites. They worked, but they came with infrastructure to maintain, upgrades to schedule, and licenses priced for enterprises.

Cloud changes three things in practice:

  • Setup is subscription-speed. You configure workflows and suppliers instead of provisioning servers. Trials are free, so you can test with real requests before committing.
  • The vendor carries the maintenance. Updates, hosting, and security patches ship without your IT team lifting a finger.
  • Integration happens over APIs. Cloud tools expect to connect to the rest of your stack through a REST API rather than a custom middleware project.

The tradeoff is real: your procurement data lives with the vendor. Before you buy, read how they store it, where it resides, and what happens to it when you leave.

When you do not need one

If your team makes a handful of purchases a year and one person approves them all, a shared spreadsheet is fine. Buy software when the symptoms show up: approvals lost in inboxes, duplicate orders, invoices that surprise finance, or auditors asking for records nobody kept.

Those symptoms almost always come from indirect procurement: the software subscriptions, contractors, agencies, equipment, and travel that every department buys with no forecast behind it. Nothing visibly stops when that spend goes wrong, which is exactly why it leaks. If that sounds like your company, read what indirect procurement is, why it leaks, and how to get it under control before you compare tools.

Three ways to run purchasing

Once the symptoms are real, you have three paths, and the right one depends mostly on what your company already runs.

Email and spreadsheetsStandalone cloud platformAn app inside Jira or JSM
Where requests liveInboxes and tabsA new systemThe service desk your staff already use
Who learns a new toolNobodyEvery requester and approverNobody who has raised a ticket
Setup effortNone, and it showsNew rollout, new logins, new trainingAn app install on a platform already configured
Audit trailReconstructed by handBuilt inBuilt in, alongside every other request type
Fits whenA handful of purchases a yearNo Atlassian footprint, complex sourcing needsJira or JSM is already in the building

Do you already run Jira or JSM?

The answer decides the cheapest path.

Does your company run Jira or JSM?

Yes, we run Jira or JSM No, or not sure

Not sure? Ask whoever runs your IT helpdesk. If staff raise tickets through a support portal, that portal is often Jira Service Management, and the platform is already paid for.

If yes: procurement can live where your tickets live

Procurement is a request-and-approval workflow, and Jira is a request-and-approval engine your team already knows. That is the gap Raley Procurement for Jira & JSM fills: an Atlassian Forge cloud app that turns a Jira or JSM ticket into a purchase request, routes approvals through your own matrix (by department, budget, product type, or spend threshold, up to three stages), generates the PO as a PDF in the same work item, tracks deliveries, and exports every order as CSV or over the REST API.

The three steps above are exactly what it is built for. Intake runs through the JSM portal with your own request form. Each order line takes up to five custom fields, so cost centre, GL account, or project code ride along per line and can print on the PO PDF. Budgets are first-class: finance sets them, approvals can route by them, and committed spend stays visible on live dashboards. It carries Atlassian's Cloud Fortified badge, communication runs over SSL with token authentication, and data is deleted 60 days after uninstall. The longer argument for this setup lives in procurement in Jira Service Management: the case for it.

If no, or not sure: read this before you buy a platform

A standalone cloud procurement tool will do the five jobs above. Before you commit to one, look at what your company already licenses. Teams that start a service desk on Jira Service Management get intake, approvals, and purchasing on one request engine, and it ends up handling IT, HR, facilities, and procurement instead of one tool per queue. The five reasons teams run procurement on Jira or JSM makes that case in full, and why procurement belongs in JSM explains why adoption, not features, is usually what decides.

FAQ

What is procurement software used for?

It manages the purchasing cycle from request to payment record: employees submit purchase requests, approvers sign off, the system issues purchase orders, receiving is logged, and finance gets a clean audit trail of committed spend.

What information should a purchase request form collect?

Enough for an approver to decide without writing back: what is being bought, the quantity, the cost, the reason, and who is requesting it. Finance teams usually add their own required fields such as cost centre, GL account, and project code, so every approved request is already coded for the books.

Is cloud procurement software the same as e-procurement?

Mostly. E-procurement is the broader term for any electronic purchasing, including older on-premise systems. Cloud-based procurement software is e-procurement delivered as a subscription the vendor hosts, so there is nothing to install or maintain.

Do small teams need procurement software?

Not always. Below roughly a few purchases a month with a single approver, a spreadsheet works. The trigger is process pain: lost approvals, duplicate orders, or missing records at audit time.

Can procurement software run inside Jira or Jira Service Management?

Yes. Procurement is a request-and-approval workflow, and JSM is built for exactly that pattern. Apps such as Raley Procurement add the purchasing layer (POs, budgets, suppliers, and deliveries) to the intake and approval engine teams already use. Why procurement belongs in JSM covers when this beats a standalone platform.

Is my data safe in a cloud procurement tool?

Check three things on any vendor: encrypted connections, a published data retention policy, and a recognized trust mark. For Atlassian Marketplace apps, the Cloud Fortified badge signals the app meets Atlassian's additional security, reliability, and support checks.