The purchase order approval process is one of the most manual workflows in manufacturing operations. A purchase requisition gets submitted by email or on paper. A purchasing coordinator manually routes it to the right approver. The approver responds by email. The coordinator creates the PO in the ERP. The PO gets emailed to the supplier.

Every step in that sequence is manual. Every step can be automated. This tutorial builds the full PO approval workflow in n8n, from the initial requisition form to the PO created directly in the ERP via API.

What You Are Building

An n8n workflow that:

  1. Accepts a purchase requisition via a structured form
  2. Routes the request to the correct approver based on amount
  3. Sends the approver a one-click approve or reject notification
  4. On approval, creates the PO in the ERP via API
  5. Sends the PO confirmation to the requester and purchasing team
  6. On rejection, notifies the requester with the reason
  7. Escalates if no response is received within 24 hours

Prerequisites

n8n instance running version 1.0 or later.

ERP with a REST API. This tutorial uses the ERP API for PO creation in Step 6. ERPs with documented REST APIs for PO creation: NetSuite (REST Record API), SAP Business One (Service Layer), Epicor Kinetic (REST API), and JobBOSS2. If your ERP does not have a REST API, the PO creation step can be replaced with an email to the purchasing team containing the approved requisition details formatted as a PO.

ERP API credentials configured in n8n. Add an HTTP Request node credential with your ERP's base URL and authentication (API key or OAuth2 depending on your ERP). Test the connection by making a read request (GET a list of existing POs) before building the write step.

Email or Slack for approver notifications.

Defined approval matrix. Document before building: who approves what amounts, what the escalation path is, and what happens when a requisition is rejected. The Switch node routing reflects these rules directly.

Workflow Overview

n8n Form Trigger (requisition submission)

    → Set node (normalize form data)

    → Switch node (route by amount)

        → Branch A: Under $500, auto-approve, skip to PO creation

        → Branch B: $500 to $2,000, route to department manager

        → Branch C: Over $2,000, route to COO or VP Operations

    → Gmail or Slack (send approval request with approve/reject links)

    → Wait node (hold up to 24 hours)

    → IF node (approved or rejected)

        → Approved: HTTP Request to ERP (create PO), notify requester

        → Rejected: Notify requester with reason

    → Schedule sub-workflow: escalate if no response in 24 hours

Step-by-Step Build

Step 1: Build the Requisition Form

Add an n8n Form Trigger node as the starting point. Configure the form with these fields:

  • Requester Name (text)
  • Requester Email (email)
  • Item Description (text)
  • Vendor Name (text)
  • Estimated Amount (number)
  • Quantity (number)
  • Preferred Delivery Date (date)
  • Urgency (dropdown: Standard, Expedited)
  • Notes (text, optional)

Click the form URL to preview it and confirm all fields render correctly. This is the form your team will use to submit purchase requests.

Step 2: Add a Set Node to Normalize the Data

Add a Set node to extract and rename the form fields into clean variable names. This makes the downstream expressions easier to read and maintain.

Key fields to set:

  • requesterName, requesterEmail
  • itemDescription, vendorName
  • amount: parsed as a number
  • quantity, deliveryDate, urgency
  • submittedAt: set to {{ $now.toISO() }}

Step 3: Add the Switch Node for Approval Routing

Add a Switch node and configure three output branches based on the amount field:

  • Branch A (Auto-approve): amount less than 500
  • Branch B (Manager approval): amount greater than or equal to 500 AND less than or equal to 2000
  • Branch C (Director approval): amount greater than 2000

For urgency-based overrides (Expedited requests under $500 that still require a check), add a fourth branch or add an AND condition to Branch A: auto-approve only if urgency is Standard. Expedited requests route to the manager regardless of amount.

Step 4: Build the Approval Notification

For Branches B and C, add a Gmail node to send the approval request. The email should include:

  • The full requisition details (item, vendor, amount, delivery date)
  • An Approve link (triggers the approval callback webhook)
  • A Reject link (triggers a short rejection form or directly triggers the rejection callback)

Keep the email format clean. Approvers who receive too much context in the approval email start ignoring them. The essentials are the item, vendor, amount, requester, and the two action buttons.

For Slack-based approvals, use a Slack node with Block Kit formatting to create an inline approve/reject button. The button actions trigger separate webhook URLs in n8n.

Step 5: Add the Wait Node

Add a Wait node after the Gmail send. Configure it to resume on webhook call with a 24-hour limit.

The Wait node pauses the workflow here. Nothing progresses until the approver clicks a link or the 24 hours expire.

For the dual callback approach (separate workflows for approved and rejected): the email links point to two different webhook-triggered workflows. The main workflow ends after sending the approval email and logging the pending status. The callback workflows handle the resolution.

Step 6: Create the PO in the ERP via API

In the approved workflow (triggered when the approver clicks Approve), add an HTTP Request node to create the PO in the ERP.

The API call structure varies by ERP. For NetSuite as an example:

  • Method: POST
  • URL: https://[account-id].suitetalk.api.netsuite.com/services/rest/record/v1/purchaseOrder
  • Authentication: OAuth 1.0 (NetSuite uses token-based auth)
  • Body: JSON with vendor reference, line items, expected delivery date, and memo field

For SAP Business One, the Service Layer endpoint for PO creation is: POST /b1s/v1/PurchaseOrders

Map the requisition data fields to the ERP's required fields. Test this step in isolation using a test purchase order before connecting it to the live approval flow.

If the ERP API call fails, add an error handler to notify the purchasing team so they can create the PO manually. Do not let failures silently drop.

Step 7: Send Confirmations

After the PO is created successfully:

  • Add a Gmail node to notify the requester: "Your purchase request for [Item] has been approved. PO [PO Number] has been created."
  • Add a Gmail node to notify the purchasing coordinator with the full PO details for their records.

On the rejection path, send the requester a clear notification with the rejection reason and instructions to revise and resubmit if applicable.

What to Watch Out For

ERP API authentication setup. ERP APIs typically require OAuth, token-based auth, or session-based authentication that expires. Test your credentials carefully and note the token refresh requirements. NetSuite tokens do not expire but require a specific HMAC-SHA256 signing process. SAP B1 sessions expire and need a login call before each API interaction.

Vendor record must exist in the ERP before PO creation. If the vendor is new, the PO creation call will fail because the vendor record does not yet exist. Add a vendor lookup step before the HTTP Request node: GET the vendor by name. If not found, route to the vendor onboarding sub-workflow or flag to purchasing before creating the PO.

Amount field type. n8n Form Trigger returns form fields as strings. Ensure the amount is parsed as a number (Number($json.amount)) before the Switch node comparison. String comparison of "1500" greater than 500 may behave unexpectedly depending on how the Switch node handles type coercion.

What This Unlocks Next

The PO approval workflow is the upstream half of the procurement automation. Once a PO is created via API, the next automation layer monitors supplier acknowledgment: did the supplier confirm receipt of the PO within 48 hours? If not, n8n sends an automated follow-up.

That workflow, combined with inbound shipment tracking, builds the full purchase-to-pay visibility loop covered in the Week 2 supply chain post.

The Flow Kaizen guide includes the ERP API prerequisite checklist, covering what credentials you need, how to test API access before scoping the build, and which ERP modules need to be enabled for PO creation via API.