Purchase orders and receipts in Field Service

What it does

Field Service has a light purchasing flow: raise a purchase order for parts, get it approved, receive the goods against it, and record the vendor's bill. POs either restock a warehouse or buy something specific for a customer work order, and receipts are what actually put stock on hand.

Key facts

Purchase orders live at Inventory > Purchase > Purchase Orders. A new PO starts at System Status = Draft.
The flow is Draft, then Submitted once the lines are on, then Approved by someone with the authority. Receipts come after approval.
Lines are Purchase Order Product records added on the Products tab. A PO can carry a delivery warehouse, a vendor and a Ship Via method (Ship Via values are maintained at Settings > Inventory > Ship Via).
Approval is where inventory first reacts: for inventory-tracked products being received to a warehouse, Field Service writes a journal that increases Quantity on Order by the line quantity.
A PO can be tied to a work order, either through the work order lookup on the PO's Details tab or by creating it from the work order's Related > Purchase Orders. That's the "buy this specifically for this job" pattern.
Receiving is a two-record job: a Purchase Order Receipt (name, PO, who received it) and then Purchase Order Receipt Product rows for what actually turned up.
Multiple receipts against one PO are supported. Partial deliveries are the expected case, not an exception — create a receipt per delivery.
Receipt products are what move Quantity on Hand in the destination warehouse and clear the on-order figure. An approved PO with no receipt moves nothing physical.
Bills are separate again: from the PO, Inventory > Purchase > Bills > New, with Bill Date and Vendor Invoice Number, then receipt products added through Related > Receipt Products.
Same permissions as the rest of inventory — Field Service - Administrator or the Inventory Purchase role.
Microsoft's own guidance is that this is basic purchasing. Complex pricing, multi-currency procurement or real vendor management belongs in Supply Chain Management or the client's ERP.

When to use / skip

Use Field Service purchasing when the buying is simple and service-driven: a technician needs a part, someone raises a PO, it arrives at a depot or gets drop-shipped for a job. For a service business without a real procurement function this is genuinely enough, and it keeps the parts story inside one system.

Skip it when the client has a finance or procurement team with an ERP. Field Service POs have no meaningful approval hierarchy, no budget checking, no vendor catalogue, no landed cost. Running them in parallel with the ERP's purchasing means two PO numbers for one purchase and an argument every month-end. In that world, keep Field Service to work order demand and let the ERP do the buying, either through the Supply Chain Management integration or a custom one that writes back with manual inventory journals.

The awkward middle is a client who wants "just a bit of approval". Ask what happens when someone exceeds their limit. If the answer is anything richer than a status change, you're building it.

Configuration decisions

Whether Field Service is the purchasing system at all, or a demand signal for something else. Decide before anyone sees a PO form.
What approval actually means here: who can move a PO to Approved, enforced by security role, by a Power Automate flow, or just by convention.
Whether POs are raised against warehouses, against work orders, or both — and what the client expects to happen to cost and billing in the work-order case.
Whether the bill step is used, or whether vendor invoices are matched entirely in finance. Half-used bills are worse than none.
How Ship Via and vendor lists are maintained, and by whom. These are small setup tables that quietly become dumping grounds.
Numbering: whether the client needs PO numbers that agree with an external system, which usually means an autonumber or an integration, not the out-of-box name.

Gotchas

Approval bumping Quantity on Order means an approved-and-forgotten PO permanently inflates the on-order figure. There's no automatic ageing or closure — someone has to police stale POs.
Approving a PO does not put stock on hand. Clients regularly test with an approved PO, see no change to availability, and report a bug.
Receipts are their own records, so a partially received PO looks the same as a fully received one at a glance. Reporting on outstanding quantities is a build, not a feature.
The PO/receipt/bill chain has no locking to speak of. Editing quantities after receipt is possible and will desynchronise the ledger.
Purchase orders linked to a work order don't automatically become billable lines on that work order. If the client expects pass-through billing, that's design work.
Products that aren't Inventory type generate no on-order or on-hand movement at all, so a PO for them is a record of intent and nothing more.

Consultant notes

Get the client to walk you through one real purchase end to end, including who signs what. Nine times out of ten it exposes an approval expectation the native flow doesn't meet.
Demo the partial-receipt case deliberately. It's the scenario clients care about and the one that shows why receipts are separate records.
Push back on rebuilding procurement inside Field Service. If the requirement list starts mentioning budgets or three-way matching, that's an ERP conversation.
Before go-live, agree who owns stale POs and set up a view for approved orders with no receipt after N days. Nobody thinks of it, everybody needs it.
If Supply Chain Management is in scope, check the procurement integration direction early — which system creates the PO decides most of the rest of the design.

Worth another look if the client adds a finance system, or if Field Service purchasing gains real approval controls in a future wave.