Purchase Request to Purchase Order
This guide walks through the end-to-end procurement flow on the SpendOne Platform, the AI-based platform for indirect corporate spend. It covers creating a purchase request, routing it through the rules engine, collecting multi-step approvals, generating a purchase order, sending it to the supplier, recording delivery, and closing the case.
For admins. Requesters create purchase requests under Purchases → New Request, picking a supplier and one or more line items; cost centers, categories and required attachments are enforced by the request form. Approval routing is governed by rules configured under Administration → Rules (see the Approval Rules Configuration guide) and by cost-center owners maintained under Administration → Cost Centers. Approvers see their queue under Tasks → Approvals. Once a request is fully approved, the buyer role takes over: the request transitions into a purchase order under Purchases → Orders, where the buyer marks the payment method ready, places the order with the supplier, and later confirms delivery. Disputes (wrong delivery, damaged goods) are raised from the same PO detail page.
For integrators. The flow is driven by four route groups: /purchase-requests (draft, validate, request approval, cancel), /approvals/* (task queue, approve, reject), /purchase-orders (order, receive, dispute, complete) and /suppliers (supplier directory). Approval routing is the side-effect of POST /purchase-requests/{code}/request-approval, which evaluates the configured approval rules and produces an approval plan with one or more steps; tasks become actionable step-by-step. Delivery is recorded as part of the purchase-order state machine (POST /purchase-orders/{code}/receive). There is no public delivery-note endpoint; the delivery note is materialized internally when the PO is marked received. See the OpenAPI reference for full payload schemas.
Sequence
Step 1: Create the request
POST /purchase-requests creates a draft. The payload carries the supplier code, cost center, line items (product code, quantity, net price, tax rate) and optional attachments uploaded separately via POST /purchase-requests/{code}/attachments. A draft can be edited freely with PUT /purchase-requests/{code} until approval is requested.
If the supplier is unknown to the directory, create it first via POST /suppliers. Suppliers can also be bulk-imported through the Data Imports pipeline (suppliers kind).
Step 2: Request approval
POST /purchase-requests/{code}/request-approval validates the draft and triggers rule evaluation. The Rules Engine resolves all active approval rules, ranks them by priority, and produces an ApprovalPlan containing one or more ApprovalTask entries grouped by task_order. Tasks at the lowest order become actionable; higher-order tasks remain pending until their predecessors complete. If no rule produces an approver, the plan is auto-approved.
Use POST /purchase-requests/validate/{code} beforehand to surface validation errors without committing.
Step 3: Multi-step approval
Approvers fetch their queue with GET /approvals/tasks and per-request tasks with GET /approvals/{code}/tasks. They act on a task with:
POST /approvals/{code}/tasks/{id}/approve: record approval, advance the planPOST /approvals/{code}/tasks/{id}/reject: terminate the plan with rejectionPOST /approvals/tasks/{id}/assign: delegate to another user
Only tasks at the current minimum pending step are actionable; the API returns 409 if a higher-step task is approved out of order. When the last task at the highest step approves, the request transitions to APPROVED and the platform automatically creates a corresponding purchase order.
Step 4: Order with the supplier
The buyer fetches the new PO with GET /purchase-orders/{code}. Two preconditions gate ordering: the payment method must be confirmed (POST /purchase-orders/{code}/payment-method-ready) and any accounting follow-ups resolved. The buyer then calls POST /purchase-orders/{code}/order, which records the order timestamp and the billing contact. There is no PO document generation and no send to the supplier: transmission is out of band, and the API persists state only.
Step 5: Receive and close
When goods arrive, POST /purchase-orders/{code}/receive records the delivery and opens an internal delivery-note record bound to the PO. If the delivery is incomplete or damaged, raise a dispute with POST /purchase-orders/{code}/dispute; resolve or cancel disputes via POST /purchase-orders/{code}/resolve-dispute and POST /purchase-orders/{code}/cancel-dispute. Once the buyer is satisfied, POST /purchase-orders/{code}/complete closes the case. Subsequent invoices ingested for this supplier will match against the closed PO during reconciliation (see the Invoice Ingestion and Extraction guide).
Cancellation
A request can be canceled by the requester or an approver before final approval with POST /purchase-requests/{code}/cancel. After PO creation, cancellation moves to the PO scope: POST /purchase-orders/{code}/cancel. Cancellation is a state transition on a dedicated POST action, not a DELETE. DELETE /purchase-requests/{code} moves a draft, or an already-canceled request, to PENDING_DELETION.