Purchase Order Automation Requests to approved POs without the email chase
A purchase request becomes an approved purchase order the supplier has received — with the approvals recorded, not buried in email.
- Run for you$247/month
- Installed for you · one-time$249
- Custom build · this process$4,000–7,000 one-time
- Starts whenForm / Slack request
Covers one entity, one ERP and up to 500 requests a month. Multi-entity approval matrices, supplier portals or punch-out catalogues are a custom build. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
Purchase Order Automation is an automation Agentmelt installs in Slack. The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $247/month, with setup and maintenance included. A custom build of this process is $4,000–7,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-18.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is purchase order?
Purchase order automation takes a purchase request from a form, a Slack message or an email to procurement and carries it to a received PO without the email chase: an AI agent maps the free-text item to a category, suggests the contracted supplier and fills the budget line from the cost centre; the workflow checks remaining budget and policy (three quotes above a threshold, a contracted supplier for the category), routes approvals by amount and category with reminders and escalation, creates the PO in NetSuite, Dynamics, SAP Business One or Xero with the approvals attached, emails it to the supplier and tracks acknowledgement and receipt. Every step is logged, so committed spend by cost centre is live and the audit trail is the workflow’s own record.
- Purchase requests arrive as emails, get approved in a thread, and become POs by re-keying.
- Nobody knows what has been committed against a budget until the invoice arrives.
- Approvals stall because the approver is on holiday and there is no escalation.
- The same laptop gets bought from four suppliers at four prices.
- Auditors ask who approved a PO and the answer is a search through Outlook.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
Purchase requests arrive by email, get approved in a thread nobody can find later, and become POs by re-keying. The workflow takes the request from a form or Slack, has an AI agent complete and normalise it (the right category, the preferred supplier, the budget line), checks budget and policy, routes approvals by amount and category with reminders, creates the PO in the ERP, sends it to the supplier and tracks receipt — with a full audit trail.
- 13:05 Someone submits a request in a form or Slack: what, why, how much, when.
- 13:06 The item is categorised, the preferred supplier suggested, the budget line checked, the policy applied.
- 13:07 The approval chain runs in Slack — manager, budget owner, procurement — each with the request and the remaining budget.
- On approval The PO is created in the ERP and emailed to the supplier; receipt is confirmed from a Slack prompt.
Maverick spend, lost approvals, POs created after the invoice arrives, and no visibility into committed spend until month-end.
Every purchase starts as a request with a budget check and ends as a PO the supplier received, with approvals recorded. Committed spend is visible in real time, preferred suppliers are used because the workflow suggests them, and invoices match POs because the PO existed first.
Trigger, then 8 steps.
Seven of the eight steps run without anyone. Step 04 waits for a person.
Form / Slack request
Receive the request
What, why, quantity, estimated cost, needed-by date, requester and cost centre — from a form or a Slack message.
Normalise and complete
Maps the free-text item to a category, suggests the preferred supplier from the catalogue, fills the budget line from the cost centre, and asks the requester for anything missing.
Check budget and policy
Remaining budget for the line from the finance system; policy rules (three quotes above a threshold, contracted supplier required for a category, blocked categories).
Route approvals
Approval chain by amount and category: manager, budget owner, procurement, finance — each in Slack with the request summary; reminders and escalation after the SLA.
Create the PO
Approved request becomes a PO in the ERP (NetSuite, Dynamics, SAP B1, Xero) with the approvals attached.
Send to the supplier
PO emailed from procurement with terms and delivery details; supplier acknowledgement tracked.
Track receipt
Expected delivery dates monitored; the requester confirms receipt (or partial receipt) from a Slack prompt, which closes the PO for invoice matching.
Report committed spend
Live view of requested, approved, ordered and received spend by cost centre and category; approval cycle time by step.
Every purchase starts as a request with a budget check and ends as a PO the supplier received, with approvals recorded
Every purchase starts as a request with a budget check and ends as a PO the supplier received, with approvals recorded.
One decision, at step 04. Seven steps ran without you.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
A typical first month — a 180-person company with about 140 purchase requests a month, on NetSuite and Slack.
Not a client report
Purchases start as an email to a manager, or simply happen on a card. The PO is created after the invoice arrives, if at all; nobody can say who approved a $9,000 software renewal; and committed spend is unknown until month-end, when accounts payable reconciles the surprises.
The first month- Day 1The request form and the Slack command are live. The agent fills the boring fields — category, cost centre, the preferred supplier from the approved catalogue — and the request lands with finance for a policy check before anything routes.
- Week 1The approval matrix is loaded from the sheet finance owns: who approves what, above which amount, in which category. Approvals arrive as buttons in Slack, with a reminder after two days and escalation after four.
- Week 2Budget checks use live NetSuite data. Over-budget requests are flagged with the number, not blocked silently; two go through with a CFO approval on the record.
- Week 3The first POs are created in NetSuite and sent to suppliers with every approval attached. A request for a supplier not in the catalogue goes to onboarding first.
- Week 4Receipt is tracked against the PO. Committed spend is on the weekly report, and the invoice workflow now matches to a PO that existed first.
| Metric | Before | After a month |
|---|---|---|
| Purchases with a PO before the invoice | a minority | the default — the request path is faster than an email |
| Approvals without a record | common | none: actor and timestamp on every step |
| Time to an approved PO | days of email | hours, with reminders |
| Committed spend visible | at month-end | in real time |
The blueprint's mechanism is the figure: once the request-to-PO path is faster than sending an email, people use it, and the PO exists when the invoice arrives. Measure the share of invoices that match a PO in month two against month zero.
This is a worked example, not a client's results: the company is a composite of a stated size, and the figures are the ranges this blueprint's own metrics make typical at that size. A real engagement replaces it, with permission, once an install has run a month.
Data it touches
- Purchase request form / Slack
- Supplier catalogue and contracts
- Budget system (ERP or FP&A tool)
- ERP purchasing module
- Approval policy matrix (finance-owned sheet)
Guardrails
- No PO is created without the approvals the policy matrix requires; the workflow enforces, it does not decide.
- Supplier suggestions come from the approved catalogue; new suppliers go through onboarding first.
- Budget checks use live data; over-budget requests are flagged, not blocked silently.
- Every step is logged with actor and timestamp for audit.
PO before invoice, every time
The reason invoice processing breaks down is that the PO did not exist when the invoice arrived, so there is nothing to match. Making the request-to-PO path faster than sending an email is what gets people to use it: a Slack command, an agent that fills in the boring fields, and approvals that arrive as buttons. Once the PO exists first, the invoice workflow matches automatically and month-end stops being a reconciliation of surprises.
Approvals as policy, not habit
The approval matrix — who approves what, above which amount, in which category — lives in a sheet finance owns. The workflow applies it exactly, every time, with reminders and escalation. That consistency is what auditors want and what removes the 'who approved this?' conversation.
What it connects to.
| Tool | Role in this workflow |
|---|---|
| n8n | Intake, checks, approval routing, PO creation, tracking |
| Claude | Request normalisation and completion |
| NetSuite / Dynamics / Xero | PO and budget system |
| Slack | Requests, approvals, receipt confirmation |
Want this running without building it?
$247/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$4,000–7,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded walkthrough.
Covers one entity, one ERP and up to 500 requests a month. Multi-entity approval matrices, supplier portals or punch-out catalogues are a custom build.
Also sold one-time, installed in your own accounts, as part of the accounts payable teams package — do it yourself $49 · installed for you $249 · done for you $490.
When this becomes a custom build.
The subscription covers the standard version — $247/month, setup and maintenance included. Three things move it to a custom build ($4,000–7,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
Approval matrices by entity, department and amount, rather than one chain per category.
Supplier portals or punch-out catalogues as the ordering channel.
More than one ERP or entity, or above 500 requests a month.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
Frequently asked questions.
Can requesters use it without training?
Yes — the form or Slack command asks for what they know (what, why, roughly how much) and the agent completes the rest, asking one question at a time if something is missing.
Does it handle recurring purchases?
Blanket POs and scheduled releases are supported; the request references the blanket and skips the approval chain within its limits.
What about suppliers not in the catalogue?
The request is held while the supplier goes through your onboarding (details, banking verification, terms); the workflow creates that task and resumes when it completes.
What is the difference between purchase order automation and an AI procurement agent?
Purchase order automation is one process — request to approved PO to receipt — run by rules with an AI step for completing and categorising requests. “AI procurement agent” usually means the wider set: sourcing, supplier research, spend analysis, supplier risk, contract review. Those exist as separate workflows here; the PO workflow is the one most companies start with because it removes the daily chase.
How does the workflow decide who approves?
From an approval chain you define by amount and category — manager, budget owner, procurement, finance — each getting the request summary in Slack with approve and reject buttons. Reminders go out on a schedule and unanswered approvals escalate to a deputy. One chain per category fits the standard install; a matrix by entity, department and amount is a custom build.
What happens at receipt?
The requester is prompted in Slack on the expected delivery date to confirm full or partial receipt; the confirmation closes the PO for three-way matching, so the invoice-processing workflow can approve the supplier’s invoice against the PO and the receipt without a person.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- Oracle — NetSuite documentation docs.oracle.com/en/cloud/saas/netsuite/index.html
- Xero — Developer documentation developer.xero.com/documentation/
- n8n docs — Wait node (approval steps) docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait/