Receiving Inventory Right: Purchase Orders, Partial Deliveries, and Vendor Bills

Receiving inventory means confirming what actually showed up against what you ordered, updating your stock and item costs to match reality, and creating a bill for what you owe the vendor — not for what you originally typed into the purchase order. Get this step wrong and two things break at once: your on-hand counts stop matching the shelf, and your payables stop matching what you actually received. Get it right and a purchase order becomes a straight line from order to shelf to paid bill.

This matters more than it looks like on paper, because almost no delivery arrives exactly as ordered. Something is backordered, a case gets damaged in transit, the vendor substitutes a size, or the invoice price is 40 cents higher than the PO. The stores that stay accurate treat receiving as a real workflow with a few checks built in, not a rubber stamp on a packing slip.

What does "receiving" actually mean in retail inventory?

Receiving is the step where a purchase order becomes real inventory. Until you receive it, a PO is just a plan — quantities and costs you expect. Once you receive it, those quantities hit your stock ledger and become sellable, and the cost you paid becomes the cost basis for that item going forward. Receiving is also the trigger point for what you owe the vendor: you shouldn't create a payable for items that never arrived, and you shouldn't leave received stock un-billed indefinitely either.

How does the PO → receive → bill workflow actually work?

The clean version of this workflow has four stages, and skipping any one of them is usually where stores lose track of stock or money.

• Create the purchase order. Order from a vendor with expected quantities and unit costs per line item, before anything ships.
• Receive against the PO, line by line. When the delivery arrives, enter what actually came in — not what was ordered — for each line.
• Post received stock to inventory. Quantities and costs from the receipt update the item ledger at that location; the PO status reflects what's still outstanding.
• Turn the receipt into a vendor bill. A bill is created for what was received, feeding your accounts payable so you know what you owe and when it's due.

Doing it in this order — PO first, receipt second, bill third — is what keeps inventory and payables tied to the same source document. If a store skips straight to "just enter a bill when the invoice arrives," nobody double-checks the delivery against what was ordered, and discrepancies get paid instead of caught.

How do you handle a partial delivery or a backorder?

Partial deliveries are the normal case, not the exception, especially for hardware, apparel, and grocery-adjacent categories where vendors ship what they have. The fix is receiving at the line-item level instead of marking a whole PO as complete or incomplete.

• Receive only the quantity that physically arrived on each line — if you ordered 24 units and 15 showed up, receive 15.
• Leave the PO open for the remaining 9 units instead of closing it out, so you don't lose track of what's still owed to you.
• Don't create a new PO for the backordered quantity unless the vendor tells you it's on a separate shipment — a second PO for the same open line just creates duplicate ordering.
• Only bill for what was received. The vendor's invoice for a partial shipment should match the partial receipt, not the original order quantity.
• If a vendor cancels the backorder outright, close the remaining line instead of leaving it open indefinitely — an open PO line for stock that's never coming just clutters your outstanding-orders report.

This is also where a shared, per-location stock ledger earns its keep: a partial receipt updates on-hand immediately for the units that arrived, so the register and the online store (if you're running one) reflect what's actually sellable, not what was hoped for. See multi-location inventory management for how this plays out across more than one location.

What happens to item cost when the invoice doesn't match the PO?

Vendor costs shift between the order and the invoice more often than people expect — a price increase since your last order, a promotional cost that didn't carry through, a freight surcharge folded into the unit price. The cost that should end up on your item record is the cost you actually paid, confirmed at receiving, not the cost you originally keyed into the PO.

• Update the cost on the receiving line if the vendor's price differs from the PO, so your item cost reflects reality.
• Flag anything that's off by more than a small tolerance (many stores use a rule like "more than a few percent off PO cost gets a manager review") before the bill is approved.
• Keep an eye on cost drift over time — a string of small increases that never get questioned will quietly erode your margin. This ties directly into pricing and margin discipline.

Cost accuracy at receiving is also what makes your margin reports trustworthy later. If costs are stale or wrong, every margin number downstream — by item, by category, by vendor — is wrong too.

How do you match the vendor invoice before you pay it?

Before a vendor bill gets paid, it should be checked against two things: the purchase order (what you agreed to buy, at what price) and the receipt (what actually arrived). This is the retail version of a three-way match, and it's the single best control against overpaying a vendor.

• Quantity check — does the invoice bill for the same quantity that was received, not the quantity originally ordered?
• Price check — does the unit cost on the invoice match what was recorded at receiving, within a reasonable tolerance?
• Terms check — does the due date match the vendor's agreed payment terms, so nothing slips into a late fee?
• Duplicate check — has this invoice number already been billed? Duplicate vendor invoices are a common source of overpayment, especially with vendors who resend invoices after a slow payment.

Once a bill passes those checks, it moves into your normal accounts-payable cycle — track it as open, mark it paid when it's settled, and keep an eye on anything sitting overdue. If a bill doesn't match, the fix is to hold it, contact the vendor, and correct the receipt or the invoice before money moves — not to pay first and reconcile later.

What mistakes cause inventory and the books to drift apart?

• Entering bills without a matching receipt. This is how you end up paying for stock you never got, or paying twice.
• Closing a PO before all lines are received. The system then thinks nothing is outstanding, and the backorder gets forgotten until a customer asks why an item isn't in stock.
• Receiving by total instead of by line. Marking "the delivery arrived" without checking each item hides shortages and substitutions.
• Never updating cost at receiving. Item costs stay stuck at whatever was quoted months ago, and margin reports quietly go stale.
• Doing receiving and bookkeeping in two different systems. If receiving happens in one tool and bills get entered separately in accounting software, someone has to manually make sure the two agree — and on a busy week, that reconciliation is usually the first thing skipped.

That last one is the most common root cause. Every point above gets easier when receiving inventory and recording the vendor bill are the same motion in the same system, instead of a POS export followed by a separate data-entry pass into accounting software.

How does Retailer OS handle receiving, partial deliveries, and vendor bills?

Retailer OS runs purchase orders, receiving, and vendor bills against the same catalog and inventory ledger the point of sale sells from, so there's one record of what you ordered, what arrived, and what you owe.

• Create purchase orders to vendors with expected quantities and unit costs per line.
• Receive against the PO at the line-item level — enter what actually arrived, and a partial delivery leaves the remaining quantity open on the PO instead of closing it out.
• Cost is tracked at receiving, so your item cost reflects what you actually paid, not just the original order price.
• Received purchase orders create vendor bills in accounts payable — record them, pay them, void them if needed, and see what's overdue at a glance.
• Received purchase orders are posted to QuickBooks Online as bills, alongside a daily sales journal per channel, with a nightly check against the source so the two systems stay in agreement. Retailer OS doesn't keep a general ledger itself — it feeds QuickBooks Online, so your accounting stays in the accounting software you already use.

Because receiving updates the same per-location inventory ledger the register sells from, a partial delivery is reflected in on-hand the moment it's received — every sale, receipt, transfer, and adjustment leaves a movement row, so there's an audit trail behind the number, not just a total. If you're bringing in a catalog for the first time before you start receiving against it, see the fastest way to add products to inventory and, for shifting off spreadsheets entirely, the Excel-to-inventory migration checklist.