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.

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.

What supplier management means in practice

Before comparing vendors, pin down what you actually need. Real supplier management covers five things: a master record for each supplier, product catalogs with prices and tax rules, onboarding and compliance documents, order history per supplier, and an API to keep it all in sync with your ERP or accounting system. In a demo, ask to see each one. A vendor list with contact fields is not supplier management.

The seven tools, and who each one fits

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. It fits global enterprises, especially SAP shops, and its implementation timelines match that scale.

Coupa approaches procurement through total spend management. Supplier information, risk scoring, and spend analytics sit in one platform, which makes it a fit for enterprises consolidating many purchasing channels into one view.

Jaggaer goes deepest on source-to-pay. Strong sourcing events, supplier analytics, and category management make it a fit for organizations with heavy direct-materials spend.

Ivalua is the configurable option. Supplier workflows bend to fit complex or regulated industries, at the cost of a longer setup than the mid-market tools below.

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 PO workflows set up in days, though supplier collaboration features are thinner than in the enterprise platforms.

Raley Procurement for Jira & JSM takes a different route: it is not a standalone platform at all. It runs inside Jira and Jira Service Management, where many teams already raise requests. It keeps supplier and product catalogs with bulk CSV import, generates POs from the ticket view, routes approvals through up to three stages, and handles multiple currencies and tax rules. It carries Atlassian's Cloud Fortified badge and averages about $3 per user per month. If your team is already in Jira or JSM, this tool is a great choice.

The already-there test

A short test before you buy anything. 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 tool to your spend and your stack. Enterprise spend with dedicated procurement staff points to Ariba, Coupa, Jaggaer, or Ivalua. Mid-market flexibility points to Kissflow. Fast SMB setup points to Precoro. An Atlassian-based team points to Raley Procurement.

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.

Do small teams need a full procurement platform? Often not. A team raising a few dozen POs a month needs supplier catalogs, approvals, and clean handoff to accounting. Lightweight tools like Precoro, or an app inside an existing system like Raley Procurement, cover that without a platform rollout.

Decide from your own workflow

The honest summary: the top 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. Then trial the shortest path first.

If that path runs through Atlassian, try Raley Procurement for Jira & JSM on the Atlassian Marketplace, or read 8 lessons from five years of procurement in Jira before you decide.

Related reading

• 5 reasons to run your procurement on Jira or JSM
• Procurement in Jira: 8 lessons from five years in the field
• 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.

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, plus any additional fields required by your purchasing officers.
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.

Why "cloud-based" matters

The older generation of procurement systems lived on company servers or inside heavyweight ERP 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 talk to your ERP or accounting system through a REST API rather than a custom middleware project.

The tradeoff is real, too: 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.

And if your company already runs on Jira or Jira Service Management, you may not need a separate platform at all. 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. It is an Atlassian Forge cloud app that turns a Jira or JSM ticket into a purchase request, routes single or multi-level approvals, generates the PO as a PDF in the same work item, tracks deliveries, and hands off to your ERP through a REST API. It carries Atlassian's Cloud Fortified badge, communication runs over SSL with token authentication, and data is deleted 60 days after uninstall. We have written elsewhere about the reasons teams run procurement on Jira and the lessons from five years of doing it in the field, so we will not repeat the case here.

Worth Asking.

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.

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.

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 toppic

• 5 reasons to run your procurement on Jira or JSM
• Procurement in Jira: lessons learned in 5 years

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.

• Raley Bookman adds a "Book a meeting room" button to the Jira Service Management portal, so people book where they already raise requests.
• Each reservation links to the room asset in the JSM Assets CMDB, so capacity, location, and equipment stay attached to the booking.
• A room can hold only one reservation per time slot, so double-bookings are blocked at the source rather than discovered at 1:59 p.m.
• Facilities stopped hand-managing calendars, and the company got a clean record of how its rooms actually get used.

Three teams. One conference room. One 2 p.m. slot. Someone is about to present a quarterly review to an empty chair and a very confused cleaner.

If that sounds familiar, you already understand the problem Raley Bookman was built to solve. Here is how one team moved room booking out of their inbox and into the Jira Service Management portal, where it belonged all along.

This is an illustrative scenario, not a named customer. The headaches, however, are entirely real.

What Raley Bookman does, in one paragraph

Raley Bookman adds a "Book a meeting room" button to the Jira Service Management portal. Employees see live availability, pick a slot, and the reservation links straight to the room asset in the JSM Assets CMDB. Because a room can hold only one reservation per time slot, the double-booking problem stops at the source instead of being discovered at 1:59 p.m.

The problem: booking a room should not need a committee

Jack runs Jira at a company that, like most, asked everyone back to the office part-time. Demand for meeting rooms went up. The way people booked those rooms did not keep pace.

All the room data already lived in the JSM Assets CMDB: capacity, location, whether the projector worked this week. None of it was doing any good, because the actual booking happened like this:

• The email ask. Someone emailed the facilities team to find out if a room was free.
• The manual check. An agent cross-referenced the CMDB against a calendar by hand, like a librarian who has lost the card catalog.
• The collision. Two teams booked the same room anyway, met in the doorway, and quietly resented each other for the rest of the quarter.

Jack's manager, Toby, asked for one thing: let people book a room through the portal themselves, without facilities playing switchboard.

The fix: a booking button inside the portal

Jack installed Raley Bookman and added a "Book a meeting room" button to the JSM portal. The booking flow went from an email thread to three clicks: open the portal, see what is free, claim a slot.

No new tool to learn. No second login. The thing employees already use for IT and HR requests now books rooms too.

"The booking flow went from an email thread to three clicks: open the portal, see what is free, claim a slot."

What the team set up

Four pieces did the work:

1. Portal booking. Employees click "Book a meeting room" and see a calendar of open slots straight away.
2. Asset-linked reservations. Each booking is tied to the specific room asset in the CMDB, so details like "seats 10" or "has a projector" stay attached to the reservation.
3. A real-time room view. The "Meeting room view" shows what is occupied right now, so people stop requesting rooms that are clearly taken.
4. Conflict handling. Once a room is reserved for a slot, Bookman will not hand the same slot to anyone else.

What changed

The booking process moved from inbox to portal, and a few things followed:

• Overlaps are blocked by design. Bookman will not accept a second reservation for a room that is already taken in that slot, so the doorway standoff stops happening.
• No more availability emails. People can see what is free and claim it themselves, instead of asking and waiting.
• Lighter load on facilities. The team stopped hand-managing calendars and got their day back for work that actually needs a human.
• A clean record. Because every booking is tied to a JSM asset, the company has a complete record of how its rooms get used, which is genuinely useful when someone asks whether the third-floor room is worth keeping.

No miracle, no buzzwords. Just the booking living where the work already lives.

• A manual purchase order can cost up to $506.52 to process (APQC), once delays, errors, and chasing are counted.
• You can run the full purchasing process, request to approval to vendor PDF, inside Jira or JSM with an app like Raley Procurement & Quotation.
• Your team keeps the interface they know, finance gets live budget reporting, and approvers can act straight from email.

A manual purchase order can cost up to $506.52 to process, according to APQC research, once you count the delays, errors, and chasing. That is a remarkable amount to spend on the privilege of buying something.

Good procurement does the opposite: the right things arrive on time, approvals move, and operations run under budget. The catch is the tooling. Here are five reasons to run procurement on software your team already uses, Jira or Jira Service Management, instead of bolting on another ERP.

The short version: you can run a full purchasing process, from request to approval to vendor PDF, inside Jira or JSM with an app like Raley Procurement & Quotation. Your team keeps the interface they know, finance gets live budget reporting, and approvers can act straight from their email.

1. Your team already knows the tool

The biggest cost of new software is the learning. Jira is trusted by a large global base of organizations, including names like NASA and Tesla, per Atlassian's customer list. Your team already uses it for IT and project work, so a purchase request is just another familiar form, not a new system to dread.

Requesters submit purchase orders through the Jira or JSM interface they use every day. The learning curve is short because there is barely a curve.

2. The workflow bends to your process

Most purchasing tools make you adapt to their workflow. Jira lets the workflow adapt to you. With Raley Procurement & Quotation, almost any purchasing process is possible: products, services, inventory, supplies, raw materials, each with the steps and rules your company actually follows.

Because purchase orders follow your Jira project workflow, you customize them the same way you customize everything else in Jira.

3. Approvals fit your real approval matrix

Approval rules are where generic tools fall down. Raley Procurement & Quotation lets you approve by budget, by department, and along your specific corporate approval matrix, including separate approvals for new products or vendors.

Approvers get an email when their decision is needed, and can approve or reject each request right from that email. That improves oversight and shortens the wait, because nobody has to log in to keep a purchase moving.

4. It connects to your other systems

Procurement does not live alone, so the app comes with an API to connect to your other tools. Your systems can update products and services in the registry dynamically, which lets you track the full life cycle of inventory, requests, and orders without re-keying data between systems.

5. Finance sees spend in real time

Leaders should not have to guess at the numbers. With live reports, finance and approval managers can see current budget status from inside Jira, across departments, budgets, and suppliers. Approved requests generate a PDF purchase order, attach it to the ticket, and can send a copy to the vendor automatically.

Who does what

The app fits the roles already in your procurement process:

• Employees submit purchase requests as Jira users or JSM customers; the procurement team validates and approves them.
• Vendors receive approved POs automatically, as a generated PDF emailed to the right supplier.
• Management oversees finance and purchasing, with budgets and inventory updating dynamically.
• Admins set up, deploy, and maintain the app, including company structure, users, and permissions.

For the longer view, read 8 lessons from five years building procurement in Jira.

• Shared resources like rooms, laptops, and vehicles are easy to own and hard to share, and spreadsheets break the moment two people want the same one.
• Raley Bookman adds self-service booking to the JSM portal on top of JSM Assets, so people reserve from the Help Center they already use.
• Each reservation becomes a Jira ticket linked to the asset, so a slot can only be held once and the audit trail builds itself.

Somewhere in your company right now, a laptop is "definitely booked," a meeting room is hosting two teams who both have it in writing, and a spreadsheet called bookings_FINAL_v3.xlsx is quietly lying to everyone.

Shared resources are easy to own and hard to share. Raley Bookman fixes the sharing part by putting reservations where your team already works: the Jira Service Management portal. It adds self-service booking on top of the assets you already track in JSM Assets. People open the portal, see what is free on a timeline, pick a slot, and get a confirmation. Each reservation becomes a Jira ticket linked to the asset, so a room, a loaner laptop, or a fleet vehicle can only be held by one person at a time.

The real cost of booking by spreadsheet

Most companies still book internal resources with some mix of spreadsheets, a shared calendar, and a hopeful email to whoever "looks after" the thing. That works until two people want the same resource at the same time, which is to say it works until lunchtime. Three things go wrong, every time:

• Downtime. Two bookings collide, someone loses, and a meeting starts ten minutes late while people find another room.
• Wasted spend. Nobody can see what is actually free, so teams buy a sixth loaner laptop while five sit in a drawer.
• Annoyed people. Booking a desk should not require knowing which colleague secretly controls the calendar.

How Bookman works

Bookman sits between your JSM Assets database and the service portal. Your assets already live in JSM Assets, with their capacity, location, and details. Bookman makes those assets bookable, so people reserve them from the same Help Center they already use to raise IT and HR requests. No new tool, no second login.

What you get

Four things do the work:

1. A real-time timeline. People see availability at a glance, pick a slot, and get an automatic confirmation, all inside the portal.
2. Asset-linked reservations. Every booking ties to a specific asset in JSM Assets, so details like "seats 10" or "has a projector" stay attached to the reservation.
3. Conflict prevention by design. Once an asset is held for a slot, Bookman will not hand the same slot to anyone else. Double-bookings stop being possible rather than being discovered.
4. Booking rules you set. Define booking windows (say, 8am to 5pm) and maximum durations so one person cannot reserve the demo room for a fortnight.

Every reservation also creates a Jira ticket, which gives you a searchable record of who booked what and when. That record is genuinely useful later, when someone asks whether the third-floor room is worth keeping.

Where teams use it

Bookman handles any asset you track in JSM Assets, not only meeting rooms:

• IT: loaner laptops, test devices, VR headsets, anything that gets checked out and (eventually) returned.
• Facilities: meeting rooms, hot desks, parking spaces.
• Operations: pool vehicles and shared equipment for off-site events.

It runs on your existing Jira, so going from five rooms to five thousand devices is a matter of adding assets, not adding infrastructure. You can also read how one team used Raley Bookman to end meeting-room double-bookings.

• Jira is powerful but unfriendly to non-technical users, so requests often arrive as messy emails instead.
• Raley Intake Forms builds branded, dynamic forms that create clean Jira tickets, embeddable on any site or Confluence page, with no license needed to submit.
• Conditional fields and field mapping mean what lands in Jira is already structured, so you skip the manual cleanup.
  

Managing incoming requests in Jira should not feel like a second job. A bug report here, a marketing ask there, an HR ticket that arrives as three separate emails and a screenshot of a screenshot. The standard Jira issue screen is either too much for the person filling it in, or too little for the data you actually need back.

Data collection should be the easy part. That is why we built Raley Intake Forms for Jira: branded, dynamic forms that turn messy requests into clean, structured tickets. You build the form, embed it anywhere (your website, a Confluence page, or a portal), and the data maps straight to your project's schema. Submitters do not need a Jira license, and fields adapt to their answers, so what lands in Jira is already clean.

The problem: Jira is powerful, not friendly

Jira is excellent at project management and intimidating at first contact. Non-technical users open the default issue screen and meet a wall of fields, jargon, and a layout that feels heavy. Many just give up and send an email instead, which is how you end up back where you started.

The native Jira Issue Collector helps, but it is short on styling and the dynamic logic you need to get good data the first time.

Dynamic fields that hide what doesn't apply

Why ask for a browser version when someone is reporting a billing problem? With conditional logic, Raley Intake Forms shows or hides fields based on earlier answers. Forms stay short and relevant, which is also the quickest way to get more of them finished.

Forms that match your brand

Your brand should not stop at the edge of your website. Intake Forms gives you control over colors, fonts, and layout, so moving from your site to the form feels like one continuous experience rather than a jarring handoff to "the Jira bit."

Drop a form into Confluence

Using the dedicated Confluence macro, you can turn any Confluence page into an intake portal. It is a tidy way to centralize internal requests without sending your team off to navigate away from the documentation they are already reading.

Build it without code

You do not need a developer to build a solid form. The what-you-see-is-what-you-get editor lets you drag and drop standard and custom Jira fields, set validations, and generate an embed code in minutes.

Clean data, mapped to your fields

Intake Forms supports Jira field types as first-class citizens. Checkboxes, date pickers, dependent dropdowns: whatever the user submits maps to your project schema, so you skip the manual data entry and cleanup that usually follows a form submission.

Better together: the Raley ecosystem

If you already run Raley Email Notifications, Intake Forms is the front half of the same loop. A form creates a ticket, and a custom-styled notification keeps the reporter updated as it moves, so the person who raised the request never has to email to ask "any news?"