Sales Order vs Purchase Order: Same Deal, Opposite Sides
A purchase order is the buyer's request to a supplier; a sales order is the seller's confirmation and fulfillment record. Side-by-side table, flow and checks.
Bottom line
A purchase order is the buyer's commitment and a sales order is the seller's confirmation of the same deal. Match invoices to your PO, read the supplier's confirmation for changes, and make the PO number the reference both sides share.
Is it right for you?
- Put your PO number on every order you send, and ask suppliers to quote it on confirmations and invoices.
- Read each supplier confirmation against the PO before the goods arrive.
- Turn any agreed change in quantity, date or item into a formal PO change.
- File the PO, the supplier's confirmation and any change together for each order.
- For drop shipments, confirm customer delivery on the linked sales order before approving the vendor invoice.
The short answer
A purchase order (PO) and a sales order (SO) usually describe the same deal from opposite sides. The buyer creates the PO and sends it to the supplier. The supplier, once it has the PO, creates a sales order to confirm what it will deliver, at what price and when. If you are in accounts payable, the PO is your document. If you sell, the SO is yours.
Xero defines the pair this way. A purchase order is "a document sent by a buyer to a supplier, setting out the goods or services to be purchased," created before the supplier delivers anything. A sales order is "a document sent by the supplier to the buyer after receiving a purchase order" that "confirms the details of the order before the goods or services are delivered."
Sage calls the sales order "basically a mirror image of the purchase order," a document that formally acknowledges the seller has received the PO and accepts its details. That mirror image is the key to the whole comparison: same lines, same quantities, same prices, but each copy lives in a different company's books.
Side-by-side: purchase order and sales order
The table lines the two documents up on the questions that matter when you are reconciling an order. The rows draw on the Xero, Sage and Ramp descriptions cited in this guide.
| Dimension | Purchase order | Sales order |
|---|---|---|
| Who creates it | The buyer | The seller (supplier) |
| When | First, before anything is delivered | After the seller receives the PO or the customer's request |
| Main job | Request goods or services and control spending | Confirm the order and drive fulfillment |
| Who sees it | Sent to the supplier | Sent to the buyer as confirmation in some workflows; used mainly inside the seller's business in others |
| Typical contents | Items, quantities, agreed prices, delivery expectations, payment terms | Items, quantities, prices, discounts, delivery terms |
| What follows | Goods receipt, then the supplier's invoice is matched against it | Shipment or delivery, then the seller issues an invoice |
Notice the row on who sees it. Xero describes the sales order as something the supplier sends to the buyer. Ramp, in its comparison table, lists the sales order as an "internal document for fulfillment team" and says suppliers use SOs "mainly as internal documents." Both are describing real practice. Some sellers email an order confirmation generated from the SO; others keep the SO inside their own systems and send nothing until the invoice. If you are the buyer, do not assume a sales order will arrive. Ask the supplier how it confirms orders.
What both documents have in common
Because the two documents describe one transaction, most of their fields overlap. Ramp lists three similarities: both record the agreed transaction terms; both include product details, quantities, pricing and delivery expectations; and both serve as reference points throughout the order process and help resolve disputes.
Xero's list of what belongs on a purchase order is a good template for checking either one. It names a purchase order number and date, buyer and supplier details, item descriptions with quantities, unit prices and any discounts, tax details, and payment and delivery terms. When you hold a supplier's sales order next to your PO, those are the lines to compare one by one.
The fields that differ are the reference numbers. Your PO carries your number; the supplier's SO carries its own. Neither number replaces the other, which is why the cross-reference matters so much at invoice time.
How one deal moves through both documents
Here is the sequence that Xero and Sage describe, written from both sides so you can see where each document appears.
1. Buyer raises the PO. On the buyer's side, an approved request becomes a purchase order with a unique number, the supplier's details, item descriptions, quantities, prices, tax and payment and delivery terms. Xero lists those fields as what a PO needs so that both parties understand exactly what is being bought and on what terms.
2. Seller confirms with a sales order. The supplier enters the order in its own system as an SO. Sage says this confirms "the items, quantities, prices, discounts, and delivery terms."
3. Seller fulfills. Sage notes that on the selling side the sales order starts the internal fulfillment process and can guide allocating stock, scheduling production or assigning resources for service delivery.
4. Seller invoices. After delivery the seller issues an invoice. Sage separates the two clearly: the sales order confirms the purchase request, while the invoice is the official request for payment once the transaction has been completed.
5. Buyer matches and pays. Back on the buyer's side, AP compares the invoice with the PO and the receiving record before paying. The sales order is not part of that match. It belongs to the seller's records, and a buyer who files a copy is keeping it as evidence of what the supplier agreed to, not as a document AP is required to match.
The practical consequence: the PO number is the thread that ties the two sides together. If the supplier's sales order and invoice both carry your PO number, matching is simple. If they carry only the supplier's own order number, someone in AP has to work out which PO the invoice belongs to.
When the sales order changes the deal
A sales order is not always a perfect copy. Sage points out that the seller might request slight modifications to the buyer's original PO, such as adjusting delivery dates or offering alternative products, and that a sales order lets the seller document those changes and get the buyer's confirmation.
This is where buyers get caught. The PO in your system says 100 units delivered on the 15th. The supplier's confirmation says 80 now and 20 on backorder, or a substitute part number. If nobody on the buying side reads the confirmation and updates the PO, the invoice will not match and AP will flag an exception that is really a change everyone agreed to weeks earlier.
Two rules prevent most of these problems. First, treat any difference between the confirmation and your PO as a request to change the PO, and change the PO formally rather than noting it in an email. Second, make sure the change is recorded before the goods arrive, so receiving staff check the delivery against the updated quantities and not the original ones.
Which one is legally binding?
There is no single answer, and the sources are careful about that. Ramp's table says a purchase order "becomes binding when accepted" and that the sales order "represents acceptance of the PO."
Sage goes further. It says that in most cases the sales order represents the point at which formal acceptance becomes legally binding, particularly if it mirrors the purchase order. But it adds that the original PO may specify that only its exact terms are valid, in which case the purchase order can also be legally binding, and that the point at which the contract becomes binding can vary by industry and by the laws governing sales contracts where the transaction happens.
For AP teams, the useful takeaway is narrower than a legal opinion. Keep the PO, the supplier's confirmation if one was sent and any change order together, because those are the documents someone will ask for if a dispute starts. If a contract question does arise, take it to whoever handles your contracts rather than relying on a software vendor's blog, including the ones cited here.
Where software links the two: drop shipments
In most businesses the PO and SO live in different companies' systems. A drop shipment is the case where both appear in the same system. A seller takes a customer's order and has its own vendor ship directly to that customer, so the seller holds a sales order with the customer and a purchase order with the vendor for the same goods.
Microsoft Dynamics 365 Business Central handles this directly. Its documentation explains that when a sales order is marked for drop shipment and you create a purchase order with the customer's address in the Ship-to field, you can link the two documents to instruct the vendor to ship directly to the customer. From a sales order with drop shipment lines, the Create Purchase Orders action suggests the PO lines and pulls the vendor from the item card or stockkeeping unit card, which you can change if needed.
The point for AP is that one sales order can create one or more purchase orders. When you receive the vendor's invoice for a drop-shipped order, match it against the PO, but check that the linked sales order shows the customer delivery as complete, because your own warehouse never saw the goods.
Do you need sales orders at all?
If you only buy, no. Sales orders are a seller's document, and a business that never sells physical goods on account can run its whole AP process on POs, receiving records and invoices. If you also sell, especially from stock, sales orders are how you reserve inventory and plan shipments before invoicing, which is the internal role Sage and Ramp both describe.
If you are setting up the buying side, our purchase requisition vs purchase order guide covers the approval step before a PO exists, the purchase order template lists the fields a supplier expects, and the small-business PO software roundup compares tools that generate and track POs.