I recently built a Procurement PO Checker MVP using n8n, ERPNext API, Excel, and Slack.
The problem
When a supplier confirmation contains dozens of line items, manually comparing every SKU, quantity, price, and delivery date against the original Purchase Order becomes time-consuming.
It gets even more complicated when suppliers confirm quantities in packs or boxes instead of individual units.
What the workflow does
A supplier confirmation (Excel) is uploaded to Slack.
n8n validates the file and retrieves the corresponding Purchase Order through the ERPNext API.
Each line is compared against the ERP data:
Supplier SKU and PO line matching
Confirmed quantities, including packaging conversions
Unit prices
Requested vs. confirmed delivery dates
Missing or invalid information
The workflow posts the verification result directly in the original Slack thread.
Example: 100 units ordered, but only 80 confirmed → a 20-unit shortage is detected and reported.
If all values match, the workflow returns ALL CHECKS PASSED.
I also implemented error handling for invalid Excel files, missing Purchase Orders, and ERPNext API failures.
The comparison logic is rule-based, using n8n Code nodes rather than an AI agent.
This is an MVP built to demonstrate automated procurement verification, not a production deployment.
I’ve attached a short demo and a screenshot of the workflow.
I’d be interested to hear how others approach supplier confirmation validation and unit conversions in n8n.
A rule-based comparison is a sensible choice here, because the result needs to be deterministic and auditable. For the pack versus unit conversions, one approach is to keep a small mapping of SKU to units per pack in the ERP or a lookup sheet and convert before comparing, rather than inferring it from the confirmation text, and to flag any SKU with no mapping instead of guessing. It can also help to compare prices and quantities within a small tolerance, for example rounding to the currency’s decimal places, so minor floating-point differences do not trigger false mismatches, and to log each check result with the PO number so exceptions can be reviewed later.
How do you handle the same SKU appearing on two PO lines with different delivery dates? For example, 50 units due this week and 50 next month, but the supplier confirms one line of 100. The total quantity matches, yet the delivery commitment may not. Does your matching use the ERP PO line ID when available, and flag ambiguous matches rather than combining them by SKU?
Good point! In the current MVP, matching is based on Supplier SKU rather than PO Line ID.
If the same SKU appears on multiple PO lines, the workflow flags it as an ambiguous match instead of combining the quantities or assuming which delivery date applies.
So in your example, the 100-unit confirmation wouldn’t automatically pass the check.
Using PO Line ID for more precise matching would be a good improvement for a production version. Thanks for pointing this out!
Nice work, Yana! I like that you’ve kept the comparison logic rule-based instead of adding an AI agent where deterministic validation is more appropriate.
One additional case worth testing is how the workflow handles duplicate supplier uploads or a retry after an ERPNext API timeout, so the same confirmation doesn’t create duplicate processing or inconsistent results.
I’ve been working on n8n workflows with FastAPI and PostgreSQL, focusing on idempotency, validation, and failure recovery. This is a very relevant use case!
That makes sense, thanks for clarifying! Since the current workflow is read-only, rechecking the same file is perfectly reasonable. Idempotency becomes more critical once the workflow starts creating records or triggering external actions. I like the clear separation between deterministic PO validation and actions that may need duplicate protection. Nice MVP!
