Every purchase your company makes starts with a quiet moment that nobody logs. An engineer realizes the team needs another seat of a tool. A manager decides it is finally time to replace the laptop that sounds like a hairdryer. Someone, somewhere, decides they need something.

What happens in the next five minutes decides everything. Where that need goes, how it gets captured, who sees it, how it gets routed: that is the difference between procurement that is fast and controlled and procurement that is slow and leaky. That front half of the lifecycle is intake-to-procure, and in most companies it is held together with email, good intentions, and luck.

Here is the argument, in one line. Intake-to-procure is a regular service request and orchestration problem, and that is precisely what Jira Service Management was built to solve. So the intake layer of procurement should live in JSM.

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 deliberately 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 appropriate approvers. Execution is about the transaction. A lot of procurement tooling goes wrong by trying to be Jack of all trades.

Why intake breaks in most companies

Left to grow on its own, intake spreads across every channel an employee can find: an email to a manager, a Slack DM to finance, a half-filled form, a hallway conversation, a ticket raised to the service team in the wrong project. The symptoms are familiar to anyone who has worked in operations:

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.

Garbage in. Free-text requests show up missing the business justification, cost-centers, GL accounts, categories. The first thing procurement does is bounce them back, and the clock resets.

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...

Maverick spend. When the official path hurts, people quietly route around it, and unvetted vendors and purchases slip through.

None of these is a financial problem. They are intake, triage, routing, and visibility problems. That is exactly the category of problem service management already solved well for IT and HR.

Why this is a JSM problem, not a finance-tool problem

The instinct is to buy a procurement suite to fix intake. But looking at what a good intake experience actually requires, and it maps almost one to one onto what JSM already does:

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.

The last but not the least. We're yet to see an ERP which offers this kind of functionality that regular business users would really be able to use.

There is an adoption argument sitting on top of the technical one, and it might be the most important point in this whole piece. People already submit requests in JSM. Put procurement intake where employees already go, and they actually use the front door instead of walking around it. A process people follow beats a better process they avoid, every time.

What good intake-to-procure looks like in JSM

A mature setup tends to share the same shape:

  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. 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.
  3. 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.
  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. A clean handoff of the approved request to the system that executes the purchase (ERP, AP, or a PO engine), with the PO number flowing back onto the ticket for traceability.

One principle runs through all six: own the orchestration in JSM, hand off the transaction to the system built for it. Intake belongs to JSM. The ledger does not.

Where the boundary sits, and where an app helps

Saying intake belongs in JSM is not saying that the whole procurement process belongs there. The financial transaction (three-way matching, invoicing, payment), the procure-to-pay (P2P) half of the lifecycle, Vendor Contracts and lifecycle management belongs in your ERP or AP stack. The value of putting intake in JSM is that the request reaches that boundary already structured, approved, and traceable, instead of arriving as a half-formed email at 4:55 on a Friday.

Stitching the intake layer together natively is real configuration work: request types, Assets-backed enrichment, cross-functional approval matrices, and a clean ERP handoff. You can absolutely build it yourself if you have the Jira capacity and the patience.

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. Build or buy comes down to how complex your intake is and how much Jira time you want to spend. Either way, the layer belongs in JSM.

Can Jira Service Management handle procurement intake?

Yes. Procurement intake needs a single request portal, structured and validated forms, triage and queues, SLAs, workflow and automation, cross-functional approvals, and visibility into status and aging. Those are JSM's core capabilities, the same ones that handle IT and HR requests. JSM Assets can also hold vendors, budgets, and cost centers as managed master data that requests reference at intake.

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.

Why does procurement intake break without a tool like this?

Because it fragments across email, Slack, half-filled forms, and tickets raised in the wrong place. That produces four recurring symptoms: no single front door, low-quality free-text requests, approvals hidden inside inboxes, and maverick spend when people route around a painful process. These are intake, triage, routing, and visibility failures, not accounting failures.

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

You can build it yourself with request types, Assets-backed enrichment, approval matrices, and an ERP handoff, if you have the Jira capacity. 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.

What stays in the ERP or AP system?

The financial execution: purchase-order issuance against the ledger, receiving, three-way matching, invoicing, and payment. JSM owns the request and its approval trail. The ERP owns the money. The PO number flows back onto the JSM ticket so the request stays traceable end to end.

The bottom line

Intake-to-procure is not an accounting function bolted onto the front of procurement. It is a request-management and orchestration function, and treating it like one is the unlock. JSM already gives you the single front door, the structured intake, the routing, the cross-functional approvals, and the visibility good intake demands, all inside a portal employees already use.

Put intake-to-procure in JSM. Keep the financial transaction in the systems built for it. You get the rare combination of a fast front end and a controlled one, instead of forever choosing between the two.