Buying that already knows what it should cost
A purchase order should not be the first time anyone checks the price. Purchasing holds every supplier’s catalogue, cost and lead time on the same item records as your stock, so the PO is built from what you already negotiated.
A price book that spans every item and every supplier
One grid across all supplier lines, so "who do we buy this from and for how much" is a question with an answer rather than a phone call.
- Item, supplier, brand, the supplier’s own SKU, cost per unit, minimum order quantity and lead time on one row
- Filter by supplier, brand and active state; search over item, your SKU or theirs
- A default source per item, so the PO editor knows who to suggest before anyone types
Load their price list instead of typing it
Upload the catalogue the supplier actually sent you. The rows are parsed and matched to your items, and you review the match before a single line is written.
- CSV, Excel and PDF price lists, all read server-side
- The extract step writes nothing — you review parsed rows against their matched items, then confirm
- Confirming upserts that supplier’s line per matched item and leaves your other suppliers untouched
Purchase orders with a lifecycle, not a status field
A PO is editable while it is a draft and read-only after that, and the server enforces it — so the edit form is simply not offered once the order has gone out.
- Draft to sent to partially received to received, plus cancelled, each with the actions that state actually allows
- Lines pre-fill from the supplier’s catalogue, including the packaging that supplier ships that item in
- Creating, editing and sending sit behind their own permission, so buying can be separated from the rest of inventory
Send it from your own mailbox
A purchase order is a message to a person. It can go from the platform, or from your own connected mailbox so the thread sits in your sent items and their reply comes back to you rather than into a void.
- Send from the platform, or from your connected mailbox
- Edit the recipient and the covering message per send
- Or mark it sent manually, for the supplier who still wants a phone call
Reordering that produces a PO, not a report
The low-stock list is grouped by supplier — because a purchase order is per supplier — and each group turns into a draft order at the suggested quantities.
- On-hand, reorder point, target maximum, suggested quantity and supplier for every tripped item
- Take selected rows or the whole group; it seeds a DRAFT for review and never auto-posts
- Items with no supplier land in their own bucket instead of quietly disappearing
Common questions
Can it really read a PDF price list?
Yes, and here is the catch worth knowing up front: PDF extraction runs through the AI seam, so it needs an AI provider configured for your account. Without one it fails closed with a message naming that reason rather than importing something half-read. CSV and Excel have no such dependency.
Is there an approval workflow?
Not a multi-step approval chain. What exists is separation of duties: creating, editing and sending a purchase order is its own permission, so the person who raises orders need not be the person who runs the rest of inventory. If you need a threshold-based chain, say so — it is a build, not a setting.
Do you do RFQs or tendering?
No. This is the module for buying from suppliers you have already chosen: their catalogue, their price, their lead time, your order. Sourcing events and competitive tendering are not shipped.
Does it three-way match?
Not automatically. Receiving records what actually arrived against the purchase order, and landed cost is applied to the receipt; the supplier invoice and its credit notes live in Finance. Matching the three is something a person does today, not a rule the system enforces.
Bring your worst supplier price list
The messy one nobody wants to key in. It is a better test of the module than any demo we could script.