What is Purchase order (PO)?

How a purchase order flows from order to landed cost

A PO moves through a predictable lifecycle, and each stage produces a number your books care about. You issue the PO (a commitment, not yet an expense), the supplier confirms it, goods ship, you receive them, and finally you match the supplier's invoice against what you ordered and what arrived. The gap between any two of those stages is where money quietly leaks: short shipments, price changes, and surprise freight all show up as mismatches.

Landed cost is what turns a PO line into a real unit cost. Take the PO unit price, then allocate inbound freight, import duty, customs brokerage, and any prep or labeling across the units in the shipment. That fully loaded number, not the supplier's sticker price, is what should hit inventory on your balance sheet and later flow into COGS when the unit sells. Sellers who skip the allocation overstate gross margin and underprice their products.

The three-way match deserves more attention than it usually gets. You compare three documents: the PO (what you agreed to buy), the receiving record (what physically arrived and passed inspection), and the supplier invoice (what you're being asked to pay). All three should agree on SKU, quantity, and price. When they don't, the discrepancy has to be resolved before the bill is approved, not after the wire goes out.

• •PO issued: a commitment to buy, recorded as a draft, not yet an expense
• •Goods received: inventory increases on the balance sheet at cost
• •Invoice matched: the supplier bill is checked against the PO (three-way match)
• •Freight and duty allocated: layered onto unit cost to get landed cost
• •Unit sells: landed cost moves from inventory into COGS

A worked example: from PO to per-unit cost

Say you issue a PO for two SKUs: 600 units of SKU A at $4.00 each and 400 units of SKU B at $9.00 each. The goods value is $2,400 plus $3,600, so $6,000 total. The PO is signed, you wire a 30% deposit, and nothing touches your profit and loss statement yet, because you've bought an asset you don't have.

The container arrives and three more bills show up: $1,400 in ocean freight, $520 in duty, and $180 in prep and labeling. That's $2,100 of inbound cost sitting on top of a $6,000 order. Now the question is how to spread it. Allocating by value gives SKU A 40% of the $2,100 ($840) and SKU B 60% ($1,260), which works out to $1.40 and $3.15 per unit. Landed cost becomes $5.40 for SKU A and $12.15 for SKU B.

Allocate by unit count instead and every unit picks up $2.10, giving landed costs of $6.10 and $11.10. Neither method is wrong, but they produce different margins, so pick one and document it. Value-based allocation suits mixed shipments where price roughly tracks size; unit-based suits cases where everything ships in similar cartons. Weight or volume based allocation is the most accurate when a shipment mixes a heavy, cheap SKU with a light, expensive one.

Notice how much moved. SKU A went from a $4.00 sticker price to $5.40 landed, a 35% increase. Price that product off the PO line alone and you've handed away a third of your margin before Amazon has taken a single fee.

Creating a purchase order in QuickBooks (and why it's only half the job)

QuickBooks Online and Desktop both support native purchase orders: you create a PO against a vendor, add line items with quantities and costs, and when the goods arrive you convert the PO into a bill so it lands in accounts payable. A QuickBooks purchase order template keeps the format consistent and makes the eventual three-way match faster. For low-volume sellers, creating purchase orders in QuickBooks directly is often enough.

The catch is that QuickBooks treats a PO as a procurement and payables document, not an inventory-costing engine. It won't automatically spread a $3,200 ocean-freight invoice across 1,500 mixed-SKU units, and it won't tell you that a unit you're about to reprice now costs 14% more than the last batch. That landed-cost allocation, the step that makes your COGS and gross margin trustworthy, is the gap many sellers fill with a spreadsheet or with purchase-order-aware tooling like BeanHawk that ties supplier costs straight through to per-unit COGS.

Which QuickBooks you run changes the details. Purchase orders in QuickBooks Desktop live inside the vendor workflow and carry over to item receipts, which suits sellers who prefer non cloud based accounting software they own outright, and the Desktop one-time purchase model appeals to anyone tired of subscription based accounting software. The trade-off is access: Desktop sits on one machine, so a warehouse team receiving goods can't touch it without remote access, and Intuit has been steadily narrowing what the Desktop line supports. QuickBooks Desktop Point of Sale is the cautionary example, since Intuit discontinued it and steered retailers toward Shopify POS, which left a lot of shops hunting for QuickBooks POS alternatives that still handled purchase orders and receiving. If you're choosing today, check what Intuit currently sells and supports before betting your purchasing process on it.

The same limitation applies in Xero, and it catches people out. Sellers who set up amazon xero or QuickBooks connections often assume the ledger will handle inventory costing once the sales data flows in. It won't: the ledger knows what you sold and what you were paid, but the cost side depends entirely on how carefully you capture and load your POs.

How purchase orders are recorded in your books

Issuing a PO creates no journal entry. That surprises new sellers, but it's correct: a commitment to buy isn't a transaction, and nothing has changed on your balance sheet. Some businesses track open POs in a memo or encumbrance report to see committed cash, but that sits outside the general ledger.

The first real entry happens at receipt. You debit Inventory and credit Accounts Payable for the goods value. Freight and duty invoices, when they arrive, get debited to Inventory as well (or to a landed cost clearing account you later push into inventory), never to a general shipping expense. Booking inbound freight as an operating expense is one of the most common ecommerce accounting errors, and it inflates reported profit in restocking months while starving your inventory valuation.

Deposits get their own treatment. A 30% prepayment to a supplier before shipment is a prepaid asset, not an expense and not yet inventory, so it sits in a supplier deposits account until goods arrive and the deposit is applied against the bill. If you're doing amazon bookkeeping with overseas suppliers on deposit terms, this account is worth reconciling every month, because forgotten deposits are one of the quieter ways money goes missing.

COGS comes last. The landed cost sits in Inventory until a unit sells, at which point you debit COGS and credit Inventory. That's the only moment your PO cost touches the income statement.

• •PO issued: no journal entry
• •Deposit paid: debit Supplier Deposits (asset), credit Cash
• •Goods received: debit Inventory, credit Accounts Payable at PO cost
• •Freight and duty billed: debit Inventory, credit Accounts Payable
• •Unit sold: debit COGS, credit Inventory at landed cost

Purchase order automation software and when it's worth it

Manual POs are fine until you're reordering dozens of SKUs across multiple suppliers on different lead times. At that point purchase order automation software, or a cloud-based purchase order system, starts paying for itself by pre-filling orders from reorder points, tracking which POs are outstanding, and flagging when received quantities don't match what you ordered. Automated purchase order systems reduce the most expensive PO error: paying an invoice for goods you never received.

From an accounting standpoint, the real win isn't the ordering convenience, it's the clean data trail. When every PO carries its SKUs, costs, and freight allocation, your inventory valuation stays accurate in real time and your cost of goods sold reflects what you actually paid, batch by batch. That's the difference between a P&L you can price decisions on and one you reconstruct at tax time.

Document capture is the cheap half of this. An invoice app that syncs with QuickBooks (the receipt-and-bill capture category, including tools like Dext, Hubdoc, and Bill) reads supplier invoices and freight bills, then pushes them into your ledger coded and attached, so the three-way match happens against a real document instead of a PDF in someone's inbox. A QuickBooks expense tracking app does the same job for the card spending around your orders: samples, prep supplies, courier charges. Neither one allocates landed cost, but both remove the retyping step where PO data usually goes wrong.

Be honest about the threshold. Under roughly ten SKUs and a handful of suppliers, a shared spreadsheet with a PO number, dates, quantities, costs, and a received column holds up fine and costs nothing. The signal that you've outgrown it is usually confusion rather than volume: nobody can say which POs are still open, or two people order the same SKU in one week.

Common purchase order mistakes

Reusing PO numbers is the fastest way to make a year of records unusable. Numbers must be unique and sequential, and a cancelled PO keeps its number. Auditors and suppliers both trace by number.

Receiving in the wrong unit is next. If you order 50 cases of 24 and receive 50 units, your per-unit cost is 24 times too high and every margin calculation downstream is wrong. Record receipts in sellable units, with the conversion applied at intake.

Partial shipments trip up almost everyone. When a supplier ships 800 of the 1,000 units you ordered, the PO stays partially open, you receive 800 into inventory, and you approve a bill for 800 only. Closing the PO in full because the invoice says so is how you end up paying for units that never arrived.

Last one: price changes. Suppliers quietly revise unit prices between orders, and if receiving copies the old PO cost forward, your inventory value drifts from reality. The invoice price at each receipt is what feeds your weighted average or FIFO layers.

What belongs in a purchase order agreement

A purchase order agreement is the PO's terms made explicit, useful when you're dealing with a new overseas supplier or a large outlay. A solid purchase order agreement template or format spells out the exact specs, quantities, unit price, currency, payment schedule, Incoterms (which decide who pays freight and where risk transfers), inspection rights, and what happens if goods arrive late or defective.

Those terms aren't just legal cover; they're accounting inputs. Incoterms in particular determine how much freight and duty you'll be allocating into landed cost, and the payment schedule tells you when cash actually leaves versus when the inventory liability is recorded. A vague PO produces vague books.

Connecting POs to the rest of your accounting stack

The PO is the front end of a chain that ends in your general ledger, and the chain breaks wherever the data has to be retyped. A reasonable stack looks like this: POs and receipts feed landed cost, landed cost feeds inventory valuation, valuation feeds a monthly COGS journal, and your channel settlements feed revenue and fees. Tools like A2X and Link My Books handle the settlement half well. The cost half is usually where sellers are still on spreadsheets.

Two structural points decide whether that chain holds. First, receiving has to run on a perpetual inventory system: each receipt updates quantity and cost the moment goods land, so your inventory value is right on any day rather than only after a count. A periodic approach leaves you guessing between counts, which defeats the purpose of capturing POs carefully in the first place. Second, don't expect your storefront to help. Cloud-based ecommerce platforms are built for the sell side and mostly treat purchasing as someone else's problem, so the PO, the receipt, and the freight allocation have to live in your inventory or accounting layer, not in Shopify or Seller Central.

If you're evaluating amazon accounting software, ask specifically what it does with purchase orders. Does it accept a PO with multiple SKUs? Can it allocate a freight invoice that arrives three weeks after receipt? Does it recalculate unit cost when the actual duty differs from your estimate? Plenty of tools that market themselves as ecommerce inventory management software track quantities beautifully and do nothing useful with cost.

Whatever you pick, the test is the same: pull one closed PO, follow it to the COGS posted on the units that sold from it, and see whether the numbers tie. If you can't trace that path in ten minutes, your PO process isn't feeding your books, it's sitting next to them.

Frequently asked questions

Is a purchase order the same as an invoice?

No. You issue a purchase order to the supplier to place the order; the supplier issues an invoice back to you to request payment. The PO comes first and states what you intend to buy; the invoice confirms what was actually billed. Matching the two (plus the receiving record) is the three-way match that catches overbilling and short shipments.

Does a purchase order count as an expense in my books?

Not by itself. Issuing a PO is a commitment, not a transaction, so nothing hits your P&L yet. The expense (or more precisely, the inventory asset) is recorded when goods are received and the bill is entered. The cost only becomes COGS later, when the unit actually sells.

How do I create a purchase order in QuickBooks?

In QuickBooks Online, turn on purchase orders in Account and Settings, then create one from the +New menu against a vendor, adding line items with quantities and costs. When goods arrive you convert the PO into a bill. A saved purchase order template keeps formatting consistent. Remember QuickBooks won't allocate freight and duty into unit cost, so you handle landed cost separately.

How does a PO connect to my COGS?

The PO unit price is the starting point for landed cost. Once you add freight, duty, and prep, that fully loaded cost sits in inventory until the unit sells, at which point it becomes COGS. An accurate, well-captured PO is what makes your cost of goods sold, and therefore your gross margin, trustworthy.

When is purchase order automation software worth it?

Roughly when manual tracking starts producing errors, typically once you're reordering many SKUs across several suppliers with different lead times. Automated systems pre-fill orders from reorder points, track outstanding POs, and flag receiving mismatches, which prevents the costly mistake of paying for goods that never arrived.

How should I handle a supplier deposit before goods ship?

Record it as a prepaid asset in a supplier deposits account, not as an expense and not as inventory. When the goods arrive, apply the deposit against the supplier bill and move the value into inventory. Reconcile that account monthly, because unapplied deposits from cancelled or delayed orders are easy to lose track of.

What if I receive fewer units than the PO says?

Receive only what arrived, leave the PO partially open, and approve a bill for the received quantity only. Then chase the supplier for the balance or a credit. Closing the PO in full because the invoice claims full quantity is how sellers end up paying for units that never showed up.

Does any accounting software handle POs and landed cost for Amazon sellers?

Some do, but check carefully. The settlement-side connectors (A2X, Link My Books) map your Amazon payouts into QuickBooks or Xero and don't touch purchase orders. BeanHawk handles POs, landed cost allocation, and per-unit COGS alongside the ledger sync. Whatever you're comparing, ask whether it can allocate a freight invoice that arrives after receipt, since that single feature separates real costing from a glorified order log.

Related terms

Go deeper

• COGS for Amazon Sellers: Getting Cost of Goods Sold Right
• Amazon Wholesale: How the Model Works and How to Win on Margin