If you're searching for dispensary purchase order software, here's the landscape as of mid-2026, from the POS vendors' own documentation: Dutchie POS has real purchase orders — create them under Products → Purchase Orders, email them to vendors, and receive against them — but its reorder report is a standalone analytics page that doesn't generate POs. Treez has no outbound purchase order at all: inventory intake is invoice-based, entered or imported after the product arrives. Flowhub has the best par-level alerting of the three, but no purchase order object anywhere in its documented workflow — inventory arrives by Metrc manifest import.
All three are strong where cannabis POS has to be strong: Metrc receiving. None of them runs the loop that happens before the manifest exists — deciding what to order, sending it to the distributor, and reconciling what was confirmed against what arrived. This guide walks each system's actual purchasing surface, then the layer question.
Dutchie POS: purchase orders, disconnected from reordering
Dutchie (the largest cannabis POS by store count — the 2024 Cannabiz Media POS report put it at roughly a third of identified US dispensary licenses) has the most complete purchasing surface of the three:
- POs: Products → Purchase Orders; vendors must exist first; POs can be emailed to vendors from the system
- Receiving: Products → Inventory → Receive, select the PO from the dropdown, enter received quantities, then complete the order — so partial receiving with explicit close-out
- Metrc: pending licensed transfers are accepted in Metrc first, then received into Dutchie with the source set to the pending transfer; Metrc Tag Control locks tag fields, and Retail ID QR codes auto-fetch
- Vendors: managed under Products → Vendors, required for receiving, deactivatable but never deletable
The gap is between awareness and action. Dutchie's low-inventory threshold is a menu feature — it removes items from your online menu when stock runs low; it doesn't touch purchasing. And the Reorder Report (a Greenbits-legacy analytics page) estimates days of stock left and exports a CSV — it doesn't create the PO. The buying decision travels from a report, through someone's judgment, into a manually built PO, with nothing checking the two against each other.
Treez: receiving and distributor finance, no outbound PO
Treez's own docs are direct: "invoices are how retailers intake inventory into your Treez portal." The flow is built for what happens after the truck: import a full Metrc manifest in one click (or per package), map each line to a Treez product, enter costs, accept, print labels. Its distributor management is genuinely the strongest of the three — license numbers with expirations, document attachments, representative contacts, credit notes with running balances, and outstanding amounts owed per distributor.
What's absent from the documentation is everything before delivery: there's no documented way to create a purchase order and send it to a distributor, which also means no order-vs-received reconciliation — the invoice you key in is the record, so a short or substitution against what you actually asked for is invisible by construction. Treez's analytics dashboard does compute suggested reorders (sales velocity times a reorder window, minus stock on hand), but the suggestion is a number on a dashboard, not an order.
Flowhub: par intelligence, no PO object
Flowhub's par-level story is the best of the three: par levels per product, a Par Level Report of everything below par (schedulable to email you the night a par is crossed), and a Predictive Par Level report that uses daily sales velocity to suggest par levels and forecast when items will hit them. Receiving is Metrc-manifest-driven — accept in Metrc, receive the manifest in Flowhub, create inventory per package, with bulk import for previously seen packages.
But as of mid-2026 we could find no purchase order feature anywhere in Flowhub's help center, release notes, or product pages, and no vendor-management workflow. The par alert tells you what's low; what happens next lives in email, text, and the distributor's sales rep.
The pattern, side by side
| Buying loop step | Dutchie | Treez | Flowhub |
|---|---|---|---|
| Reorder signal | Reorder Report (analytics only) | Suggested reorder (analytics only) | Par + predictive par alerts (best) |
| Create + send PO | ✔ Create and email POs | ✖ Not documented | ✖ Not documented |
| Receive vs ordered | ✔ Receive against PO | Invoice intake only — no order to check against | Manifest import — no order to check against |
| Metrc receiving | ✔ Pending transfers, tag control | ✔ One-click manifest import (deepest) | ✔ Manifest import + discrepancy tab |
| Distributor records | Basic vendors | ✔ Licenses, credits, balances (best) | Not documented |
| Signal → order → reconciliation, connected | ✖ | ✖ | ✖ |
Three different strengths, one shared shape: the reorder signal never becomes the order, and the order (where one exists) never meets the signal. In regulated retail that gap costs more than elsewhere, because every discrepancy you catch at receiving instead of at confirmation is also a compliance reconciliation — a package count that doesn't match the manifest, a substitution that changes what needs Metrc tags, a credit that has to survive both your books and BioTrack in states that require it.
What the layer looks like on top
Keep the POS you have — all three do their Metrc receiving jobs well, and ripping out a dispensary POS midyear is nobody's idea of fun. The layer question is whether the loop before and after the manifest is connected: reorder math computed from actual sell-through and lead times instead of a dashboard someone remembers to check; POs created from those signals and sent to each distributor in their channel; distributor replies — confirmations, shorts, substitutions, price changes — captured as structured updates on a living purchase order; receiving reconciled against the confirmed order, not just the manifest; and cost and credit history per distributor that survives into accounting.
That's the loop LineNow runs for regulated retail, alongside strict Metrc receive workflows — the compliance-gated receiving model is documented in Metrc Receive: How One-Paste Manifest State Pull Should Actually Work and the Metrc adjust/reject/partial-receive guide. For the wider compliance stack, see Cannabis State Reporting: Metrc, BioTrack, and the Procurement Layer.
Sources checked
- Dutchie Support: Create a purchase order in Dutchie POS
- Dutchie Support: Receive inventory from a purchase order
- Dutchie Support: Metrc — receive inventory from a pending transfer
- Dutchie Support: Reorder Report
- Treez Support: All About Invoices
- Treez Support: Invoicing inventory imported from Metrc
- Treez Support: Distributor management
- Flowhub Help: Par Level and Predictive Par Level reporting
- Flowhub Help: Import inventory by manifest (Metrc)
- Cannabiz Media: 2024 Point of Sale Report