The purchase order flow now runs entirely inside the JSM ticket. 

Open a JSM Ticket anc you will see autogenerated purchase order right there within the ticket, ready for you to work on.

You can edit the order in the ticket, line by line, or in an expanded table view. Pick the view that fits the moment. Both write to the same purchase order.

Inline in the ticket, each order line is a card. Pressing the plus button adds a new line with its own Save and Discard buttons, so a requestor can add an item without leaving the request. or

The expand icon opens the Purchase request modal, where the order lines appear as a spreadsheet-style table. Click a cell to change it. Enter or Tab applies the change; Escape cancels it. This is the view for a procurement person tidying up a ten-line order, or for finance correcting a GL account across several lines.

Finance fields on every line, totals that keep up

Each order line carries the fields finance needs to route the approval and record the spend.

Below the lines, the Net amount, Tax amount, and Gross amount update as lines change. A Set discount button applies a discount to the order. Because the cost centers, GL accounts, budgets, and tax rates come from the Finance settings, a requestor picks from your lists rather than typing codes from memory.

Approvals under the order, in both views

The Approvals section lists each approver with a role tag such as FINANCE, their department, their decision, and the time they voted. Approve Purchase Order and Reject Purchase Order sit under the order in the inline view and in the expanded view, so an approver reads the lines and decides on the same screen.

Between the two buttons sits Approval Assistant. It opens the AI Assistant, which reviews the order with the approver. It cannot approve or reject anything itself.

The Approval AI Assistant will help guide the approvers in deciding, then explains why an order was decided. Compares the order with the supplier’s earlier orders, prices, discounts, budgets, and the ticket discussion

Find out more indetails about Raley Procurement AI Agents via The AI Procurement Assistant for Jira article

Every change to the order is logged on the ticket

A purchase order that lives on the ticket also keeps its history there. A Procurement Audit tab sits in the ticket's Activity panel, next to Comments and History, and records every change to the order and to each line: when it happened, who made it, which record changed (the Order or a Line), the action (CREATED or UPDATED), and the value before and after.

Read the log from the bottom up, and the order's life is there in full. Three lines are created within the same second, and the order's net, tax, and gross amounts are recalculated and logged after each one. A minute later, two lines get a cost center assigned, with the empty value and the new value side by side. The System moves the status from PO Draft to Pending Approval. The approver moves it from Pending Approval to PO Approved, and the Approved flag flips to true, with their name and the time on the row.

Nobody wrote any of that down. It is a byproduct of working on the order in the ticket, which is what makes it useful when finance asks in three months why an amount changed. The same log is also available company-wide under Settings, filterable and exportable; [the dashboard and audit article] covers that view and the Reports that sit beside it.

Settings areas, written in Finance Terms

Admin settings are rebuilt as one left-hand menu. Every page has a plain-language subtitle stating what it controls, and a Procurement Dashboard link sits top-right on every page.

Here are some more examples of what it looks like inside Raley Procurement App Settings.

Raley Procurement for JSM is built for indirect spend:

The laptops, licenses, contractors, services, and supplies that every department buys and that no single buyer owns. It fits companies that already run Jira Service Management and want purchase requests, orders, and approvals to live there, with finance structure (budgets, cost centers, GL accounts, currencies) applied on every line. For the wider picture on why indirect spend leaks and what control looks like, read that article first.

It is not built for direct materials, bills of materials, sourcing events, or supplier contract management. If your spend is the product you sell, you need a different category of tool.

Try it on your own ticket

The fastest way to judge this is to raise one real request, generate the purchase order on the ticket, and have one approver decide under the order lines. If the three people involved can each see what they need without opening another tool, it fits.

Start a free trial of Raley Procurement on the Atlassian Marketplace and run that one request this week. Prefer a walkthrough first? Book one on the product page.

Can you create a purchase order in Jira Service Management?

Yes. With Raley Procurement installed, a purchase request raised from the JSM portal carries a purchase order on the ticket itself, with supplier, order lines, totals, and approvals. The order is edited in the ticket, inline or in an expanded table, and approved there.

Do requestors need a Jira license to raise a purchase request?

Requestors raise requests from the JSM customer portal as JSM customers. Approvers and admins work in Jira. Check the Marketplace listing for the current pricing model, which follows the user count of the parent Atlassian product.

Which finance fields are on a purchase order line?

GL code, cost center, GL account, budget, unit price, quantity, and a per-line tax rate, with a calculated line total. Cost centers, GL accounts, budgets, and tax rates are dropdowns populated from the Finance settings.

Who can edit a purchase order?

An admin chooses in the Jira and JSM settings page: Team Member and Finance, or Finance only.

Does Raley Procurement support more than one currency?

Yes. The Finance settings hold a base currency and other supported currencies with exchange rates. Unit prices are entered in the purchase order’s currency.

Is this the right tool for indirect spend only?

It is built for indirect spend inside Jira and JSM: purchase requests, approval routing, purchase orders, budgets, and a clean handoff to the ERP. It does not cover sourcing events, contracts, or direct materials planning.

A product manager needs a $1,400 annual license for a usability testing tool. She fills in the form, emails her manager, or posts in the finance channel, depending on how purchasing works at her company this quarter. Then nothing happens. Four days later she asks her manager, who says he approved it. Finance says they never saw it. IT says it needs a security review that nobody told her about. On day nine, she pays for it on her own card and files an expense claim.

That sequence plays out thousands of times a day in companies that would describe their purchasing as "under control." It is the view from the requestor's side, and it is the view almost nobody designs for. Procurement articles are written for procurement teams. Finance articles are written for controllers. The employee who started the whole thing, and who will decide whether to use the process next time, is treated as an input.

This article is about that employee. It covers what a purchase request feels like from the inside, why requests go silent, what the silence costs, and what a request should be able to tell its requestor at any moment. It closes with a test you can run on your own process this week.

Key takeaways

• From the requestor's side, a purchase request has three questions: has anyone approved this, who owns it now, and when will it be bought? A process that cannot answer all three on demand will be bypassed.
• Requests go quiet for structural reasons, not lazy approvers. The usual ones are that nobody is named as the current owner, the approval route is invisible to the requestor, and purchases need three separate yeses (manager, finance, and IT or legal) that live in three systems.
• The cost shows up as chasing and as bypass. 56% of workers say the only way to get information they need is to ask someone or schedule a meeting, and fewer than half of procurement leaders believe employees follow their purchasing policies.
• Adding approvers makes it worse. Perceptyx lists "multi-layer purchase approvals for routine expenses" among the bureaucracy complaints that drag engagement down, and Gartner's view is that leaving end users to navigate complex workflows alone leads to more noncompliance, not less.
• The fix is a single front door where the requestor already works, with the approval route computed and shown at submission, one status that stays true across every review, and a place to see your own requests without asking anyone.

What a purchase request looks like from the requestor's side

A purchase request is an employee asking the company to spend money on something they need to do their job: software, a laptop, a contractor, a conference ticket, a service renewal. In most companies under 1,000 people, this is almost all indirect spend, and the requestor is not a buyer by trade. They are a marketer, an engineer, or an office manager who needs a thing and would like to get back to work.

That framing matters because the requestor measures the process by one standard: how much of my attention does it take between asking and receiving. Everything procurement cares about (policy, preferred vendors, budget lines, cost centers) is invisible to them unless the process makes it visible. What they see instead is a form, then a gap.

The gap is where the three questions live.

Has anyone approved this yet? The requestor does not know whether their manager saw it, whether finance has a queue, or whether the request is sitting in someone's inbox under forty other messages.

Who owns it now? If the manager approved it, is it with finance? If finance approved it, is somebody actually placing the order? In a process built on email and chat, the answer changes with every forward.

When will it be purchased? The requestor usually has a date that depends on this: a project start, a campaign launch, a new hire's first day. The process rarely knows that date, so it cannot say whether it will be met.

Those are not unreasonable questions. They are the same questions you would ask a parcel courier. Yet most purchasing processes cannot answer them without a human going and looking.

Why requests go quiet

It is tempting to blame slow approvers. In practice, requests stall for structural reasons that would stall any approver.

Nobody is the named owner at this moment. An email thread with four people on it has no owner. Each person assumes another will act, and the request waits for whoever feels responsible first. A ticket with an assignee has an owner. That single difference explains most of the delay.

The route is invisible to the person who cares most. The requestor does not know that a request over a certain amount needs a second signature, that new vendors need a security review, or that marketing software is approved by a different budget holder than engineering software. They find out when the request bounces, usually after a week.

One purchase, three yeses, three systems. Software is the clearest case. Lines of business now own 70% of SaaS spend while IT owns 26.1%, according to Zylo's analysis of more than 40 million licenses. So the manager approves the budget in one place, IT reviews security in another, and finance checks the budget line in a third. Each step is sensible on its own. Together they produce a request that is "approved" three times and still not bought.

Procurement cannot staff its way out. The Hackett Group's 2025 Key Issues Study projects procurement workload rising 9.8% against a 1% rise in staff, a gap the report puts at roughly 9%. Whatever queue exists today gets longer unless requestors can serve themselves.

Notice that none of these is a people problem. They are all visibility problems, and visibility is a design choice.

What the silence costs

The first cost is chasing. Atlassian's State of Teams 2025 survey of 12,000 knowledge workers found that 56% often find the only way to get the information they need is to ask someone or schedule a meeting, and that teams spend about a quarter of the workweek searching for information. A purchase request with no status is a textbook case: the information exists in someone's inbox, and the only retrieval method is interrupting that person.

The second cost is bypass. Amazon Business's 2024 State of Procurement Report, a survey of more than 3,000 procurement decision makers, found that fewer than half (46%) agree that non-procurement employees follow their policies and procedures. The same respondents, 78% of them, said streamlining purchasing for people outside procurement was very important. They know where the leak is.

Bypass is rarely malicious. The academic literature on maverick buying, going back to Karjalainen, Kemppainen, and van Raaij's 2009 study, describes a spectrum that runs from unintentional to deliberate, with most of it sitting at the unintentional and well-meaning end. The product manager in the opening did not set out to break policy. She had a deadline and a process that had gone dark.

The third cost is slower and harder to see. Perceptyx reports that the statement "my company does a good job minimizing or eliminating unnecessary bureaucracy" is the lowest-scoring item in its global benchmark, at 48% favorable, and names "multi-layer purchase approvals for routine expenses" as one of the friction points employees cite. At one large customer in that analysis, engagement ran at 81% among employees who felt bureaucracy was under control and 31% among those who did not. Marketing teams, who request tools and contractors constantly, scored lowest of any function at 30% favorable.

A purchasing process is one of the few places where every employee meets the company's bureaucracy directly. It shapes how they feel about working there.

Why more approvers make it worse

The reflex when spend feels out of control is to add a signature. Payhawk's 2024 survey of finance leaders found that half require all spend to be approved before it happens, while only 28% let employees spend within a policy without pre-approval.

Pre-approval is not wrong. It is the right control for most indirect spend. The problem is that each added signature, in a process with no visible route and no named owner, adds another place for the request to disappear. Gartner's 2025 Hype Cycle for Procurement and Sourcing Solutions puts it plainly: "Without intake management solutions, end users manage their procurement journey independently through complex procurement workflows. This could lead to increased noncompliance, and negatively impact end-user experience."

The benchmark numbers show how long the journey takes even with dedicated software. Procurify's 2026 benchmark, drawn from more than $30 billion in customer transactions, puts the median requisition-to-PO cycle at 55 hours in 2025, up from 51 the year before. That is more than two working days for companies that already run a procurement system. The companies approving purchases over email do not appear in any benchmark, because nobody can measure them.

So the goal is not fewer controls. It is controls the requestor can see. A two-day wait with a visible owner and a predictable route is tolerable. A two-day wait in the dark is where bypass begins.

What a request should be able to tell you

Here is the standard we hold our own intake process to. At any moment, without asking anyone, a requestor should be able to answer the three questions from the opening. That requires five things from the process.

One front door. The request starts in one place, whether the requestor is a Jira user or not. A service portal does this well because it already handles the "I need something" interaction for IT and HR, and people know where it is. Email and chat are fine for discussing a purchase, but a request that only exists in a thread has no status.

The route shown at submission. When the requestor picks a department, a budget, and the items they need, the process should compute who has to approve it and show those names, with their approval limits, on the request itself before it is submitted. This is the single change that kills "I didn't know it needed a second signature." Routing rules based on amount, department, budget, product category, and cross-functional review (legal, security, IT) exist so that the rules run, and the requestor sees the output.

One status that stays true. When a request needs a security review and a budget check and a manager's signature, the requestor should see one state, not three. Every approver attaches to the same record, each vote is visible on it, and the record moves to approved only when the last vote lands. If any reviewer says no, it moves to rejected, and the requestor sees which vote did it. Locking the request from edits once it is submitted keeps that status trustworthy, because approvers are voting on a version that cannot change under them.

A place to see your own requests. Not a report somebody runs for you. A view, in the portal, that lists the requests you have raised and what state each is in. Team members see their own; approvers see what is waiting on them; finance sees everything. Nobody has to ask.

Structured items, not free text. When a requestor can pick a product from a catalog with the supplier, unit price, and tax already attached, the request arrives complete. Free-text items are still allowed, because the catalog will never contain everything, but the default should produce a request finance can act on without a clarifying email.

None of these requires a procurement platform. They require a record with an owner, a computed route, and a view the requestor can open. That is a workflow design problem, and most companies already own a tool that can solve it.

Put the front door where people already work

The Hackett Group's advice to procurement leaders in 2025 is to "orient your procurement operating model to meet the needs of end-user stakeholders" and to provide self-service options. The practical reading of that advice: do not make requestors learn a new system to ask for a laptop.

There is also a tool-sprawl argument. ORO Labs' 2025 survey of enterprise procurement executives found 64% already run 10 or more procurement tools and only 8% say most of them deliver the expected return. Another standalone system, with its own login and its own notification stream, is a cost before it is a benefit.

For companies that run on Atlassian, the front door already exists. Jira Service Management is where employees ask for access, equipment, and help. A purchase request is the same shape of interaction: a form, a queue, approvers, a status, a resolution. Atlassian's own enterprise service management guidance names procurement as a team that can use the portal to "guide employees to the right purchasing process, collect complete request details, coordinate approvals". We have written elsewhere about why procurement fits inside Jira Service Management and the lessons from five years of building it there, so this article will not repeat the argument. The point for the requestor is narrower: the status of a purchase request should be checkable in the same place they check the status of their laptop ticket.

A test you can run this week

Pick the last five purchase requests that went through your company. For each one, try to answer the three questions as they stood 48 hours after submission, using only what the requestor could see at the time.

1. Could the requestor tell, without asking anyone, whether it had been approved?
2. Could they name the person it was waiting on?
3. Did they know the expected order date, or at least the next step?

Then ask the requestors one more question: did you buy anything in the last quarter without going through the process, and why?

If the answers are mostly no and the reasons are mostly "it was faster," you do not have an approver problem. You have a visibility problem, and the next section is about what to do with it.

Deciding in practice

If your company has fewer than about 30 people and one person approves everything, a shared inbox and a card policy will do. The three questions have the same answer every time: ask that one person.

Past that size, the questions multiply faster than the headcount. The requestor needs a record they can open, the approver needs a queue that names them, and finance needs to see what has been committed before the invoice arrives. If your teams already live in Jira or Jira Service Management, that record can be a ticket, with the approval route computed from your own rules and the status visible in the portal. On our own intake flow, the average request-to-PO cycle is 29 hours, against the 55-hour industry median above. The number matters less than the fact that every requestor can see where their request is for all 29 of them.

That is what Raley Procurement for Jira and JSM is built to do. If the five requests you tested came back with more questions than answers, book a short walkthrough and bring one of them with you.

Worth asking
What is a purchase request?
A purchase request is a formal ask by an employee for the company to buy something they need for their work, such as software, equipment, a contractor, or a service. It is the first step of the procure-to-pay process and precedes the purchase order, which is the company's commitment to a supplier. A purchase requisition is the same thing by a more formal name.

How long should a purchase request take to approve?

Procurify's 2026 benchmark puts the median requisition-to-PO cycle at 55 hours for companies that already run procurement software. A realistic target for routine indirect spend is one to two working days, with the requestor able to see the status throughout. Speed matters less than predictability; a visible three-day wait is tolerated, an invisible one is bypassed.

Why do employees bypass the purchasing process?

Most bypass is unintentional or well-meaning rather than deliberate. The usual triggers are a request that has gone silent, an approval route the employee did not know about, and a deadline that cannot wait. Fewer than half of procurement leaders in Amazon Business's 2024 survey believed employees followed their policies, and 78% said streamlining purchasing for non-procurement staff was very important.

What should a purchase request tracking system show the requestor?

At minimum: the current status, the person or role the request is waiting on, the full approval route with each approver's decision, and a list of the requestor's own requests in one place. A process that can only answer these questions by having someone look is not tracking; it is searching.

Can you track purchase requests in Jira Service Management?

Yes. A purchase request maps onto a JSM request type: a form on the portal, a ticket with an assignee and status, approvers attached to the ticket, and a resolution. Approval routing by amount, department, budget, and product, plus purchase order generation and budget tracking, come from Marketplace apps built for that purpose rather than from JSM itself.

The harder question is not whether you can build it. You almost certainly can. It is whether building and maintaining it yourself costs less, over the years, than installing a purpose-built app such as Raley Procurement. This article lays out both paths, with a feature-by-feature comparison, so you can make the call for your own situation.

The short answer

Build it natively when a purchase request is one form, one approver, and the issue key is a fine PO number. Buy an app when you need multi-line orders coded to cost centers, a product and supplier catalog, approval routing that changes with amount and department, and a PDF purchase order. We haven't mentioned the need to integrate with ERP yet... The dividing line is complexity, and complexity tends to grow.

First, which "template" are we talking about?

Two different things get called "the Jira procurement template", and they are not equal.

The first is Atlassian's Procurement template, a business project template for Jira itself, aimed at finance teams and described as a way to "track all purchases from request to receipt". It gives you a board, a list view, a form, a customizable workflow, and no-code automation. It is a tidy starting point for tracking purchases as tasks. It is not a procurement system: there are no order lines, no budgets, no suppliers, and no approval logic beyond what you wire up yourself.

The second is JSM, which does not ship a procurement template but does ship the building blocks: a customer portal, request types, forms, approval steps, Assets for reference data, and automation. This is the platform serious DIY builds are made on, and it is the platform Raley Procurement runs on top of. Our own view, argued in Jira vs JSM for procurement intake, is that JSM is the right Atlassian home for purchasing either way.

So the real comparison is three-way: the Jira template as shipped, a DIY build on JSM, and Raley Procurement on JSM.

What "build it yourself" actually means in JSM

"Build it in JSM" is not a switch you flip. It is an assembly project with several pieces you have to design, wire together, and then keep working through every Atlassian release:

1. A request type and form for purchase requisitions per category, plus a bunch of separate request types for the processes around it: new supplier onboarding, price changes, discounts, and edits to requests that are already locked.
2. A custom workflow with the right statuses, transitions, and post-functions to move a request from draft, through approval, to an issued PO.
3. A data model for cost-centers, gl-accounts, routings, suppliers, departments, and products, plus a way to connect each of those to the people and limits they belong to.
4. An approval engine that routes to the right approvers, in the right order, based on amount, department, budget, and supplier.
5. PO numbering, PDF generation, notifications, and reporting on top of all of it.
6. Integration with ERP

None of these is impossible. Several are deceptively hard and more sound like a solution project that can be outsourced to some Atlassian solution partner for implementation

Where building it yourself is the right call

Be skeptical of any vendor, Raley included, who tells you never to build anything. There are real cases where native JSM is the smart, cheap answer.

Simple, low-volume purchasing. If a requisition is essentially "describe what you want, get one manager's sign-off", a basic JSM request type with a single approval step does the job. You do not need an app for that.

Internally generated PO numbers. If you have no legacy numbering scheme, using the Jira issue key as the PO number is clean and free. This is one place DIY shines.

A single, stable approval path. If everyone routes to the same one or two approvers regardless of amount or department, native approvals plus an automation rule can handle it.

In-house Jira capacity. If you have admins who can treat the build as a maintained internal product rather than a one-time project, the ongoing cost is real but budgeted.

If most of those describe you, build it. An app's value shows up as complexity rises, so if your complexity is low, the math favors DIY.

Where building it yourself gets expensive

Procurement complexity tends to grow, and it grows in exactly the places JSM's native tooling runs thin. We wrote up the field detail in Procurement in Jira: 8 lessons from five years in the field; here is the short version.

Purchase request forms are harder than they look. A JSM form is a fixed set of fields. Out of the box, the portal does not offer "add another line" rows, so a request for five items becomes five copies of the same fields or a Marketplace grid app. Real purchasing also needs context the form cannot see: the requester's spending limit, the budget the line draws on, a searchable product list, and a cost center per line. The tempting shortcut, one sub-task per line item, leaves you keeping child issues in sync with a parent on totals and approvals.

Reference data needs a real home. A purchase request has to connect to suppliers, taxes, cost-centers, gl accounts, products and products. Forcing this into custom fields breaks down fast: departments cannot easily be tied to specific users, a supplier carries too much metadata for a select list, and a few thousand products in a dropdown is a usability disaster. The better pattern is JSM Assets. Since February 2026 Assets is included on the Standard plan with a 5,000-object allowance (Atlassian announcement), which removes the old Premium-only objection, but you still have to model the schema, sync it, and decide how much you sync. By the way, JSM Assets is a great place if you're in search of catalog purchases and need to store the items frequently requested.

Approval matrices are where most DIY builds stall. Real organizations approve by supplier, then product, then department, then routing by CC&GL, then ascending amount thresholds, and the approvers need to be asked in that order (the CEO should not be pinged before the VP and CFO have signed). JSM approval steps can take approvers from a user field or an Assets field, and amount-based branching can be built with automation. Encoding the ordering, then re-encoding it every time finance changes a threshold, is a standing maintenance job. Atlassian's own knowledge base documents a three-rule automation cascade just to refresh approvers when an Assets approver field changes (Atlassian support).

Edit-after-lock and auditability are easy to forget. Mistakes surface after a request has cleared a long approval chain. Most companies want a finance role that can correct a typo on a locked order rather than cancel and restart, and every such edit must be traceable: who changed what, when, with the old value preserved. That is real engineering, and it has to survive Jira upgrades.

PO numbers from another system add a layer. If purchase order numbers are issued by your finance system rather than by Jira, you need a custom field set by automation, a manual override for finance, and that number echoed onto whatever document goes to the supplier.

Individually, each of these is solvable. Collectively, they are a product. One you now own, staff, and maintain indefinitely.

Feature comparison: Jira template vs DIY on JSM vs Raley Procurement

Raley claims are checked against the Raley Procurement Marketplace listing, the product page, and the product docs as of September 2026. Atlassian columns are based on the Jira Procurement template page and JSM documentation as of the same date.

What a purpose-built app gives you

Raley Procurement exists to deliver the hard pieces above out of the box, while still living inside the JSM your teams already use. The pitch is not "replace Jira". It is "stop rebuilding the parts of procurement that are the same at every company".

Requesters raise a purchase request in the JSM portal, as a single item or as a multi-line order. Each line carries its cost center and GL account, a product from your catalog, and the budget it draws on. Approvals route by product, cross-functional reviewer, budget, CC, Gl, department, and spend tier, in the order your matrix defines. On approval the request becomes a purchase order with a branded PDF that stays on the same work item. And the same purchase order is sent to your ERP so, that the Finance and AP teams can continue there. Deliveries are recorded against it line by line in Raley or ERP.

Because it sits on top of JSM, you keep the flexible workflow underneath and can still shape transitions to match your process.

The trade-offs are the usual ones for any app: a per-user subscription, dependence on a third-party vendor's roadmap and support, and the need to fit your process into the app's model, which is flexible but not infinitely so. Raley Procurement carries Atlassian's Cloud Fortified mark on its listing; check the current version and reviews there before you decide.

A decision framework

A rough way to choose:

The single most useful reframe is total cost of ownership, not upfront cost. A DIY build looks free because the license line is zero, but the real bill is the engineering to build it plus years of maintenance as finance changes thresholds, Atlassian ships updates, and edge cases pile up. An app converts that unpredictable internal cost into a predictable subscription. Whether that is a good trade depends entirely on how complex your procurement is and how much Jira admin capacity you can spare.

Bottom line

JSM is an excellent foundation for procurement either way. That is not the question. The question is how much of the procurement layer you want to own. If your process is simple, build it natively and do not pay for an app you do not need. If you are staring down multi-tier approval matrices, multi-line request forms, supplier and product registers, and edit-after-lock auditing, recognize that "just build it in Jira" is a real product commitment, and that is precisely the work Raley is designed to take off your plate.

The practical takeaway: sketch your approval matrix and your purchase request form on one page. If you can build them with native request types, a workflow, and a single automation rule, do that. If the sketch already needs footnotes, you have your answer.

Try Raley Procurement free on the Atlassian Marketplace or see how it works.

FAQ

Does Jira have a procurement template?
Yes. Atlassian's Procurement template is a business project template for Jira with a board, list, form, workflow, and automation, aimed at finance teams tracking purchases as tasks. It does not include order lines, budgets, suppliers, or approval logic; you build those yourself or add an app.

Does Jira Service Management have a procurement template?
No dedicated one. JSM provides the building blocks (portal, request types, forms, approval steps, Assets, automation) and you assemble a procurement process from them, or install an app such as Raley Procurement that uses those blocks.

Can JSM handle multi-line purchase requests natively?
Not as repeatable rows on a portal form. The native options are one set of fields per line, sub-tasks per line, or a Marketplace grid app. Raley Procurement adds order lines inside a single work item.

Do I need JSM Premium to build procurement with Assets?
Not any more. Since February 2026 Assets is included in Service Collection Standard with a 5,000-object allowance; larger allowances come with Premium and Enterprise.

Does Raley Procurement replace Jira Service Management?
No. It runs on top of JSM. Requesters use the JSM portal, the request is a JSM work item with your own workflow, and Raley adds order lines, catalog, suppliers, budgets, approval routing, PDF purchase orders, and goods receipt.

Related reading

• Why intake-to-procure belongs in Jira Service Management
• Jira vs JSM for procurement intake
• Procurement in Jira: 8 lessons from five years in the field
• What is cloud-based procurement software?
• How a growing software team brought purchase approvals into Jira

This article explains what indirect procurement covers, why it leaks money in a way direct procurement does not, and what a team that is not a Fortune 500 can actually do about it.

The short answer

Indirect procurement is the buying of everything a company needs to operate that does not go directly into the product it sells: software, contractors, agencies, office and facilities supplies, travel, equipment, and professional services to name a few. It is booked as operating expense, requested by almost every department, and spread across hundreds of suppliers. Direct procurement, by contrast, buys the materials and components that become the product, and is usually run by a dedicated team with appropriate forecasting and tracking.

That spread is why indirect procurement is hard. Nobody owns all of it, so nobody sees the whole picture.

Already on Jira or JSM? Your indirect purchasing can run where your requests already live: Raley Procurement handles intake, approvals, and POs inside the tools you have.

Direct vs indirect procurement

Direct procurement buys what you sell. Indirect procurement buys what you run on. The two look similar on an invoice and behave completely differently in practice.

The last two rows explain everything else in this article. A direct procurement failure has a forcing function: a missing part halts production and gets fixed (or noticed, at least) the same day. An indirect procurement failure has none. The purchase happens anyway, just at a worse price, from an unvetted vendor, without a record.

Why indirect spend leaks

Indirect spend leaks because the process to buy correctly is slower than the process to buy badly. Three mechanisms do most of the damage.

Maverick spend

Maverick spend is buying outside the agreed process or contract: the manager who expenses a tool on a card, the team that signs a contractor on a handshake, the department that renews with the incumbent because the intake form takes too long. It is rarely malicious. It is usually a rational response to friction.

The cost is not abstract. Hackett's benchmark of digital world-class procurement organisations found they suffer 59% less savings loss due to maverick spend than their peers. The gap between the two groups is mostly process, not headcount.

Tail spend

Tail spend is the long list of small purchases from many vendors. Hackett's 2025 Tail Spend Management Study puts it at roughly 20% of enterprise spend spread across 80% of suppliers, and found that only 4% of companies actively manage most of it. Each purchase is too small to negotiate. Together they are a large, unmanaged number.

For a 200-person company the tail is not exotic. It is the fourteen SaaS tools nobody reconciled, the three freelance designers on three different rates, and the office supplies ordered from whichever shop was open.

Spend that never becomes a purchase order

The quietest leak is the purchase that skips the PO entirely. No PO means no approval trail, no committed-spend number for finance, and no document to match the invoice against. The invoice arrives, someone recognises the vendor name, and it gets paid. Sievo's analysis of $103 billion in spend found that moving indirect invoice-to-due timing from bottom quartile to top quartile alone frees roughly $34,000 in working capital per $1 million of spend. You cannot manage timing on invoices that have no order behind them.

What indirect procurement covers

Indirect procurement covers every operating purchase, and each category leaks in its own way. Five categories account for most of the spend in a software or services company.

Software and cloud. The fastest-growing category and the one with the most auto-renewals. The failure mode is sprawl: duplicate tools, unused seats, and multi-year clauses nobody read.

Contractors and professional services. Consultants, freelancers, legal, audit. The failure mode is scope: statements of work that describe outcomes vaguely enough that every invoice is technically correct.

Marketing and agencies. Media, creative, PR. The failure mode is opacity. The Association of National Advertisers found that about one in four dollars in the $88 billion open-web programmatic market is lost to waste in the supply chain.

Facilities, equipment, and supplies. Laptops, furniture, maintenance, consumables. The failure mode is urgency: someone needs it today, so the process gets skipped altogether.

Travel and events. The failure mode is off-channel booking, where the price you negotiated never gets billed.

You do not need a category manager for each of these. You need each of them to enter through the same door.

The Indirect Spend Control Ladder

The Indirect Spend Control Ladder is a four-rung test for how much of your indirect spend you actually control. Most teams are on rung one and think they are on rung three. Climb it in order; each rung depends on the one below.

Rung 1: one front door. Every indirect purchase request, from any department, starts in one place with a structured form. If requests arrive by email, chat, and hallway, you are not on the ladder yet. This is the rung that kills maverick spend, and it only works if the door is easier to use than the workaround.

Rung 2: no PO, no pay. A purchase order is issued before the commitment, not reconstructed after the invoice. Approval routes by the rules you already have (department, CC, GL, product type, spend threshold) so a $200 cable clears in one step and a $40,000 contract collects every sign-off. The benchmark above suggests this is where world-class teams pull away.

Rung 3: receipt before payment. Someone records that the goods or services arrived, per line, and the invoice is matched against both the order and the receipt. Partial deliveries get partial receipts. This is the rung that stops paying for things that never showed up.

Rung 4: spend you can query. Committed and received spend is visible by department, supplier, and cost-center while it happens, not at quarter close. Until this rung, "how much do we spend on contractors?" is a research project.

A useful benchmark for where you land: Hackett's world-class organisations run about 95% of indirect spend under management, against 66.5% for everyone else. If you cannot state your own number, you are below rung four by definition.

How company size changes the answer

Company size changes the tooling, not the ladder. The four rungs are the same at 50 people and 5,000; what differs is how much machinery you need to climb them.

Below about 50 people, a shared form and a spreadsheet can hold rungs one and two if one person owns it. Past that point the spreadsheet becomes the bottleneck, and the honest options split three ways: a standalone procurement platform, a module of a larger finance suite, or a purchasing layer inside a request tool your company already runs. We compare those paths in what cloud-based procurement software does and when you do not need it and, for the 100-to-1,000 range, in the mid-market procurement software buyer's guide.

The third path matters more for indirect than for direct procurement. Indirect requests come from every department, and every department already raises IT, HR, and facilities requests somewhere. If that somewhere is Jira Service Management, the front door for rung one already exists. The case for it is in why procurement belongs in Jira Service Management.

Features to check, whichever path you take

Whatever you choose, six capabilities decide whether you climb the ladder or buy a nicer spreadsheet.

1. A structured request form you can extend with your own required fields (cost centre, project code, need-by date), so you can't submit a half-empty request.
2. Approval routing by threshold and department, in stages, with each approver seeing only what concerns them.
3. A generated purchase order (usually a PDF) issued from the approved request, not typed separately.
4. A supplier and product catalogue, so recurring purchases are picked, not re-described.
5. Goods receipt recorded per order line, with partial receipts.
6. Committed-spend visibility and an export finance can reconcile against.

Anything beyond these is useful for large procurement functions and optional for everyone else.

Where Raley Procurement fits

We build Raley Procurement for Jira & JSM, so read this section knowing that. It runs the six capabilities above inside a Jira or JSM work item: purchase requests raised through the JSM portal with your own required fields, approval routing by department, cost-center, gl account, product type, and spend threshold, a PDF purchase order generated from the approved request, a supplier and product catalogue with CSV import, goods receipts per order line with partial receipts, committed-spend dashboards, and CSV or REST export. It is Cloud Fortified on the Atlassian Marketplace.

It is not a source-to-pay suite. It does not negotiate with suppliers, manage contracts or supplier risk, or replace category management for a procurement department of twenty. If your indirect spend runs into the hundreds of millions, you are shopping in a different aisle, and the buyer's guide above says so.

Where indirect procurement is headed

Indirect procurement is moving toward orchestration: one intake layer that collects every request and coordinates the reviews behind it, with software increasingly handling the small negotiations humans never got to. Hackett reports that 88% of procurement leaders are open to AI-powered agents for small-value negotiations. That is a sensible direction for the tail.

It does not change the ladder. An agent negotiating a $12,000 renewal still needs the request to have entered through one door, a PO to exist, and a receipt to close it. The rungs come first. The automation sits on top.

How to decide, in practice

Start by counting doors. List every way an indirect purchase request reaches an approver in your company today: email, chat, a form, a spreadsheet, a conversation. If the answer is more than one, that is your first project, before any tool comparison.

Then ask which rung you are on and be honest about it. Most teams discover they issue POs for some purchases and none for the rest, which means rung two is a habit, not a control.

If your company already runs Jira or Jira Service Management, the front door exists and your indirect procurement can live in it. See how Raley Procurement runs intake, approvals, and purchase orders inside JSM, and start a free trial from the Marketplace.

FAQ

Short answers to the questions people search for around indirect procurement.

What is indirect procurement?

Indirect procurement is the purchase of goods and services a company needs to operate but does not sell: software, contractors, agencies, facilities, equipment, supplies, and travel. It is booked as operating expense and requested by every department, which is why it is harder to see and control than direct procurement.

What is the difference between direct and indirect procurement?

Direct procurement buys what goes into the product (materials, components, goods for resale) and is planned from a forecast by a dedicated team. Indirect procurement buys what the company runs on, arrives from any department without a forecast, and involves a far more fragmented supplier base. When direct procurement fails, production stops; when indirect procurement fails, nothing visible stops, so the cost accumulates quietly.

What are examples of indirect procurement?

SaaS subscriptions and cloud services, freelance and consulting contracts, marketing agencies and media, laptops and office equipment, maintenance and cleaning, office supplies, and business travel are all indirect procurement.

What is maverick spend in indirect procurement?

Maverick spend is buying outside the agreed process or contract, usually because the official route is slower than the workaround. It removes the purchase from approval, from negotiated pricing, and from the record. The fix is to make the correct route the easy one: a single intake door and approvals that route automatically.

What is tail spend?

Tail spend is the large number of small purchases from many suppliers that are too small to negotiate individually. Hackett's 2025 study puts it at about 20% of spend across 80% of suppliers, with only 4% of companies actively managing most of it.

Can indirect procurement run inside Jira or Jira Service Management?

Yes. Indirect procurement is a request-and-approval workflow, and JSM is a request-and-approval engine most companies already use for IT and HR. A Marketplace app such as Raley Procurement turns a JSM request into a purchase request, routes the approval tiers, generates the PO, and records receipt, all inside the work item.

Related reading

• What is cloud-based procurement software?
• Why procurement belongs in Jira Service Management
• Solving the intake-to-procure problem with Jira Service Management
• The benefits of automating your purchasing process
• Mid-market procurement software: a buyer's guide
• Procurement in Jira: 8 lessons from five years in the field

Most purchasing is not a process. It is a habit. Someone emails a vendor, pings finance about budget, and forwards an invoice weeks later, hoping the numbers still match. It works until it doesn't: a duplicate order, a missed sign-off, a budget already spent before anyone looked.

Procurement automation replaces those handoffs with one workflow that carries a request from "we need to buy this" to an approved purchase order. Here is what that buys you.

What procurement automation means

Automating the purchasing process means four things run on rules instead of memory: intake (a structured request, not a free-text email), approval routing (the request reaches the right people automatically), PO generation (an approved request becomes a formatted purchase order), and tracking (order status and budget stay visible as work moves). Software handles the routing and the record-keeping; your team makes the decisions.

The benefits, made concrete

Faster cycles. Across the industry, the median request-to-PO cycle runs about 55 hours (Procurify, 2026 Procurement Benchmark Report). Structured intake and automatic routing cut the inbox-waiting time behind most of that number.

Fewer errors. Retyping an approved request into a PO template is where quantities get transposed, and the wrong vendor slips in. Generating the PO from the approved request removes the retype and the rework behind it.

Spend you can actually see. A budget updated after the fact is stale by the time anyone reads it. Automation tracks committed spend as requests move, so a controller sees what is promised, not just what has cleared the bank.

Less off-policy spend. When submitting a request is more work than skipping it, people route around the process, and maverick spend climbs. A clear intake path with approval rules built in keeps buying inside policy.

An audit trail that writes itself. Every request, approval, and change is recorded as it happens. When finance or an auditor asks who approved what, the answer is already there.

You don't need a heavyweight platform

The usual response is to buy a standalone procurement suite. That fixes the workflow and creates a new problem: another system to log into, used a few times a year before people drift back to email.

If your team already runs on Jira and Jira Service Management, there is a shorter path. A procurement layer adds structured intake, tiered approval routing (by department, budget, product, and spend threshold), branded PDF purchase orders, a supplier and product catalog, and live budget tracking, all inside the tools people already open every day. That is what Raley Procurement for Jira and JSM does, and it is Cloud Fortified on the Atlassian Marketplace.

The benefits do not come from the size of the tool. They come from making purchasing a repeatable workflow, run where your team already works.

Related reading: Why procurement belongs in Jira Service Management.

Want purchasing to run this way inside your own Jira? See how Raley Procurement works, or get Raley Procurement on the Atlassian Marketplace.

Worth asking

What is procurement automation?

Procurement automation uses software to run the purchasing process on rules instead of manual handoffs. It captures requests through a structured form, routes approvals automatically, generates the purchase order, and tracks order status and budget, so buying moves from request to approved PO without manual reassembly.

What are the main benefits of automating the purchasing process?

Shorter request-to-PO cycles, fewer data-entry errors and less rework, real-time visibility into committed spend, less off-policy (maverick) spend, and an audit trail that records every request and approval as it happens.

How does procurement automation reduce maverick spend?

Maverick spend rises when submitting a request is harder than skipping it. A clear intake path with approval rules built in gives people a compliant way to buy, so purchases stay inside policy.

Do you need a separate platform to get these benefits?

No. A dedicated suite is one option, but a team already on Jira and JSM can automate intake, approval routing, PO generation, and budget tracking with a procurement layer inside those tools, with no new system to learn.

Most supply chain delays do not start on the loading dock. They start earlier, when a simple purchase sits in someone's inbox waiting for a reply. E-procurement removes that drag in four practical ways.

It shortens the buying cycle

Manual procurement scatters a single request across email, chat, and spreadsheets. Each handoff adds a wait, and waits add up.

An e-procurement system routes the request down one defined path: submit, approve, order, receive. The order reaches the supplier sooner, so the goods arrive sooner. Shorter cycles mean you carry less safety stock to cover uncertainty, and you place fewer rush orders to fix delays you could not see coming.

It gives you spend visibility you can act on

You cannot manage spend you cannot see. E-procurement records every request, order, and receipt as structured data rather than scattered attachments.

Buyers see what is on order, from which supplier, and against which budget. That view surfaces duplicate orders for consolidation and suppliers to negotiate with. Planning gets easier too, because demand shows up early in the system instead of arriving as a surprise at month-end.

It reduces errors and off-contract spend

Free-text orders invite the wrong quantity, the wrong price, and the wrong supplier. A curated supplier and product catalog settles those details before the order goes out.

Approval workflows keep buying inside policy and budget, whether you route by a single approver or by department. The payoff is fewer maverick purchases, fewer corrections, and fewer invoice disputes later. Every error you prevent upstream is a delay you avoid downstream.

It closes the loop at goods receipt

Efficiency is not only about ordering fast. It is about knowing what actually arrived.

Goods receipt records each delivery against the original order, so quantity and date are checked at the door rather than weeks later. That keeps inventory records honest and gives finance a clean trail from request to receipt. Fewer surprises reach the warehouse, and fewer reach the ledger.

In summary;

What is an e-procurement system?

A digital tool that manages buying from end to end: purchase requests, approvals, purchase orders, a supplier and product catalog, and goods receipt. It replaces the manual email and spreadsheet steps most teams still rely on.

How does e-procurement reduce supply chain costs?

It makes spend visible so you can consolidate orders and negotiate on volume; it holds buyers to catalog pricing, and it cuts duplicate and off-contract purchases. You buy less, on better terms, with fewer costly corrections.

Does e-procurement actually speed up procurement?

Yes. One defined workflow removes the handoffs and waiting that stretch manual buying. Requests turn into orders faster, and goods arrive sooner.

Is e-procurement only for large companies?

No. Small and mid-size teams often gain the most, because removing manual steps frees time they do not have to spare. The gain is largest when procurement runs inside tools the team already works in.

If your team already runs in Jira or JSM, this is your other option.

Raley Procurement for Jira and JSM keeps purchase requests, approvals, and purchase orders in one place: the Jira your team already uses. A business user raises a request, it routes through your approval rules, and a formatted PO goes to the supplier as a PDF. Budgets, the supplier catalog, and goods receipt live in the same view, so nobody switches tools to buy something.

If your work already runs in Jira, your procurement can run there too. Teams that have done this for years share what worked in procurement in Jira: 8 lessons from five years in the field. See how Raley Procurement works, or get Raley Procurement on the Atlassian Marketplace.

Lots of procurement tools can generate a purchase order. Fewer can tell you who your suppliers are, what you buy from them, at what price, and what is still on order. That second part is supplier management, and it is usually the difference between software that replaces your spreadsheets and software that quietly creates new ones.

Seven tools cover both sides well in 2026: SAP Ariba, Coupa, Jaggaer, Ivalua, Kissflow, Precoro, and Raley Procurement for Jira & JSM. Which one fits depends far less on feature lists than on the size of your spend and the tools your team already works in.

Two things changed the picture this year, and both matter before you shortlist. The market moved toward intake-to-procure, the layer that captures a request where work already happens and routes it onward. And nearly every vendor added agentic AI, some of it real and some of it marketing. This guide covers what supplier management actually requires, how those two shifts change the decision, the seven tools and who each fits, the buying criteria that matter in 2026, and a short test to choose.

What supplier management means in practice

Before comparing vendors, pin down what you actually need. Real supplier management covers five things, and each is a place cheaper tools quietly fall short.

• A master record for each supplier. One source of truth for contacts, terms, tax IDs, and bank details, not a value retyped into each purchase order.
• Product catalogs with prices and tax rules. So a requester picks a known item at a known price, and the tax and total are right before anyone approves.
• Onboarding and compliance documents. Insurance, certifications, and contracts attached to the supplier, with renewal dates you can see coming.
• Order history per supplier. Every request, order, and receipt against that vendor, so you know what you actually buy and can negotiate from evidence.
• An API that keeps all of it in sync with your ERP or accounting system. This is where most tools quietly fail. If supplier and order data do not flow to finance on their own, someone rekeys them, and the errors start there.

In a demo, ask to see each one. A vendor list with contact fields is not supplier management. It is an address book with a better logo.

How the procurement software market shifted in 2026

For two decades, the default answer to which procurement software was a source-to-pay suite: one platform for sourcing, contracts, suppliers, and purchasing, sold to a dedicated procurement team. That default is loosening, and the analysts are now on the record.

In January 2026, Gartner placed Zip, an intake and orchestration vendor, in its Magic Quadrant for Source-to-Pay Suites as a Visionary. It was the first time an intake-first product appeared in that research, and the youngest company placed in it. The category it represents, intake-to-procure, starts from a different premise than the suites. Instead of asking employees to log into a procurement system, it captures the request inside the tools people already use, then routes approval, ordering, and supplier data onward.

The reason the category exists is adoption. Heavyweight suites are capable and, in many rollouts, under-used, because they ask people to leave their work to raise a request. When the tool goes unused, the supplier data it was supposed to hold goes stale. Intake-to-procure is the market's answer to that failure.

The incumbents are responding by buying and building. In May 2026, Coupa acquired the orchestration platform Tonkean to fold intake and orchestration into its own platform, the latest in a run of AI-focused acquisitions. SAP and GEP have added intake and orchestration layers of their own. The money follows the same line: Zip reached roughly a $2.2 billion valuation in its 2024 funding round, ORO Labs raised $100 million in March 2026, and Levelpath raised more than $55 million in mid 2025.

For a buyer, the takeaway is simple. Where a tool runs is now a first-order decision, not a detail. A suite with every feature still fails if your team will not open it.

The agentic AI reality check

The second shift is agentic AI, and it needs a colder eye. Nearly every vendor now markets AI agents that promise to run tasks on their own. Some of that is real. A lot of it is labeling.

Gartner warned in May 2026 that "agent washing," dressing up older automation as autonomous agents, is creating real risk for buyers under pressure to show results. In mid 2025, Gartner analysts estimated that of the thousands of vendors claiming agentic AI, only around 130 were doing something genuinely agentic. The direction of travel is still upward: Gartner forecasts that supply chain management software with agentic AI will grow from under $2 billion in 2025 to about $53 billion by 2030, and that the share of enterprises using it will climb from roughly 5 percent to roughly 60 percent over the same window.

Underneath the labels, the shipped reality is uneven. SAP is rebuilding Ariba as an AI-native platform on a phased 2026 rollout, so several of its most-promoted agents are on the calendar, not yet in your hands. Zycus reports an autonomous tail-spend negotiation agent deployed at Tata Play, a vendor-reported case rather than an independent benchmark. Others sit somewhere between demo and general availability.

The buyer's move is the one you already use on any capability claim. Ask to see the agent run on your data, not on a slide. Then decide whether it removes work or just renames it.

The seven tools, and who each one fits

With those two shifts in view, here are the seven tools that handle supplier management well in 2026, and the field around them.

Enterprise source-to-pay suites

These are built for organizations with dedicated procurement teams managing hundreds or thousands of suppliers, and their implementation timelines match that scale.

SAP Ariba is the enterprise reference point. Its supplier network connects millions of trading partners, and its supplier lifecycle tools cover onboarding, risk, and performance. Gartner named it a Leader in its 2026 Magic Quadrant. SAP is now rebuilding Ariba as an AI-native platform, so factor the migration into your timeline. It fits global enterprises, especially SAP shops.

Coupa approaches procurement through total spend management, with supplier information, risk scoring, and spend analytics in one platform. Gartner named it a Leader and positioned it highest for Ability to Execute in 2026, and Forrester rated its current offering highest in its most recent Supplier Value Management evaluation. It fits enterprises consolidating many purchasing channels into one view.

Jaggaer focuses on source-to-pay depth, with sourcing events, supplier analytics, and category management. Gartner named it a Visionary in 2026. It fits organizations with heavy direct-materials spend.

Ivalua is the configurable option, with supplier workflows that bend to fit complex or regulated industries, at the cost of a longer setup than the mid-market tools below. Gartner named it a Leader in 2026. It fits regulated, process-heavy environments.

The Leader field is wider than these four. Gartner's 2026 Magic Quadrant also named GEP, Oracle, and Zycus as Leaders, with GEP positioned highest for Completeness of Vision and Zycus promoted from Visionary the year before. If your shortlist is enterprise-only, those three belong on it.

Mid-market and SMB tools

Kissflow Procurement Cloud targets the mid-market with no-code workflows. Teams tailor supplier onboarding and approval flows without developers, a practical middle ground between rigid SMB tools and heavy enterprise suites.

Precoro serves small and mid-sized teams that want purchasing control fast. Supplier records, catalogs, and purchase-order workflows set up in days, though supplier collaboration features are thinner than in the enterprise platforms. Procurify and Order.co sit nearby if you want spend cards or high-volume goods buying.

Atlassian-native intake-to-procure

Raley Procurement for Jira & JSM takes the intake-to-procure route for one specific world: teams that already run on Atlassian. It is not a standalone platform. It runs inside Jira and Jira Service Management, where many teams already raise requests, and it turns the JSM portal into a procurement front door. Employees request, procurement approves through a workflow you define, finance sees committed spend, and your existing ERP or accounts-payable stack keeps its job. It is Cloud Fortified and free to try. More on what it does, and does not do, below.

If purchase requests already start in Jira or JSM, the shortest path is the one that runs there. Start a free trial of Raley Procurement for Jira & JSM on the Atlassian Marketplace.

The buying criteria that matter in 2026

Feature checklists miss the criteria that decide procurement projects this year. Four are worth adding to your evaluation.

Supplier risk and regulatory transparency. New rules are pushing supplier due diligence deeper into the supply chain. The EU's Corporate Sustainability Due Diligence Directive and its Deforestation Regulation both require companies to know and document their suppliers, and in some cases their suppliers' suppliers. If you operate in or sell into Europe, supplier-risk data and multi-tier visibility are no longer optional.

E-invoicing mandates. Europe is phasing in structured e-invoicing under the VAT in the Digital Age reforms, alongside national mandates already live in several countries. Support for the common formats, Peppol, Factur-X, and XRechnung, is now a real buying criterion for any European operation, not a line-item feature.

Sustainability and Scope 3. Carbon and supplier-sustainability data are moving from separate reporting tools into procurement platforms, so category and supplier decisions can weigh emissions at the point of purchase. Expect this as a standard column in enterprise evaluations rather than an add-on.

Direct and indirect coming together. The suites are unifying direct-materials and indirect purchasing on one platform and one data model, which matters if you have run them in separate systems until now.

For most teams reading this, the spend in question is indirect: software, contractors, agencies, and equipment, requested by every department and spread across hundreds of suppliers. That is the spend supplier management is meant to tame, and it is also the spend most likely to skip the process entirely. If that is your situation, start with indirect procurement: what it is, why it leaks, and how to get it under control, then come back to the tool question.

One caution on market-size figures. You will see the procurement software market sized confidently in vendor decks. Independent estimates for 2025 and 2026 actually range from roughly $8 billion to $11 billion with growth rates in the high single to low double digits, and the scope behind each number varies. Treat any single figure as a range, not a fact.

The already-there test

Before you buy anything, run a short test. Ask three questions.

1. Where do purchase requests start today? If the answer is email or chat, any tool above is an upgrade. If the answer is Jira or JSM tickets, start with what plugs into that.
2. Who owns supplier data? If procurement runs a dedicated team managing hundreds of suppliers, the enterprise suites earn their cost. If finance keeps a catalog of forty suppliers, they do not.
3. What does one more platform cost you? Count logins, admin overhead, and training, not just the license. The cheapest tool is often the one your team never has to leave their workflow to use.

Match the answers to your spend and your stack. Enterprise spend with a dedicated procurement team points to Ariba, Coupa, Jaggaer, Ivalua, and the wider Leader field. Mid-market flexibility points to Kissflow. Fast SMB setup points to Precoro. Requests that already live in Atlassian point to Raley Procurement.

What Raley Procurement is, and is not

Honesty helps you choose faster, so here is the line.

What it does today. Purchase requests raised from the JSM portal. Approvals routed through a workflow you build by product, department, budget, and tier. Order tracking that shows what has been ordered, received, and is still outstanding, from the ticket view. Live dashboards on committed spend across departments and vendors. Multiple currencies and tax rules. It is Cloud Fortified, billed through Atlassian, and free to try on the Marketplace.

What it does not do. It is not a full source-to-pay suite. It does not run sourcing events, RFx, or direct-materials and BOM planning, and it does not replace an enterprise supplier-risk network or a category-management engine. If your spend needs those, the enterprise suites are the right call. Raley Procurement runs on Atlassian Cloud, so it fits teams whose work already lives in Jira or JSM, not teams shopping for a separate system to run on the side.

Decide from your own workflow

The honest summary: the procurement software for you is the one that manages suppliers where your requests already live. Audit where requests start, who owns supplier data, and what a new platform really costs. Weigh the 2026 criteria that apply to you, whether that is supplier risk, e-invoicing, or sustainability. Then trial the shortest path first.

If that path runs through Atlassian, start a free trial of Raley Procurement for Jira & JSM, or book a walkthrough on your own setup first. Prefer to read first? Procurement in Jira: lessons from five years covers what actually happens when purchasing lives in Jira.

FAQ

What are supplier management capabilities in procurement software? Supplier master records, product catalogs with pricing and tax rules, onboarding and compliance tracking, per-supplier order history, and API access to sync supplier data with an ERP. Software that only stores contact details does not qualify.

What is intake-to-procure, and how is it different from source-to-pay? Intake-to-procure starts with the employee request and routes it through approval and ordering inside the tools people already use. Source-to-pay is the broader suite that adds sourcing events, contract management, and supplier-risk networks for large, dedicated procurement teams. Gartner added an intake and orchestration vendor to its source-to-pay research for the first time in 2026, a sign the two are converging.

Which procurement tools have the strongest supplier management? It depends on scale. For large, sourcing-heavy spend with a dedicated team, the enterprise suites in Gartner's 2026 Magic Quadrant carry the supplier-risk networks and category-management depth that scale needs. For mid-market flexibility, Kissflow. For fast setup, Precoro. For teams on Atlassian who want supplier and order data where requests start, Raley Procurement.

Can you run procurement inside Jira or JSM? Yes. Raley Procurement for Jira & JSM raises purchase requests in the JSM portal, routes approvals through a workflow you define, tracks orders from the ticket view, and reports on committed spend, without moving your team to a separate system.

Do small teams need a full procurement platform? Often not. A team raising a few dozen purchase orders a month needs supplier catalogs, approvals, and a clean handoff to accounting. A lightweight tool like Precoro, or an app inside a system you already run like Raley Procurement, covers that without a platform rollout.

Is agentic AI in procurement software ready to rely on? Selectively. Some agents are shipping and useful for narrow tasks such as document capture and tail-spend work. But Gartner has warned that many agentic claims are older automation relabeled, and independent proof is still thin. Pilot any agent on your own data before you count on it.

Related reading

• Indirect procurement: what it is, why it leaks, and how to get it under control
• 5 reasons to run your procurement on Jira or JSM
• Procurement in Jira: lessons from five years
• Managing suppliers and products in Raley Procurement (docs)

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.

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.

Related reading

• Indirect procurement: what it is, why it leaks, and how to get it under control
• Procurement in Jira Service Management: the case for it
• 5 reasons to run your procurement on Jira or JSM
• Procurement in Jira: lessons learned in 5 years
• The benefits of automating your purchasing process with technology

We did something slightly unhinged so you would not have to. We did three separate research reviews in 2025 and 2026 on procurement software. We included most tools that sell to mid-sized companies today. We compared them until we saw a clear pattern. This guide is that pattern.

Here is the headline before you read another word. There is no single winner in procurement software. There is a right tool for the specific thing going wrong in your buying right now, and a crowded field of tools that are wrong for it. The whole job of a buyer's guide is to get you to the right one without paying for the rest. Most guides hand you a ranked list of ten. A ranked list feels comforting and is often useless. The tool ranked third might fit you best. The tool ranked first might be built for a company ten times your size.

So we sorted the field by the problem each tool actually solves, not by a score. Up front: we make one of these tools. That is exactly why the comparison below also tells you when to buy something else, including nothing.

What we found, in four lines

• The label hides six different products. “Procurement software” includes intake tools, procure-to-pay systems, and accounts-payable engines. It also includes corporate-card platforms, source-to-pay suites, and tools inside software you already use. They compete on the shelf and rarely compete for the same buyer.
• Match the tool to the pain, not to your headcount. Two companies of the same size need different tools if their buying breaks in different places.
• In Europe, one filter sits above the rest: e-invoicing law. ViDA and the national mandates make structured e-invoicing a requirement to check, not a feature to admire.
• The cheapest win is often the software you already own. If your team already lives in Jira or Jira Service Management, purchasing may not need a new home at all.

What we did, and why we bothered

We combined three separate research passes from 2025 and 2026.
They covered the US and European markets. We also resolved any differences between them. Then we grouped roughly "thirty tools" by the job they perform rather than the badge they wear. Where the three passes gave a price, we kept it only as a third-party benchmark with the date. Almost none of these vendors publish a real number. Where they cited a market statistic, we kept the firm's name and the year, and softened anything that only one source claimed.

That last habit matters more than it sounds. The procurement software market is estimated at about $9 billion to $10 billion in 2025.
The exact figure depends on how each research firm defines the category.
Mordor Intelligence, Grand View Research, and Fortune Business Insights all estimate within that range as of 2025.¹ Europe is roughly a quarter of it. We are telling you the number and its wobble in the same breath, on purpose. A buyer's guide that hides its uncertainty is just marketing with footnotes.

The 4 jobs each of these tools is doing

Strip the marketing and the entire category comes down to four jobs.

1. Intake: it turns "I need to buy this" into a structured request instead of a Slack message that evaporates.
2. Approval: it routes that request to the right people by rules you set.
3. Ordering: it turns an approved request into a purchase order a supplier will act on.
4. Visibility: it shows finance what is committed, not just what is paid, before the invoice arrives to ruin someone's afternoon.

Everything past those four jobs is an addition, not the definition. Strategic sourcing, contract lifecycle management, supplier risk scoring, and global payments are real capabilities. They explain why one tool costs a few hundred dollars a month. They also explain why the next tool costs a seven-figure annual contract. The jobs stay constant. The additions are what you are actually paying to argue about.

The whole market, grouped by the problem each group solves.

We list vendors as examples of a category, not as ranked contenders. A feature-by-feature cage match belongs in a dedicated comparison, not a field guide.

A quiet seventh option is easy to overlook. It is the procurement module already built into an ERP system. Examples include NetSuite or Dynamics. It carries no reconciliation seam, since the data never leaves the system. It also tends to go unused because the interface was built for the finance team. It was not built for a marketing manager buying a laptop twice a year.

Now, the annotations the table is too small to hold.

Intake and orchestration tools had a good idea: stop trying to replace the ERP. Instead, they become a single front door. They route every request across finance, legal, IT, and security at once. If your spend leaks because there is no obvious way in, this is the fix. Just remember what it is. It orchestrates. It does not become your source of truth.

Classic mid-market procure-to-pay is the workhorse quadrant, and the one most 100-to-1,000-person companies actually need. Requisition, approval, purchase order, budget control, in one accessible tool that a normal human can learn in an afternoon. It has fewer sourcing tools than enterprise suites. This is only an issue if you run formal sourcing events. Most mid-sized teams do not.

Accounts-payable-led platforms come at procurement from the money end. If you struggle with the time between sending an invoice and getting paid, start here.
This is especially true for cross-border payments.
It also applies if you must follow European e-invoicing rules. The procurement features are real but younger than the payments engine underneath them.

Card-led spend platforms start from the corporate card and add purchasing on the side. They are excellent at cards and expenses. They are, by design, lighter on the structured requisition and supplier lifecycle that a procurement team eventually wants.

Enterprise source-to-pay is where the famous names live, and where most mid-market buyers overspend. These suites are magnificent at nine-figure scale and heavy everywhere else. An enterprise suite will cheerfully sell a 200-person company the same platform it sold a 200,000-person one. The demo is identical. The invoice and the implementation calendar are not. Below about $100 million in managed spend, analysts’ guidance points to a lighter option.
Independent buyer research often says these are overbuilt for the mid-market.⁴

Embedded, inside tools you already run, is the newest idea and the one we work in.
So, weigh the next section accordingly. If your company already uses Atlassian, procurement can be part of the platform your team uses every day. It will not be a fifth place that no one remembers to visit.

So which one is for you?

Skip the feature grid. Start with the sorest spot, because the tool that fixes your worst pain is almost always the right first move. We call this the sore-spot shortlist, and it is four questions answered plainly.

Is your worst problem that spend happens outside any process at all, and you already run an ERP? Look at intake and orchestration. Is it that you have no structured requisition, approval, or budget control to begin with? Look at classic mid-market procure-to-pay. Is it the invoice-and-payment end, or a European compliance deadline breathing down your neck? Look at an accounts-payable-led tool. Is it that your buying spans strategic sourcing, contract lifecycle, and several legal entities at real scale? Then, and genuinely only then, look at enterprise source-to-pay.

Answered yes to none of them, or yes to three? That is useful information, not a failure. Pull last quarter's spend and split it two ways: physical goods against software and services, and many small purchases against a few large ones. Whichever quadrant holds the bulk of your money and your requests is the pain you are actually solving. Everything else is a rounding error you can automate later.

One warning that applies to every path. Every demo goes perfectly, because every demo runs on the vendor's tidy sample data. Bring your messy invoice and one real approval case.
Bring the ugly one with an exception.
Then watch what the tool does. Then ask for the first-year total including implementation and your own team's time, not the sticker price. The gap between those two numbers is where budgets go to die.

One more variable: are you buying in the US or in Europe?

The six kinds exist on both sides of the Atlantic. The weighting is what changes, and for European buyers one factor sits above everything else.

In Europe, e-invoicing law is now a hard filter, not a nice-to-have. The EU’s VAT in the Digital Age reform, called ViDA, took effect in 2025. It will roll out in phases through the early 2030s. Mandatory structured e-invoicing for intra-EU B2B transactions will start in 2030 (European Commission, as of 2026).⁵ Several countries move sooner. Germany has required businesses to receive structured e-invoices since 2025. It will phase in issuing rules during 2027 and 2028. France, Belgium, Poland, Italy, and Spain each use their own timelines and formats.
These include Factur-X, XRechnung, Peppol, KSeF, and FatturaPA.
These details come from national tax-authority sources, as of 2026.⁶ If your buying involves VAT-compliant invoicing across EU entities, check each vendor’s structured e-invoicing support first. This step often changes your shortlist.
It usually points you toward Europe-based, accounts-payable-focused tools.
These include Basware, Spendesk, Payhawk, Onventis, and Ivalua.

Europe also adds data residency, currencies, and payment plumbing. GDPR pushes you to confirm EU data hosting. Multi-country groups need real multi-entity and multi-currency handling, verified past the marketing line. Payments use SEPA instead of ACH.
For some vendors, card issuance follows EU or UK rules.
For others, it does not. None of that is on a US buyer's radar, and a European buyer cannot skip any of it.

The US shortlist is shaped by the ERP, not the tax code. US mid-market buyers face lighter invoicing rules. They prefer tools built for NetSuite, QuickBooks, and Sage Intacct. Examples include Ramp, Procurify, Tipalti, and Zip. The decision turns on integration fit and adoption.

The through-line: for a U.S. buyer, the shortlist depends on ERP fit. For a European buyer, compliance comes first, before fit matters. Same six kinds, different order of operations.

Before you buy anything, look at what you already own

Here is the move almost every buyer's guide skips, because no vendor makes money reminding you of it.

Before you sign for a new platform, look hard at the software your team already runs every day. The reason procurement tools sit half empty is rarely the feature list. It is the address. Most people who file a purchase request are not procurement professionals. They buy something a few times a year, and they will not learn a new system to do it. They default to email, a card, a forwarded invoice, and your shiny new tool becomes shelfware. The most expensive procurement software is the one nobody opens.

Your project and service management stack is where those people already are. If your company runs on Jira or Jira Service Management, purchasing does not necessarily need a new home.

It adds a layer to the home you already use. This makes a purchase request one more familiar form. It sits next to IT tickets, and HR requests your team files without thinking.

Raley Procurement for Jira and JSM turns a request from the JSM portal into a purchase order. It creates the order in the same Jira work item. It routes the order through up to three approval tiers. Approvals depend on department and spend limits. It generates a formatted PDF for the supplier. It also tracks orders and deliveries from the same issue. It includes partial receipts. Finance can view committed spend, which means approved orders not yet received. It is shown separately from actual spend in Jira dashboard widgets and CSV exports. It imports up to 1,000 products from a CSV. It handles purchase orders in multiple currencies. It also offers a REST API for hand-off to your ERP. It carries Atlassian's Cloud Fortified trust mark.⁷

Now the part a product page usually hides. It is not a source-to-pay suite, and it does not pretend to be. Strategic sourcing events, contract lifecycle management, and global multi-entity consolidation are jobs for an enterprise platform; if those run your week, buy one. It does not replace your ERP or your accounts-payable stack; it hands off cleanly after approval. And its whole advantage rests on your team already living in Jira. If you are not on Atlassian, one of the other five kinds fits you better, and we would rather tell you that here than sell you the wrong thing.

So the sequence is simple. Diagnose your sorest spot. Weight the region filter. Check what you already own before you buy a new anything. If that stack turns out to be Jira or JSM, try Raley Procurement against your own approval tiers and budget, not a canned demo, and see whether purchasing was a home-improvement job all along rather than a house move.

See Raley Procurement for Jira and JSM on the Atlassian Marketplace or read the full feature breakdown on the product page.

Questions people actually ask

What counts as mid-market for procurement software? Most vendors and analysts treat mid-market as roughly 100 to 1,000 employees, or about $10M to $250M in revenue. The sharper test is complexity: several entities, multiple approval tiers, and spend scattered across teams, but without the dedicated procurement department and nine-figure spend that justify an enterprise suite.

What is the difference between procure-to-pay and source-to-pay? Procure-to-pay covers the transactional flow from requisition to payment. Source-to-pay adds the strategic front end: sourcing suppliers, running competitive events, and managing contracts. Most mid-sized companies need procure-to-pay plus light sourcing, not a full source-to-pay suite.

How much does mid-market procurement software cost? It ranges widely. Purpose-built mid-market tools start from a few hundred dollars a month, with Precoro listing from about $499 and Tradogram from about $225, into the low tens of thousands a year. Enterprise source-to-pay suites are quote-based and typically run from tens of thousands into six and seven figures once implementation is counted (third-party benchmarks, as of 2026, not vendor list prices).

How is buying procurement software different in Europe versus the US? The biggest difference is e-invoicing law. The EU's ViDA reform and national mandates in Germany, France, Belgium, Poland, Italy, and Spain are phasing in mandatory structured e-invoicing between 2025 and the early 2030s, so European buyers must confirm support for formats like Peppol, Factur-X, and XRechnung, plus GDPR data residency and SEPA payment rails. US buyers face lighter regulation and choose mainly on ERP fit.

What is committed spend, and why does it matter? Committed spend is money already promised to a supplier through an approved purchase order, whether or not the invoice has landed. Tools that show committed spend separately from paid spend prevent the quarter-close surprise where approved orders were never counted against the budget.

Can you run procurement inside Jira? Yes. With an app such as Raley Procurement for Jira and JSM, a team already on Atlassian can raise requests in the JSM portal, route multi-tier approvals, generate PDF purchase orders, and track committed spend, all inside the Jira work items they already use.

How should I compare procurement tools without drowning in feature lists? Start with your sorest pain, not a grid. Identify which of the four core jobs is actually failing, apply the region filter, then shortlist the two or three tools built for that job and test each with your own real approval scenario and messy invoice. Ask every vendor for the first-year total including implementation, and for references at your size and on your ERP.

What we pulled together to write this

This guide combines findings from three independent research reviews from 2025 to 2026. It covers the mid-market procurement software market in the US and Europe. The results were checked against official product documentation. Sources are numbered below, and the superscripts in the text point to them.

1. Market sizing: Mordor Intelligence, Grand View Research, and Fortune Business Insights, 2025 estimates. About $9 billion to $10 billion in 2025, Europe roughly a quarter. Figures vary by scope and method.
2. Pricing benchmarks: third-party sources such as Vendr for quote-only vendors, 2026. Order of magnitude only, not vendor list prices.
3. Vendor list pricing: Precoro from about $499 a month and Tradogram from about $225 a month, 2026.
4. Analyst guidance: Gartner, Magic Quadrant for Source-to-Pay Suites, 2025, and its forecast on agentic AI in supply-chain and procurement software, January 2026. Spend Matters, part of The Hackett Group, SolutionMap, 2025.
5. EU e-invoicing: European Commission, VAT in the Digital Age, ViDA, in force 2025. Mandatory intra-EU business-to-business structured e-invoicing from 2030.
6. National e-invoicing mandates: tax-authority guidance for Germany, France, Belgium, Poland, Italy, and Spain. Formats include Factur-X, XRechnung, Peppol, KSeF, and FatturaPA. As of 2026.
7. First-party product facts: RaleyApps product documentation and the Atlassian Marketplace listing for Raley Procurement for Jira and JSM.

A note on method, because you deserve it. Pricing in this market is mostly private. Review scores change month to month. We read G2, Capterra, and Gartner Peer Insights for direction, not scores. Analyst rankings use an enterprise view that may not fit mid-sized buyers. We have flagged uncertainty rather than papered over it. Treat every number here as directional and verify anything you are about to spend real money on.

Related reading:

• Why procurement belongs in Jira Service Management
• 5 reasons to run your procurement on Jira or JSM
• Procurement in Jira: 8 lessons from five years in the field
• Why intake-to-procure belongs in JSM
• How a growing software team brought purchase approvals into Jira

Most procurement software comparisons start with a vendor shortlist. This one starts with a harder question: do you need a dedicated platform at all, or does procurement belong inside the tools your team already runs?

Procurement management software handles four jobs: intake (capturing what someone wants to buy), approval routing (getting the right sign-offs in the right order), purchase order generation (turning an approved request into a document a vendor can act on), and budget tracking (showing what is committed, not just what is paid). You can get those four jobs done three ways: a standalone platform such as Coupa, Zip, or Precoro; a module inside your ERP; or a layer built into the tools your team already runs every day. None of the three is universally right. This article names the criteria that decide it, not a ranked list of vendors.

What procurement management software actually does

Strip away the marketing language and procurement management software does four concrete jobs.

Intake. Someone needs to buy something. The software gives them a structured way to ask, instead of an email or a verbal "just order it," so the request carries the information procurement actually needs: what, how much, which budget, which cost center and GL account, which vendor.

Approval routing. The request moves to the right approver, or sequence of approvers, based on rules such as amount, department, or product category. A small office-supplies order might need one sign-off. A six-figure renewal might need finance, a department head, and a budget owner, in that order.

Purchase order generation. Once approved, the system turns the request into a formatted purchase order a vendor can act on, without someone rebuilding it in a document editor.

Budget and supplier tracking. The tool shows what has been requested, approved, and ordered against a budget, and keeps a record of who you buy from and what you have paid them historically.

That is the category. Everything else is an addition, not the definition: AI-assisted sourcing, contract lifecycle management, supplier risk scoring, spend analytics dashboards. Some tools build these. Others skip them.

Why teams look for this in the first place

Most teams do not start evaluating procurement software because someone read about it. They start because a specific failure already happened: a purchase order that should have needed two sign-offs only got one, a department blew through its quarterly budget and nobody noticed until the invoice arrived, or finance spent a week reconstructing what was actually committed to vendors this quarter because half of it lived in email threads.

Vendors list real benefits: streamlined operations, better supplier relationships, cost control, an audit trail for compliance. All of it is downstream of one thing. A purchase request needs a single, visible path from requisition to approval to order, not three different informal paths depending on who is buying and how urgent it feels. Software does not create that path. It enforces the one you design.

The three paths, and who each one actually fits

Once a team accepts it needs procurement management software rather than an ad hoc process, there are three real ways to get it, not one.

Path 1:
a standalone procurement or source-to-pay platform. Tools such as Coupa, Zip, Precoro, and Tradogram are independent systems built to be the center of your procurement function. They are strong at spend management, sourcing, and supplier programs at scale, and they are the right call once your organization has multiple entities, high supplier count, or contract lifecycle needs that outgrow a single approval workflow. The tradeoff is real: a new login, a new system to administer, and an adoption cost, since most requesters use the tool a handful of times a year and will default back to email the moment it is friction.

Path 2: a module inside your ERP. If you already run SAP, Oracle, or NetSuite, procurement functionality built into that ERP keeps purchasing in the same financial system of record. This fits organizations where procurement is inseparable from broader financial consolidation, multi-entity accounting, or where IT policy strongly prefers one vendor for core systems. The tradeoff is that ERP procurement modules are often built for the finance team's needs first, and the day-to-day requester experience, the person actually asking to buy a laptop, can be clunky compared to a purpose-built intake tool.

Path 3: a layer inside the tools your team already runs. For a team standardized on Atlassian, meaning Jira and Jira Service Management already handle IT tickets, HR requests, and other internal service work, procurement can be a layer on that same platform instead of a new destination. Raley Procurement for Jira and JSM is built for exactly this: an app that adds structured purchase requests, tiered approval routing, purchase order generation, and budget tracking directly inside the JSM portal your team already opens. This path wins on adoption (no new login, no new system to learn) and cost (a per-user Marketplace subscription rather than an enterprise contract), and it is the wrong call if your organization is not standardized on Atlassian, or if you need the sourcing, supplier-risk, and contract-management depth that a dedicated platform provides.

None of the three paths wins by default. They fit different situations, and most of the evaluation work is figuring out which situation you are actually in

The Three-Path Procurement Decision Framework

Use these questions in order. The first one you answer "yes, strongly" to points you at your path.

1. Is procurement large and complex enough to be its own function? Multiple legal entities, a large or global supplier base, formal sourcing events (RFQ, RFP), or dedicated contract-management needs point to Path 1, a standalone platform.
2. Is your organization already standardized on a single ERP for financial operations, with procurement expected to live inside it by IT or finance policy? That points to Path 2, an ERP module.
3. Is your team already running Jira and Jira Service Management for other internal service work (IT, HR, facilities), and is procurement a core function among several, not a dedicated department with sourcing and supplier-risk needs? That points to Path 3, a Jira-native layer.

If you answered no to all three, or yes to more than one, the realistic next step is a short internal audit: walk last quarter's purchases and sort them into what came through a structured request, what came through email or Slack, and what was never formally requested at all. That audit tells you which of the three paths you are actually solving for, better than a feature checklist does.

Cloud-based procurement software: what changes and what does not

Most procurement management software vendors today, across all three paths, ship as a cloud-based procurement platform rather than an on-premise install. Cloud is now the dominant delivery model, roughly 70%+ of the market by recent industry estimates, with on-premise persisting mainly among large enterprises with strict security or data-control requirements. That shift changed deployment and maintenance: updates roll out centrally, and there is no local server to patch. It did not change the core evaluation question. A cloud-based procurement platform, an ERP procurement module hosted in the cloud, and a Jira-native procurement layer are all cloud-delivered in 2026. The distinction that actually matters for your decision isn't cloud versus on-premise. It's standalone versus embedded, which is what the three-path framework above addresses directly.

The same three paths apply to IT procurement: buying hardware, software licenses, and IT services. There's one addition. If your IT team already tracks assets in Jira Service Management, a Jira-native procurement layer keeps IT purchasing next to the asset and ticket data IT already manages, rather than in a fourth system.

Key features to check, whichever path you take

Whichever path fits, evaluate the tool against the same feature list, since the category's job does not change:

• Structured intake, not a free-text form bolted onto a generic ticket. Can it capture budget code, cost center, and vendor detail at the point of request?
• Configurable approval tiers by amount, department, product, budget, cost center, or GL account, not a single fixed approver chain.
• Purchase order generation with a formatted document a vendor can act on, not a manual rebuild in a separate editor.
• Budget tracking that shows committed spend, meaning purchase orders already approved but not yet invoiced, separately from spend already paid. A tool that only shows paid spend hides the number finance actually needs at quarter close.
• Supplier and product records that persist across requests, rather than re-entering vendor details every time.
• Multi-currency support, if you buy from vendors outside your home currency.
• A REST API or a clean export path to your ERP or accounting system for the financial transaction (matching, invoicing, payment), since procurement software should hand off cleanly rather than try to replace financial execution.

Miss the budget-commitment view, and you've missed the point. Procurement software that skips it tends to produce the exact surprise procurement software is supposed to prevent: a department finds out it is over budget only when the invoice lands, not when the purchase order was approved weeks earlier.

How to decide, in practice

Run the Three-Path Procurement Decision Framework rigorously, including the audit step if you answered no to all three or yes to more than one. Then check the feature list against the path you land on. The underlying job stays the same no matter which path delivers it: intake, routing, PO generation, budget visibility.

If you land on Path 3, the next step is seeing it against your own approval tiers and budget structure, not a generic demo. That's who Path 3 is for: teams already on Jira and JSM, where procurement is a core function among several, not a dedicated department with its own sourcing and supplier-risk needs.

See Raley Procurement for Jira & JSM on the Atlassian Marketplace or learn more on the Raley Procurement page.

What is procurement management software?
Software that handles four jobs: capturing purchase requests in a structured way (intake), routing them to the right approvers based on rules like amount or department (approval routing), turning approved requests into a formatted document for the vendor (purchase order generation), and tracking spend against budget, including what is committed but not yet invoiced (budget tracking). Everything beyond those four is an addition some tools make, not part of the core definition: sourcing, contract management, supplier risk scoring.

What are the main benefits of procurement management software?
Streamlined operations, better supplier management, cost efficiency, compliance transparency: the commonly cited benefits all trace to one underlying change. A purchase request gets one visible, enforced path from requisition to order instead of several informal ones. Cost efficiency in particular tends to come from catching budget overruns at approval time rather than at invoice time.

What is the difference between procurement software and an ERP purchasing module?
An ERP purchasing module lives inside your enterprise resource planning system (SAP, Oracle, NetSuite) and keeps procurement in the same financial system of record, which suits organizations where procurement is tightly bound to financial consolidation. Standalone procurement software and Jira-native procurement layers sit outside the ERP and hand off approved purchase orders to it for the actual financial transaction. Neither is universally better; it depends on whether your organization is ERP-led or needs procurement to live where day-to-day requesters and approvers already work.

Do I need a standalone procurement platform, or is a lighter tool enough?
It depends on scale and complexity, not company size alone. A standalone platform such as Coupa, Zip, or Precoro earns its cost when you have multiple legal entities, a large or international supplier base, formal sourcing events, or dedicated contract-lifecycle needs. Below that complexity, especially for a team already standardized on Jira and JSM, a procurement layer built into the tools you already use tends to deliver the same core jobs without a new system to adopt: intake, approval, PO generation, budget tracking.

What should small businesses look for in procurement software?
The same four core capabilities as any team: structured intake, configurable approval routing, purchase order generation, and budget tracking that separates committed spend from paid spend. Smaller teams typically do not need sourcing modules or supplier-risk scoring yet, so a lighter, cheaper tool that covers the core four without the enterprise overhead is usually the better fit than a full source-to-pay suite.

Are cloud-based procurement platforms different from on-premise procurement software?
In 2026, most active vendors ship as cloud-based, across all three paths: standalone platforms, ERP modules, embedded layers. Cloud is the dominant model, roughly 70%+ of the market, though on-premise still persists among large enterprises with strict security or data-control requirements. The meaningful choice isn't cloud versus on-premise. It's standalone versus embedded in the tools you already run, which is what the Three-Path Procurement Decision Framework in this article addresses.

How do I compare procurement software vendors without getting lost in feature lists?
Start with the three-path question (standalone platform, ERP module, or a layer inside tools you already run), since that filters out most vendors that do not fit your situation before you compare features at all. Within the path that fits, check the same core list every time: structured intake, configurable approval tiers, purchase order generation, and a budget view that shows committed spend, not just paid spend.

• Why procurement belongs in Jira Service Management
• Why intake-to-procure belongs in Jira Service Management
• Jira vs Jira Service Management: which one should run procurement intake
• 5 reasons to run your procurement on Jira or JSM
• Procurement in Jira: 8 lessons from five years in the field
• How a growing software team brought purchase approvals into Jira

Why this question matters more than it looks

A surprising number of Raley conversations start with the same question: should we run our procurement intake out of a Jira Software project or a Jira Service Management (JSM) service project? While this sounds technical it is actually one of the most consequential design choices a team will make. It affects who can submit requests, how approvals work, what the audit trail looks like, and how much it costs to license. Most teams pick a side on instinct, get six months in, and discover they chose wrong.

This is a guide to choosing deliberately. We will cover what each option actually gives you, the real cost difference, the operational implications, and which choice fits which kind of organization. By the end you will know where your procurement intake should live, and why.

Procurement intake is a strange workload. The submitters are everyone in the company: the marketing manager filing a quarterly software request, the engineering lead asking for a new contractor, the office admin restocking supplies. The approvers are a small group of specialists: procurement, finance, legal, security, IT. The work itself involves structured data (cost, vendor, line items), conversational back and forth, and links to other systems (the supplier, the ERP, the contract repo).

Atlassian gives you two ways to model this:

• Jira (Software) project. Internal-facing, every participant is a Jira licensed user, designed for teams collaborating on work.
• Jira Service Management project. Has a customer portal, supports licensed agents and unlicensed customers or requesters, designed for service workflows.

Both can hold purchase requests. Both support workflows and approvals. Both have automation. But the architecture, the licensing model, and the user experience are genuinely different, and one of them is far better suited to procurement intake for most organizations.

What Jira Software gives you for procurement

A Jira Software project for procurement looks like an internal team's project. The procurement team is the "team," every purchase request becomes a Jira issue (typically of type "Request" or "Purchase Order"), and approvers and contributors interact directly in the issue.

Strengths. The biggest strength is familiarity for procurement. The procurement team's daily work, tracking purchases, managing line items, reporting on status, happens in the same interface they would use for any other Jira project: boards, lists, backlogs, sprints if relevant. The data model is rich. Issue types, custom fields, workflows, screens, components, and versions are all available. Issue links are powerful too. A purchase request can link to a security review issue in the IT project, a contract review issue in the Legal project, a vendor onboarding issue in the Finance project. Each function lives in its own project with its own queues and permissions, and the procurement issue is the spine that ties them together. Reporting is mature: custom JQL queries, dashboards, gadgets, exports. Procurement's own metrics, cycle time, approval bottlenecks, vendor spend distribution, are first-class queryable data.

Weaknesses. Every requester needs a Jira license. In Atlassian Cloud, a Jira Standard user costs roughly $8 per month, Premium closer to $16. For a 500-person company where most employees file maybe one purchase request per quarter, this is a serious overspend, tens of thousands of dollars a year in Jira licenses for users who interact with procurement four times a year. The submission experience is wrong for occasional users too. A first-time requester opens Jira and sees a board full of issue cards they don't understand, navigation built for power users, and an issue-create form with fields designed for someone who lives in Jira. It's not bad software, it's just not designed for the once-a-quarter user, and adoption suffers as a result: spend leaks back into email and credit cards. There's no native customer portal, so the request experience is the same as a developer creating a bug ticket. You can build forms and templates, but you're working against the grain of what Jira Software is for. Permissions get complicated fast, too. Procurement requests often contain sensitive data: supplier negotiations, salary information, confidential contracts. Locking down a Jira Software project so only the right people see the right things requires careful permission-scheme work, and mistakes leak data.

What JSM gives you for procurement

A JSM service project for procurement separates the two audiences cleanly. Agents, meaning procurement, finance, and IT, work in Jira, while customers, meaning employees filing requests, interact with a clean portal. The same purchase request exists in both places, but each audience sees the version designed for them.

Strengths. The portal is the right UX for occasional submitters. A marketing manager who files a purchase request once a quarter sees a friendly form with help text, required fields, and clear status updates after submission, the same experience they already have for IT tickets or HR requests. No Jira power-user navigation, no issue cards, no boards, just a form and a status page. License costs are dramatically lower, because JSM charges per agent (the procurement team and approvers), not per customer. Everyone else in the company submits requests for free. For a 500-person company with a 5-person procurement team, that license-cost difference runs roughly an order of magnitude versus licensing everyone under Jira Software. Approvals are native: JSM has built-in approval functionality with first-class objects, approvers, approval state, escalation, so you don't need an add-on to build a basic approval workflow. SLAs are native too. JSM tracks time-to-first-response, time-to-resolution, and custom SLAs out of the box, so a purchase request sitting unapproved for five days triggers an alert without any custom automation. Permissions are cleaner, because JSM's customer/agent separation handles data sensitivity at the model level: customers see what they submitted and any updates, agents see everything, with no permission-scheme gymnastics required. Cross-functional routing is the use case JSM is built for. A purchase request that needs security review, legal review, and finance approval can spawn linked tickets in each function's queue, with each team working in its own JSM project. This is what Atlassian designed JSM to do for IT support, and it works just as well for procurement intake.

Weaknesses. JSM is more constrained than Jira Software in some places. Issue type schemes, custom fields, and workflows are still configurable, but the customer portal imposes its own UX patterns; you can't make it look exactly like anything you want, it's the JSM portal. For procurement teams who also want a project-management view of their own work, planning sprints, managing backlogs, capacity planning, JSM alone is less powerful than a Jira Software project. You can run both, keeping procurement's internal work in a Jira Software project and intake in JSM, but that adds a system to manage. JSM's own licensing model is worth understanding too: agent costs scale faster than Jira Software per-user costs once you have many agents. For very large procurement teams (say, 50 or more procurement, finance, and approval-related agents), the math starts to swing back the other way, though not by enough to overcome the customer-license savings. And customizing the portal UX has limits: you can't deeply customize its navigation structure or build entirely custom interfaces inside it. The portal looks like the portal.

Is JSM actually cheaper than Jira Software for procurement?

Cost is where this decision usually gets made, so let's make it explicit with a sample scenario: a 500-person company, a 5-person procurement team, 50 occasional approvers across departments, and 100 active requesters per quarter.

That's a roughly 12x cost difference in Atlassian licensing. For procurement intake specifically, JSM wins on cost by an order of magnitude.

The picture changes if the company already has 500 Jira Software licenses for unrelated reasons, for example engineering already runs on Jira Software, so the marginal cost of adding procurement intake there is zero. In that case, Jira Software intake costs nothing additional. This is true for some Raley customers, and it's a legitimate reason to choose Jira Software despite its other limitations.

The user experience comparison

A side-by-side of what each option feels like in practice:

The Jira Software experience is excellent if everyone is already a Jira power user. It's clumsy if half your submitters open Jira once a quarter.

When should you use Jira Software instead of JSM?

Jira Software wins for procurement intake when:

• Your company is small and everyone already has Jira Software licenses for other reasons (engineering-heavy startups under roughly 100 people).
• Your procurement team wants deep project-management-style features for their own work, not just intake.
• Your requesters are technical and Jira-fluent (engineering tools companies, dev shops).
• You're already comfortable building permission schemes and custom workflows.
• Your approval workflow depends on sub-tasks (a parent request split into child approval steps). JSM can't tie a request type to a sub-task, so sub-tasks stay off the customer portal; the JSM equivalent is issue linking, not true parent-child sub-tasks.
• Cost is genuinely not a factor.

JSM wins for procurement intake when:

• Your requesters are not Jira power users, which covers most non-engineering teams.
• You want the customer portal experience for occasional submitters.
• Cross-functional approvals are part of your workflow: security review, legal review, finance approval.
• You already run JSM for IT or HR, so procurement becomes one more service workflow.
• License cost matters, which is nearly always true and especially so for larger companies.
• SLA tracking is a requirement.

For Raley's customer, JSM is the right answer more than 90% of the time. The licensing math alone justifies it. The portal UX is the part that makes adoption stick.

Why Raley supports both, but recommends JSM

Raley works inside both Jira Software projects and JSM service projects. The data model, purchase orders, suppliers, budgets, approval matrices, is the same either way. The procurement workflows, PO generation, goods receipt, and committed-spend dashboards, work identically regardless of project type. See how the Raley Procurement product page breaks down what runs on top of either setup.

What differs is the intake experience, and that's where the choice matters. With JSM, requests come in through the customer portal. With Jira Software, requests come in through the Jira create-issue flow. Both produce the same downstream procurement workflow, but the upstream submission experience is meaningfully different.

For organizations with technical, Jira-fluent submitter populations and a small total user base, Jira Software is workable. For everyone else, JSM is the right architecture for procurement intake. We recommend JSM in nearly every new deployment, and the reason has very little to do with Raley specifically; it has to do with what JSM was designed for. For the fuller argument on why intake itself is a service-orchestration problem, see why intake-to-procure belongs in Jira Service Management.

A practical decision framework

If you're choosing today, walk through these five questions in order.

1. Are most of your purchase requesters non-engineering employees? If yes, JSM. If they're all engineers and ops-fluent users, you can consider Jira Software.
2. Do you already have JSM running for IT or HR? If yes, JSM: procurement becomes another service workflow on the same platform.
3. Will procurement requests need to touch other functions, such as security, legal, or finance, for cross-functional review? If yes, JSM: that's exactly what JSM is built to orchestrate across.
4. Is Atlassian licensing cost a real constraint? If yes, JSM: the customer/agent model is dramatically cheaper for procurement intake's user mix.
5. Are you a small team where everyone is already a Jira Software user? If yes, Jira Software is workable. Otherwise, JSM.

One structural exception sits under these questions: if your approval routing runs on sub-tasks (a parent request with child approval steps approvers act on directly), Jira Software handles it natively. JSM can't associate a request type with a sub-task, so its portal-facing equivalent is issue linking rather than a parent-child hierarchy. Narrow, but real.

In practical terms, this framework points to JSM for the overwhelming majority of organizations evaluating Raley. The exceptions are real, but narrow. For more on how procurement's day-to-day operating patterns play out once intake is settled, see procurement in Jira: 8 lessons from five years in the field.

The deeper point

The Jira-versus-JSM choice for procurement intake isn't really about Jira and JSM. It's about a more fundamental question: is procurement a function used by everyone in the company occasionally, or is it the procurement team's own internal work?

If it's the team's own work, Jira Software's project-management strengths fit. If it's a service the whole company consumes, JSM's customer-portal model fits.

For modern procurement intake, where the goal is to capture all spend by making it easy for any employee to file a request through a familiar portal, the answer is almost always JSM. That's the architectural insight behind intake-to-procure as a category, and it's why Raley's positioning leans into JSM as the natural home for procurement intake inside Atlassian. Ready to see it running on your own instance? See how Raley Procurement works on JSM.

Here are some examples of how to turn the JSM portal into a procurement use case.

What's the actual difference between Jira and Jira Service Management?

Jira Software is built for a team collaborating on its own work, every participant holds a Jira license, and the interface is issue-and-board oriented. Jira Service Management adds a customer portal and a licensed-agent-plus-unlicensed-customer model, so people outside the core team can submit requests through a simple form without a Jira license. Both sit on the same underlying platform and can hold the same kind of structured data; the difference is who is expected to use each one and how they access it.

Is JSM cheaper than Jira Software for procurement intake?

Yes, usually by a wide margin. In our sample scenario, a 500-person company with a 5-person procurement team and roughly 10 cross-functional approvers, licensing everyone under Jira Software runs about $48,000 a year, while running the same setup on JSM (15 licensed agents, with every requester free as a customer) runs about $3,600 a year, roughly a 13x difference. That gap narrows only if the company already has Jira Software licenses for everyone for unrelated reasons, such as an engineering-heavy organization, in which case the marginal cost of Jira Software intake can be zero.

Can non-Jira users submit procurement requests?

Yes, through JSM's customer portal, and this is one of its core advantages for procurement. A requester doesn't need a Jira license or any Jira familiarity: they open a portal link, fill out a form with help text and required fields, and see a simplified status page afterward. In a Jira Software project, by contrast, every requester needs a Jira license and has to navigate the same interface a developer would use to file a bug.

Does Raley Procurement work the same way in both Jira and JSM?

The underlying data model and downstream workflow are identical either way: purchase orders, suppliers, budgets, approval matrices, PO generation, goods receipt, and committed-spend dashboards all work the same. What differs is only the intake step. In JSM, requests arrive through the customer portal; in Jira Software, they arrive through the standard Jira create-issue flow. Everything after that point is the same procurement workflow.

When should procurement use Jira Software instead of JSM?

Mainly when the requester population is small and already Jira-licensed for other reasons, for example an engineering-heavy company under roughly 100 people, or when the procurement team specifically wants deep project-management features, sprints, backlogs, capacity planning, for its own internal work rather than just intake. Outside of those narrower cases, JSM's licensing cost and portal experience make it the better fit for most organizations evaluating Raley.

Raley Procurement runs on both Jira Software and Jira Service Management. See how Raley Procurement works, or read 5 reasons to run your procurement on Jira or JSM for the shorter version of this argument.

Intake-to-procure is a service-request and orchestration problem. The intake layer of procurement should live in JSM, and here is why.

What intake-to-procure actually is

Intake-to-procure is the gap between "I need to buy something" and "this is an approved, well-formed request ready to become a purchase order in your ERP." Everything that determines quality and control happens in that gap:

• Capturing the request in a structured way.
• Enriching it with the context procurement needs: cost centers, GL accounts, categories, budget, vendor, justification.
• Triaging and routing it to the right reviewers.
• Gathering approvals, often across several functions.
• Handing a clean, approved request off to the ERP system that executes the purchase and tracks invoicing, payments, and deliverables.

It is the front door of the process, separate from the financial execution (PO issuance, receiving, invoicing, payment) that an ERP or AP system owns.

Intake is about capturing the business need. Orchestration is about routing it to the right approvers.

Why intake breaks in most companies

Intake spreads across every channel an employee can find: an email to a manager, a Slack DM to finance, a half-filled form, a ticket raised in the wrong project. The symptoms are familiar to anyone who has worked in operations. These are the four we all fall for.

1. No single front door. 
   Requesters do not know where to go, so they go wherever they can. Finance and procurement teams then spend their day chasing context instead of processing requests.
2. Garbage in, inconsistent information out. 
   Free-text requests arrive missing the business justification, the cost center, the GL account, the category. The first thing procurement does is bounce them back, and the clock resets.
3. Invisible routing. 
   Approvals happen inside private inboxes. Nobody can see where a request is, who is sitting on it, or how many days it has been stuck. Good luck with the auditors.
4. Maverick spend. 
   When the official path takes too long or hurts too much, people quietly route around it, and unvetted vendors and purchases slip through.

These are not the financial problem. They are intake, triage, routing, and visibility problems. The exact problem, Jira Service Management already solved well for IT and HR.

Leverage JSM for IT, HR or Procurement, it is perfect tool to solves these common mistakes

IT and HR service management ran into these same four problems years ago, and JSM was built to solve them. Here is how each piece maps onto procurement intake.

A single portal as the front door. JSM gives requesters one familiar place to ask for what they need, the same portal they already use for IT and HR. One front door is the highest-leverage fix for fragmented intake, full stop.

Structured, validatable request forms. Request types with conditional, validated fields enforce quality at the source, so requests arrive complete instead of getting bounced.

Triage, queues, and SLAs. JSM was built to receive a stream of requests, sort them, route them, and hold them to response times. That is exactly what an intake function needs, and exactly what email can never give you.

Workflow and automation. Jira's workflow engine and automation rules route requests, escalate the stalled ones, and move work through stages without a human shepherding every step.

Cross-functional approvals. Procurement intake almost always needs sign-off from more than one team: budget owner, finance, legal, security. JSM gathers those approvals inside one tracked request, in a defined order.

Visibility by default. Because every request is a ticket, status, ownership, and aging are visible to everyone. That is the transparency inbox-based approvals destroy.

A data backbone in Assets/ERP. Vendors, budgets, departments, and products can live in JSM Assets or ERP and be referenced at intake, so requests are enriched against managed master data instead of typed in by hand.

Make intake-to-procure orchestration easier with Raley Procurement for JSM

A ready to use "Intake to Procure Orchestration template via JSM add-on app" without heavy setup and configuration that solves the same problem with proper procurement functions.

1. One portal entry point for "I need to buy, I need a new vendor, I need a quote," so requesters never have to know which downstream process applies.
2. Validation and enrichment at intake, pulling cost centers, budgets, and approved vendors from Assets/ERP so the request is well-formed before a human touches it.
3. Distinct request types behind that door (purchase request, new vendor, price change, quote), each with a form tuned to collect exactly what that process needs.
4. Automated triage and routing that sends each request down the right approval path based on amount, cost-center, category, and department.
5. Ordered, cross-functional approvals with notifications that fire in sequence, plus visible status and SLAs the whole way through.
6. Total Visibility on Budgeting, Cost Center, GL Account and Intake Status. Requesters get visibility on their requests status, the approver get notifications and able to see budget and Cost Center from year to year before making decision.

This is where a purpose-built app like Raley Procurement earns its place. It delivers structured purchase requests, vendor management, cost-center / cross-functional approvals, and PO generation on top of JSM out of the box, so you are shaping an intake process rather than assembling one from parts.

How is intake-to-procure different from procure-to-pay (P2P)?

Intake-to-procure is the front of the process: capturing a need, enriching it, routing it, and gathering approvals until the request is well-formed and ready to become a purchase order. Procure-to-pay (P2P) picks up after the PO and runs through receiving, three-way matching, invoicing, and payment. Intake-to-procure is a service-request and orchestration job, which is why it fits Jira Service Management; procure-to-pay is a financial transaction, which is why it belongs in your ERP or AP system.

Should procurement intake live in JSM or in my ERP?

Split it by job. Intake and orchestration (capture, enrichment, routing, approvals, visibility) belong in JSM, because they are service-request problems. The financial transaction (three-way matching, invoicing, payment) belongs in your ERP or AP stack. The point of putting intake in JSM is that the request arrives at the ERP boundary already structured, approved, and traceable.

The bottom line, Do I need an app, or can I build intake in JSM myself?

You can, but why? get the 30days free trials and spend your time doing something you love.

A purpose-built app like Raley Procurement delivers structured purchase requests, vendor management, budget-aware approvals, and PO generation on top of JSM out of the box.

The decision comes down to how complex your intake is and how much Jira configuration time you want to spend.

For the last decade, every new generation of procurement software has tried to fix that the same way: build a better dedicated tool and trust that people will use it. Better intake forms. Cleaner approval flows. Friendlier dashboards. More AI. The results, to be charitable, have been mixed. If you have spent six or seven figures on intake-to-procure software and half your company spend still goes around it, the problem is not the feature list. It is the address.

The adoption problem is a location problem

Procurement is the rare enterprise function whose software is used most heavily by people who are not procurement professionals. A CFO opens the finance system every day. An engineer lives in the code repository. A salesperson never leaves the CRM. Those tools earn their adoption because they are indispensable to the daily work of their main users.

A purchase request is different. A marketing manager files one once a quarter. An engineering lead, maybe twice a year. A department head does it occasionally, and reluctantly. These are exactly the people procurement needs to capture, and they have the least reason in the world to learn a new system for it. So they take the path of least resistance: a Slack message, an email to the vendor, a corporate card, a forwarded invoice. The procurement tool sits there, beautifully designed and mostly empty. That is the real problem with intake-to-procure, and it has very little to do with which vendor has the better feature grid.

The "front door" idea has a logical conclusion

The intake-to-procure category has correctly diagnosed the symptom: procurement needs an easy, friendly, and obvious front door. Modern tools have poured real effort into consumer-grade interfaces, conversational AI assistants, Slack and Teams bots, and mobile-first design, all to lower the friction of filing a request. Those are genuine improvements.

But they share one quiet assumption: that the answer is still a better dedicated procurement tool, one the requester has to remember exists, navigate to, and learn. There is another option, and most teams have not seriously weighed it: put procurement inside the tool the requester already opens every day for everything else. Follow the front-door logic all the way down, and you do not end up at a nicer door. You end up not needing a separate building.

What "everything else" actually looks like

In most mid-market and enterprise organizations, there is already one system where employees file requests, get them routed for approval, track status, and see them resolved. It is where they ask IT for a laptop, request HR onboarding, raise a facilities ticket, and send a question to legal. In a growing number of these companies, that system is Atlassian's Jira Service Management.

JSM is no longer just an IT service desk. Over the past several years, Atlassian has broadened it into a general-purpose internal service platform: HR portals, legal intake, facilities, employee experience, and, in some cases, finance operations all run through customized JSM projects. A very large base of organizations has made that investment, and a great many employees now treat filing a JSM request as a basic workplace skill, the way they treat sending an email. For those companies, the question changes shape. It stops being "which procurement tool should we buy?" and becomes "why are we asking our people to learn a different system for procurement when they already know how to file a request?"

The architectural argument

There is a clean architectural reason this works, separate from the user experience. Almost every requirement of an intake-to-procure platform- request forms, multi-level approvals, dynamic routing, queues, SLAs, audit trails, cross-functional collaboration, status visibility, and integrations- is something Atlassian's platform was built to do from the start. JSM did not invent the intake-and-approval pattern. It industrialized it.

When procurement runs inside Atlassian, the plumbing comes with the building. Approval routing, comment threads, attachments, status tracking, audit history, permissions, SSO, mobile access, and cross-team collaboration are all inherited from a platform with a decade of investment behind them. What still has to be built is the procurement layer itself: purchase order generation, vendor master data, multi-currency, budget controls, supplier risk screening, spend analytics, and the link to finance systems. Those are real features and real work, but they sit on top of an orchestration engine that already exists. Here is the same comparison, side by side.

A standalone tool has to build the whole orchestration layer: forms, routing, approvals, queues, audit log, permissions, mobile, identity, and then the procurement layer on top. That is years of engineering to reach the baseline an Atlassian customer already has running today.

Cross-functional approval, where Atlassian quietly wins

The hardest part of modern procurement is not approval inside the procurement team. It is coordinating everyone else who has to weigh in on a purchase: IT security, legal, finance, privacy, compliance, and department heads. This is where procurement software tends to break down, and where procurement projects stall. A SaaS purchase needs a security questionnaire. A new vendor needs a data protection review. A contract needs legal sign-off. A large purchase needs the CFO. Each of those reviews lives with a different team, on a different SLA, in a different tool.

Atlassian has spent ten years making that kind of work easy. Issues link to other issues across projects. Each team keeps its own queue and its own workflow. The requester sees one unified status across every linked review, and approvers see only the requests that concern them rather than a flood from other functions. Audit history records every action, comment, and decision on its own. That is the exact substrate cross-functional procurement approval needs, and Atlassian customers already have it in production.

Where this leaves the procurement software category

None of this is an argument against procurement software as a category. The features that have emerged over the past five years- supplier risk screening, AI-assisted intake triage, contract metadata extraction, spend analytics, and vendor onboarding- are genuinely useful, and most JSM customers do not have them yet. The argument is about where those features should live.

If your company has already standardized on Atlassian as its internal service platform, the better answer is probably not a separate procurement tool that talks to Atlassian over an API. It is a procurement layer that runs inside Atlassian, uses its native building blocks, and inherits its adoption. If you are not on Atlassian, the math is different, and a standalone intake-to-procure tool may well be the right call. But for the growing group of mid-market and enterprise teams running JSM as a serious business platform, the honest question is worth sitting with: if your people already know how to file a request, why are you asking them to learn another system? The best procurement software is the kind that does not feel like procurement software at all. It feels like the way work already gets done.

To answer some questions

Can you actually run procurement in Jira Service Management?
Yes. With an app such as Raley Procurement for Jira & JSM, you can run the full purchasing process, from request to approval to a vendor purchase order, inside Jira or Jira Service Management, using the forms and workflows your team already knows.

Why does procurement software adoption stay so low? 
Because most of the people who file purchase requests are not procurement professionals and only buy something a few times a year. They have little reason to learn a separate system, so they default to email, Slack, or a corporate card. Putting procurement where they already work removes that reason to go around it.

What does JSM provide that a standalone procurement tool has to build?
The orchestration layer: request forms, multi-level approvals, routing, queues, SLAs, audit trails, permissions, SSO, mobile access, and cross-team collaboration. A standalone tool has to build all of that before it can add the purchasing layer on top.

How does procurement in JSM handle cross-functional reviews like security and legal? 
Each function keeps its own queue and workflow, issues link across projects, the requester sees one combined status, and approvers see only their own requests. The audit history captures every action automatically, which is what cross-functional purchase approval needs.

When does a standalone procurement tool still make more sense? 
When your organization is not standardized on Atlassian. If your people do not already live in Jira or JSM, the adoption advantage disappears, and a dedicated intake-to-procure platform may be the better fit.

Run procurement where your team already works ?
Yes, you do not need another platform to learn. Run purchasing through Jira or JSM with a customizable approval matrix, automatic purchase order PDFs for vendors, live budget reporting for finance, and approvals people can action from their inbox. You can get a free trial of Raley Procurement for Jira & JSM on Atlassian Marketplace today.

• Purchasing was the one process this team ran outside Jira, and it showed: surprise invoices, duplicate tools, approvals no one could find.
• Moving requests into the JSM portal gave every purchase one place to start and an audit trail that built itself.
• Approvals route by amount and department, so a 200 dollar cable and a 40,000 dollar contract no longer take the same path.

Maria runs finance and ops at a 120-person software company. Every Monday she opened a spreadsheet, three Slack threads, and her inbox to answer one question: what did we agree to buy last week?

Her team ran everything else in Jira and JSM. Purchasing was the one process that had wandered off, and it came back as surprise invoices, two people expensing the same tool, and approvals nobody could find. Here is how a team in that spot moved buying back to where the work already happens, with Raley Procurement for Jira and JSM.

The challenge: spend with no home

The company was growing, and so was its spend: new laptops, contractor invoices, a dozen SaaS renewals a month. The data was fine. Budgets, departments, and vendors were all known. The process around them was not. No single place to raise a request, no agreed path for who signs off, no current record of what had been committed. The spreadsheet was a source of truth, just never a current one.

The old way of approving a purchase

Before Raley Procurement, one purchase took a familiar detour:

• Ask around. Ping a manager on Slack about budget, then guess who else needs to approve.
• Email the sign-off. Approval lived in a reply-all thread finance was sometimes copied on.
• Update the sheet, eventually. A row got added when someone remembered, so the tracker always ran a few days behind.
• Reconcile at month end. Finance pieced it together from invoices after the money was gone.

Every step worked alone. Together they cost Maria an afternoon of detective work every Monday.

The solution: Raley Procurement for Jira and JSM

The team installed Raley Procurement and added "Raise a purchase request" to their existing JSM portal. Requests now start where every other request does, and move through an approval workflow the team set up to match how it actually buys. Nothing left Jira, and the audit trail built itself as a request moved from raised to approved to ordered.

What the team turned on

1. Requests in the JSM portal. A form in the portal people already use, with a known product and supplier catalog. No new login.
2. Routing by rule. Each request goes to the right approver by product, budget, department, and tier, so a 200 dollar cable and a 40,000 dollar contract take different paths.
3. Multi-currency. Vendors bill in different currencies, and the app handles it without a side calculation.
4. Order tracking from the ticket. Approved requests become orders: what is ordered, what is received, what is still outstanding.
5. POs and dashboards. A formatted PDF purchase order for the supplier, plus a live dashboard of committed spend finance can export to CSV.

"A request that used to drift for two or three days across Slack and email now clears the same day, in one system, with a record attached."

The results

Within the first week, the day-to-day changed:

• One place to request and approve. People stopped asking around. They opened the portal, submitted, and the right person was notified.
• Approvals that match the amount. Small buys cleared fast; large commitments got the extra sign-off, because routing ran by rule instead of by memory.
• A current record. The dashboard moved with the requests, so finance stopped rebuilding the month from invoices.

The shift in one view:

These show the shape of the change, not measured figures from a named customer. The point holds: a request that used to drift for days now clears the same day, with a record attached.

Why keeping it inside Jira and JSM mattered

The real win was not the features. It was that finance and ops got them without running a separate procurement platform. Maria's team already trusted Jira and JSM with its work, so adding purchase orders and approvals there meant no extra tool to administer, no data to sync, and no retraining. The app is Cloud Fortified and Partner Supported, so the tool running the spend meets the same bar as the work going through it.

• Five years building procurement on Jira and JSM produced eight lessons that cost us the most to learn.
• JSM beats the alternatives, custom workflows are the whole point, and purchase data belongs in JSM Assets, not custom fields.
• The biggest mistake: handling multiple line items with sub-tasks. Get the approval order right instead.

Five years ago, a client asked us a deceptively simple question: could they run their company's purchasing through Jira? We said yes, because we knew the platform could do almost anything. We did not yet know how much "almost" was carrying in that sentence.

Since then we have built procurement on Jira and Jira Service Management for a lot of companies, and we have made most of the mistakes so you do not have to. Here are the eight lessons that cost us the most to learn, written down so they cost you nothing. We build Raley Procurement & Quotation, so this is the view from inside the workshop.

1. JSM beats the alternatives for procurement

Of the Atlassian options, we prefer Jira Service Management for procurement. Any Jira-type platform can technically run purchasing, but JSM wins on two counts.

First, the portal is simpler. Jira's flexibility comes with interface complexity, and the JSM portal hides most of it behind a clean request form that non-technical buyers can actually use.

Second, familiarity. Plenty of companies already use JSM to talk to IT and HR, so the people raising purchase requests have used the portal before. Less training, faster adoption. Jira Work Management and the others tend to stay inside IT, which makes them a harder sell to a finance or operations team.

2. Customizable workflows are the whole point

Most purchasing systems ship with a fixed workflow and a few cosmetic options. You can add or skip an auxiliary step, but the core logic belongs to the vendor. The trouble is that every company approves money differently, and "differently" is exactly what fixed workflows cannot handle.

This is where Jira earns its place. Custom workflows, transitions, and post-functions are the backbone of the platform, and you can shape them to match how your company actually buys. One example we use often:

A purchase request is created, filled in, and sent for approval. Before any of that, management adds a preliminary verification step that catches obvious errors early, so fewer requests bounce back from approvers.

That single tweak means fewer rejected requests, faster approvals, and less time wasted overall.

3. Request types map cleanly to business processes

Finance needs precise data, and getting clean data out of busy people is its own discipline. The right information has to land in the right field, which is hard when a form has conditional logic or a vague free-text box doing too much work.

The JSM portal handles this well, because you can combine multiple request types with customizable, validated forms. A few things separate request forms can do:

• Onboard a new vendor with its own fields and approval path.
• Request a change to a purchase request that is currently locked.
• Add a discount or rebate to an already-approved request.
• Request a price change in the product registry, with a lookup and a justification.

Each of these is really its own process, so it makes sense to give each its own request type. Users still pick from one place: the JSM portal.

4. Purchase request forms are harder than they look

A good purchase request form is much harder to build than people expect. Stock Jira and JSM forms are fine for the simplest buying, because they are static. Even many third-party "smart" forms fall short, because they do not know the buyer's limits, budget, or approval logic.

There are two ways through this:

1. Build a custom form with integrations that look up users, budgets, vendors, products, and departments, plus custom approval routing. A good one lets you pick departments and vendors, expose your product registry, add multiple order lines (each with its own cost center), enforce policies like legal or security review for new products, and calculate taxes and totals to assign the right approvals.
2. Use a specialized app like Raley Procurement & Quotation that does all of the above out of the box.

One thing we learned the hard way: do not try to support multiple line items through sub-tasks. JSM does not support it, and even where it works, keeping child issues in sync with parent totals and approvals is a daily headache you will come to resent.

5. Track budgets, vendors, and products in JSM Assets

A purchase request cannot stand alone. It has to connect to departments, budgets, vendors, and products, and deciding where that data lives takes some thought.

Our first instinct, like everyone's, was Jira custom fields. It does not scale. Departments cannot link to users without custom work, vendors carry too much metadata for a field, and putting thousands of products into custom-field options is a genuinely bad day for whoever uses the form.

JSM Assets is the better home. It keeps purchase-related data organized, and because it has a REST API, syncing cached data with your master data is more manageable. Two cautions from experience:

• Store the minimum you need. Adding a field to Assets is easy; maintaining it forever is not.
• Let your ERP calculate totals and aggregates, not Jira. Duplicating data is bad. Duplicating behavior is worse.

Once a purchase is executed, JSM Assets also works nicely for tracking the goods and services you received. At that point it is doing exactly what the name says.

6. External PO numbers need their own process

Every purchase order needs a unique number, and how you generate it depends on the process you are replacing.

If a company has no formal numbering yet, the simplest move is to use the Jira ticket number as the PO number. It is clean and it tracks easily downstream.

Most companies moving to Jira already have a numbering system, often from an ERP like NetSuite. There, the external number has to be assigned to the Jira ticket, which a custom PO-number field set via a Jira Automation hook handles well. It also helps to let finance overwrite that number manually on the issue screen, and to print the PO number on any PDF sent to the vendor so everyone shares one reference.

7. Build in flexibility, because mistakes are certain

No matter how good your validation is, procurement mistakes will happen. Typos, miscalculations, a number that is an order of magnitude too big. The question is not whether, it is how painful the fix is.

The worst case is a mistake discovered after a request has cleared a long approval chain and gotten the C-suite's blessing. Most companies would much rather edit the request than cancel and restart, so a finance role that can intervene on a locked request saves real executive time.

Flexibility also covers the human stuff: an approver who is off sick, a ticket that slips through the cracks. Permissions to modify a locked PO, shortcuts to approve or reject, and reminder notifications all reduce the friction. The non-negotiable is accountability: any change to a locked PO should be auditable, so you can see who changed what, and the data is preserved automatically.

8. Get the approval types in the right order

Approvals are the heart of procurement, and the order matters more than people expect. Across our customers, the common approval types are:

• New vendor
• New product or service
• Department
• Budget or project
• Program (for spend over a set threshold)
• Gross-amount approvals

Some companies use all of them, some use one or two. When several apply, the order that usually works best is: new vendor, new product, department, budget, program, then gross-amount approvals in ascending order. Gross-amount approvals climb the hierarchy until they reach a level that can sign off the total.

Notifications should follow the same order as the approvals. For gross-amount approvals especially, send them up the chain in sequence: a CFO and VP approve before the request ever reaches the CEO's inbox.

If you are weighing the move, start with 5 reasons to run your procurement on Jira or JSM, or see how the same engine powers sales quoting in JSM.