GrubMarket’s Purchase Order Agent: Check the Pack Size Before Creating a PO
For produce and food-distribution purchasing teams, the hardest part of automating purchase orders is not just reading a vendor document. It is making sure the quantity being captured means the same thing in the vendor’s paperwork, the distributor’s catalog, and the ERP order entry screen. That distinction matters because a bare quantity can look correct while still being wrong if the pack size is misunderstood.
According to GrubMarket’s November 10, 2026 vendor announcement, its purchase order agent extracts fields from vendor invoices or receipts, matches products against the distributor catalog, and lets a person review the results before the purchase order is created in the ERP. The announced integration is WholesaleWare; any other integrations should be understood only as possible through GrubMarket’s Integration Platform unless the vendor confirms otherwise.
Why pack size is the first check
A vendor invoice records what the supplier billed. A receiving record tracks what actually arrived. An ERP purchase order records the items and quantities being purchased. Creating that record from an invoice or receipt does not verify what the warehouse received.
This is where pack size needs human review. GS1 US describes packaging levels as the hierarchy used to identify how product is packed, such as each, case, or pallet. In procurement workflows, that hierarchy helps a buyer confirm whether the quantity is being counted in cases, eaches, or another order unit before the PO is created.
A quantity field can be plausible and still be wrong if the pack size is unclear.
A simple example that can mislead a bare quantity field
Suppose a vendor document shows 10 cases of 12 units. That is 120 individual units. If the same line is entered as 10 each, the ERP records only 10 units. The number 10 looks plausible either way; the order unit and pack size tell you which interpretation is right.
Before creating the PO, compare the pack size on the vendor document with the matched SKU and order unit in the catalog or ERP. Then check the quantity and confirm whether the price is per case, per unit, or by weight.
How the agent should be used in practice
Based on the vendor’s announcement, the agent’s role is to pull data from the vendor invoice or receipt, map it to catalog items, and present the result for human review before the PO is created in the ERP. That review step is important because the system is assisting purchasing work, not replacing the buyer’s responsibility to verify the line details.
For catch-weight products, the rule should be even stricter. Do not infer a fixed weight from a number of cases. If the document is ambiguous about weight, pack, or unit basis, route the line to manual review rather than forcing an assumption into the PO.
A practical pilot can start with a small mix of clear documents and ambiguous ones, so the team can see where the agent is reliable and where people still need to intervene. During the pilot, log the kinds of corrections made, such as unit mismatches, pack-size changes, SKU mapping errors, or unit-cost basis corrections. That information can help purchasing teams refine their review process without assuming any particular outcome in advance.
What this means for purchasing teams
For US food distributors, the review step is a chance to catch a pack-size error before it reaches the ERP. If the vendor document and the catalog disagree, check with the supplier or the person who maintains the item catalog before creating the order.
Indian distributors with similar workflows may find the same discipline useful even if their systems, item masters, or vendor documents differ. The core idea is universal: confirm the packaging level, confirm the SKU, confirm the order unit, and confirm the cost basis before the ERP creates the PO.
GrubMarket vendor announcement
GS1 US packaging level definitions
