A purchase order is not really the first decision in a procurement process. It is the last one, the point where a need, a policy check, and a vendor choice have all already been made, and money is finally about to be committed. D365 procurement is built around that sequence of checkpoints, not around the purchase order alone.
The module itself lives in Dynamics 365 Supply Chain Management, integrating tightly with Finance for the accounting side of every purchase. This guide will explore how D365 procurement moves a request through requisition, sourcing, and ordering, and what the native spend analytics tools already reveal once the money has actually gone out the door.
Every purchase order is the last of several checkpoints
D365 procurement structures the path from need to spend as a sequence, not a single form. A requisition captures the need and checks it against policy. A request for quotation, when one is used, checks the market. A purchase order finally commits the money. Each stage in D365 procurement can still say no.
- A requisition can be rejected or sent back for revision before any vendor is even contacted.
- An RFQ can come back with no acceptable bid, closing the sourcing question without a purchase order ever being created.
- A purchase order itself can still require approval, based on category, value, or vendor, before it becomes a live commitment.
D365 procurement treats every one of these as a genuine decision point, not a formality on the way to an inevitable purchase order.
This sequencing is easy to underestimate until it breaks down. An organization that lets purchase orders get entered directly, skipping the requisition and sourcing checkpoints because that path is faster, has effectively disabled its own procurement policies without changing a single setting. The checkpoints only govern spend if the process actually routes through them.
Purchase requisitions and procurement policies: the first gate
Purchase requisitions
A requisition is where a need first gets recorded, whether the requester picks a product from a catalogue or requests something that is not yet catalogued at all. Spending limits can constrain what a requisition is even allowed to ask for, and budget fund allocation can be attached at this stage if the organization tracks commitments against a budget before a purchase order exists.
Procurement policies
Procurement policies control who can requisition what. Category access restricts which procurement categories a given requester or department can even see, and requisition permissions determine who needs an approval workflow versus who can proceed directly. These policies are what keep a decentralized requisition process from turning into an ungoverned one.
A common gap shows up when procurement policies are configured once at rollout and never revisited as the organization grows. A category access rule written for a fifty-person company can quietly become the wrong level of control for the same company at five hundred people, either too loose to catch real risk or so restrictive that requesters route around it entirely by mislabeling what they actually need.
Every policy exception, every requisition that skipped review, every category override, leaves a trace in D365 procurement data. The Metrixs analytics suite is what actually makes that trace visible.
Vendor catalogs and RFQs: choosing who gets the business
Vendor catalogs
Vendor catalogs collect the product assortment a supplier can actually deliver, and vendors can publish and maintain their own catalog directly, which keeps pricing and availability current without the purchasing team re-entering it. An approved vendor list attached to a product narrows selection further, preventing an unintended vendor from being chosen even when a catalog technically lists the item. This is one of the quieter ways D365 procurement reduces maverick spend, before an RFQ or a purchase order is even in the picture.
RFQs
A request for quotation can originate three different ways: built manually in the Procurement and sourcing workspace, generated automatically from a planned purchase order tied to demand, or converted directly from an approved purchase requisition.
- Vendors respond by copying data from the RFQ into their reply, entering the unit price they are actually offering.
- Accepting a reply transfers the vendor and price information straight back onto the requisition or purchase order line, so nothing has to be re-keyed.
- Scoring criteria can make the evaluation objective rather than a matter of whoever replied first or cheapest on a single line item.
The three RFQ origins matter for a reason beyond convenience. An RFQ generated automatically from a planned order reflects actual demand, not a guess. One converted from an approved requisition already carries organizational sign-off before a single vendor is contacted. A manually built RFQ is the most flexible of the three, and also the one most dependent on the person creating it to have scoped the requirement correctly in the first place.
If vendor selection keeps coming down to the same handful of suppliers regardless of what the RFQ scoring says, a Metrixs consulting review can show whether that pattern is policy or habit.
Purchase orders: three ways they actually originate
A purchase order in D365 procurement rarely starts from a blank form. It arrives through one of three paths, and knowing which path a given order came from matters when something about it needs tracing back.
- Master planning identifies a demand and generates a planned purchase order, which becomes a live purchase order once released.
- A processed purchase requisition converts directly into a purchase order, carrying forward whatever vendor and pricing information the requisition or its RFQ already established.
- Direct entry remains available for purchases that never needed a requisition or a competitive sourcing step at all.
Every one of these paths ends up in the same purchase order table, which is exactly why spend analysis downstream has to be able to distinguish them rather than treat every order as if it arrived the same way.
D365 procurement does preserve the origin on the order record itself, so this distinction is not lost, only under-used. A purchasing manager reviewing spend by origin, planned versus requisitioned versus direct entry, can see immediately whether direct entry, the path with the fewest checkpoints, is growing as a share of total spend, which is usually worth investigating before it becomes the dominant pattern.
Where native spend analytics already covers real ground
D365 procurement does not leave spend entirely to manual export. The Purchase and spend analysis Power BI content shows year-to-date purchase spend by vendor group, individual vendor, procurement category, product, and vendor location, alongside year-over-year change by vendor group and category.
- Supply risk assessment reports focus specifically on planned orders, tracking OTIF, on-time-in-full, delivery performance and ranking vendors and products against historical order outcomes.
- A basic vendor evaluation tool, an embedded Power BI report, compares vendor performance for on-time delivery and price variance, useful at the point a purchase order is being entered.
That is three genuinely useful native tools, not a blank canvas. What none of them do together is sit in one place: spend analysis, supply risk, and vendor evaluation each live in their own report, scoped to their own view, and none of them natively hold more than a year or two of comparative trend.
A procurement leader trying to answer one question- is this vendor actually a growing risk across spend, delivery, and price variance at once- currently has to open three separate reports and mentally reconcile them. D365 procurement generates all three data sets correctly. It simply was never built to present them as one answer to one question.
| What you need | Native D365 F&O tools | A dedicated layer such as Metrixs |
|---|---|---|
| Spend, risk, and vendor performance together | Three separate reports and workspaces | One reporting layer across all three |
| Multi-year spend trend by category | Year-over-year change only, not full history | Configurable history in one saved view |
| Cross-entity spend analytics | Assembled by hand, entity by entity | Consolidated across entities automatically |
| Refresh | As current as the last report run | 15 to 30 minutes via Synapse Link |
How Metrixs extends D365 procurement spend analytics
Metrixs reads purchase requisitions, RFQ history, purchase orders, vendor catalogs, and procurement policy exceptions through Azure Synapse Link into the same dedicated Azure Data Lake used for the rest of D365 F&O, built across more than 6,000 backend tables.
- Spend, supply risk, and vendor performance shown together, held as configurable multi-year history instead of three separate reports reviewed one at a time.
- Procurement policy exceptions and approval overrides surfaced directly, rather than buried in requisition history.
- Cross-entity spend analytics consolidated automatically, including across a multi-entity or multi-ERP environment.
- Refresh every 15 to 30 minutes, inside the same 12-module, 100+ report, 1,000+ metric suite, most deployments live in under 6 weeks, client ROI 290% to 450%.
D365 procurement still runs every requisition, RFQ, and purchase order correctly on its own. Metrixs is where a procurement or finance team sees spend, risk, and vendor performance as one connected picture instead of three separate logins.
That connected picture changes what a weekly procurement review actually looks like. Instead of opening spend analysis, then supply risk, then vendor evaluation in sequence and holding the comparison in memory, a team running D365 procurement through Metrixs opens one view where a vendor’s spend trend, delivery risk, and price variance already sit side by side.
Spend by vendor, risk by product, performance by supplier, side by side instead of three separate reports. See what that looks like in the D365 F&O finance and accounting analytics use case.
Frequently asked questions
What is included in D365 procurement and sourcing?
D365 procurement covers the full path from purchase requisition through RFQ sourcing to purchase order and receipt, governed by procurement policies and supported by vendor catalogs. It sits in Dynamics 365 Supply Chain Management and integrates with Finance for invoicing and payment, which is why D365 procurement data ultimately flows into the same general ledger reporting as every other financial process.
What is a procurement policy in D365 F&O?
A procurement policy controls category access, requisition permissions, and spending limits, determining what a given requester or department can purchase and whether an approval workflow is required. Policies are what keep decentralized purchase requisitions from bypassing organizational spend controls.
How does an RFQ work in D365 procurement?
An RFQ can be built manually, generated from a planned purchase order, or converted from an approved requisition. Vendors reply with pricing, and accepting a reply transfers vendor and price information directly onto the requisition or purchase order, with optional scoring criteria to keep vendor selection objective.
What is a vendor catalog used for in D365 F&O?
A vendor catalog lists the products or services a supplier can deliver, and vendors can publish and maintain their own catalog directly. An approved vendor list attached to a product further restricts purchasing to intended suppliers, even when a broader catalog technically includes the item.
Where do purchase orders in D365 F&O actually come from?
A purchase order originates one of three ways: released from a planned order generated by master planning, converted from a processed purchase requisition, or entered directly for purchases that skip requisition and sourcing steps entirely. All three end up in the same purchase order structure.
What spend analytics does D365 F&O provide natively?
D365 F&O ships Purchase and spend analysis Power BI content showing spend by vendor, category, product, and location, alongside separate Supply risk assessment reports and a basic vendor evaluation tool. The three exist as separate reports rather than one consolidated spend analytics view.
The verdict
D365 procurement genuinely covers the full sequence: purchase requisitions gated by procurement policies, RFQs that bring competitive sourcing into the process, vendor catalogs that keep supplier data current, and purchase orders that trace back to exactly how they originated. Every checkpoint described above is a real, working control, not a theoretical one.
Where it stops is consolidation: spend analysis, supply risk, and vendor performance held in one place, across years and entities, rather than three separate reports. Metrixs closes that gap, reading the same requisitions, RFQs, and purchase orders, refreshing every 15 to 30 minutes, and shipping it as part of the same suite that already covers general ledger, budgeting, and accounts payable.
Ready to see your own spend, risk, and vendor performance as one connected view? Book a Metrixs reporting assessment, and we will map your procurement policies and purchase history against what the reporting layer already covers.
Related reading: 8 vendor performance metrics to track from D365 F&O purchasing data
