How to Create a Purchase Order From a Reorder Report Without the Handoff Delay

Purchasing

The decision and the document should not live in two different tools

Working out what to order and actually sending the purchase order are two different days, and the gap between them is lead time that goes unmeasured because it is yours. Here is the handoff in three steps, and what to watch once the PO is out. The numbers are invented so the arithmetic can be checked.

The short version
  • Lead time has a leg before the supplier ever sees the order: the days between deciding the quantity and sending the PO. It is real, it is measurable from your own records, and it is the leg that appears on no supplier’s quote.
  • Close it by making the reorder screen the place the PO is created from: select the lines, choose how they group, set the expected date, create the draft. No retyping.
  • Once it is out, the PO already knows when it is due. Sort by soonest due date, and put an approval step in front of the status you care about instead of in front of everything.

Ask how long a purchase order takes to turn into sellable stock and you get the supplier’s production time plus freight plus receiving. The obvious place to start the clock is the day the PO was sent. It started earlier: when the reorder report said the SKU needed ordering, and the days between that moment and the PO leaving are lead time too. They delay the stock exactly as much as a slow factory does.

That leg exists when the decision and the document live in different tools. The quantity is worked out on one screen, from a forecast. Then somebody opens a template, types the SKUs, types the quantities, looks up the costs, picks a PO number, emails it, and files it somewhere the forecast tool cannot see. Every handoff is another place for delay, and every retyping step is another place for error.

Three steps close the gap. An invented PO of five SKUs from one manufacturer runs through them.

First, measure the leg you are about to close

You cannot know whether this is worth fixing without a number, and the number is in your own records. For your recent purchase orders, find two dates: the day the reorder decision was made (the reorder report run, the meeting, the spreadsheet saved) and the day the PO actually went to the supplier. Subtract.

PODecision datePO sentInternal lag (days)
1Mon 4 MayFri 8 May4
2Mon 18 MayWed 20 May2
3Mon 1 JunThu 11 Jun10
4Mon 15 JunTue 16 Jun1
5Mon 29 JunMon 6 Jul7
6Mon 13 JulWed 15 Jul2
7Mon 27 JulFri 14 Aug18
8Mon 10 AugThu 13 Aug3
Average5.9

Invented, but the shape is the point. The average is about six days, and the average hides the two that matter: PO 3 waited ten days for a cost approval, and PO 7 waited eighteen because the person who sends POs was on leave and nobody else had the template. If your supplier’s quoted lead time is 45 days, a six-day internal average adds 13% on top of it, and PO 7’s eighteen days adds 40% — making the real elapsed times 51 and 63 days rather than 45. Nobody would accept a supplier who quietly added 40% to a lead time. This is usually the cheapest leg to attack, because shortening it does not require a supplier to agree to anything.

The internal lag is the leg of lead time most directly under your control, and it is the one that never appears on a report.

Step 1: select the lines on the screen that decided them

If your reorder process already holds the SKUs, the quantities and the costs, none of it should be retyped. That is the first principle, and it is about data rather than about which vendor you use: the quantities should flow into the PO without manual transcription. A forecast built in one system and a PO raised in another is fine, as long as the numbers move as data and not as someone’s typing. (Not every reorder report carries current supplier cost — if yours does not, that is one field you will still have to source, and it is worth knowing which.)

In SKU Compass the reorder screen is the Order Estimator tab on Supply Analysis, and each row has a checkbox. Tick the SKUs you are ordering and an action bar appears with the count, the total units and the total dollars of what you have selected, and a Create PO from Selected button. The selection is the order. There is no second list to build.

Select in the order the reorder list gave you, which for a single supplier means every SKU from them that is at or below its reorder point, plus any that will cross it before the next order cycle. Ordering a supplier’s SKUs together matters for the next step.

Step 2: group the lines into the documents the supplier will receive

A purchase order is a document to one supplier. Five SKUs from one manufacturer can be one PO or five, and the right answer depends on how they will ship and how they will be approved. One combined PO is one document to send, one to chase and one to receive against. Separate POs per SKU let lines ship on different dates, get approved separately, and be cancelled individually without touching the others.

The other decisions at this step are the PO number, which should come from a sequence rather than a person’s memory, and the expected delivery date, which is the supplier’s promise written down at the moment it was made. That date matters more than it looks: it is the number you will later compare with the actual sellable date, and that comparison is how lead-time variability gets measured instead of guessed.

In SKU Compass those decisions are the fields on the Create Purchase Order dialog that opens from the action bar. It names the Manufacturer the selected SKUs are ordered from. The PO Number is auto-generated if left blank, so the sequence is the system’s, not a person’s. Expected Delivery is a date field. And PO Grouping is an explicit choice between One combined PO and Separate PO per SKU, each numbered from your prefix. The lines below carry the quantities from the estimator, case-rounded, with unit cost and extended cost per line.

For the invented five-SKU PO: if all five ship together in one container, one combined PO. If two of them are on a different production run and will ship three weeks later, split those two out, because an expected delivery date is only useful if it is true for every line under it.

Step 3: create the draft, then track it from the date it already knows

The draft is the handoff. Everything after it is the supplier’s leg plus freight plus receiving, and your job changes from deciding to watching. The principle fits in one line: create the draft from the reorder decision, record the expected date, sort open POs by due date, and place approval at the point where commitment occurs. Two things make that cheap.

First, the PO knows when it is due, because you wrote the expected delivery date on it in step 2. A list of open POs sorted by soonest due date is the whole chasing schedule: the top row is the next conversation to have with a supplier. Chasing is a scheduling problem, not a diligence problem, and the dates are already in the system.

In SKU Compass the dialog’s final button is Create Draft PO, and the Purchase Orders screen lists POs with a due date and can sort on Due date (soonest). Sort that way and stop opening the tab to check; the top of the list is the PO to chase.

Second, if POs need a sign-off, put the approval in front of the status where it is needed, not in front of every keystroke. An approval gate on draft creation adds days to every order, including the routine ones, and it is how PO 3 in the table above lost ten days. An approval that triggers when a PO reaches a specific status lets drafts be built freely and stops the document before an unauthorised commitment can happen. Put the gate at the latest point your controls allow without letting one through — for some businesses that is the moment money commits, for others it is before the supplier ever sees the document, or above a dollar threshold, or on particular suppliers.

SKU Compass has these as an Approval Workflow panel on the same screen, where you choose the status the gate applies at and who signs off. The point is not the panel; it is that the gate sits where you put it, so the draft stage can stay fast.

What the expected delivery date is really for

It looks like a courtesy field. It is the promised finish line, and paired with two other dates it becomes your lead-time record. The distinction is worth getting right, because these are two different measurements:

  • Actual lead time = actual sellable date − the date the PO was sent. How long the supplier really takes.
  • Variance against promise = actual sellable date − expected delivery date. How late or early they were against what they said.

The expected date alone answers only the second one. You need the sent date to answer the first, which is the one this whole post is about. Capture all three and each PO becomes a row telling you, per supplier, both how long they take and how reliably they hit their own dates. A small history can expose an obvious delay; as it grows, it becomes useful for estimating lead-time variability and sizing a buffer on measurement rather than on a guess. The dates have to be written down at creation, in the tool that holds the PO, or they are never written down at all.

The same record answers the internal-lag question from the top of this post. If the PO is created from the reorder screen on the day the decision is made, the lag is the gap between the draft’s creation and the date it is sent. When that gap is a day, the leg is closed. When it is ten, you know which PO, and you can ask why.

When one PO per supplier is the wrong shape

“One per SKU or one per supplier” is a false pair. The working grain is usually supplier plus ship date plus approval state, and sometimes location, terms or currency too. Group lines that genuinely share all of those; split when one of them differs. Three common splits:

Lines on different production runs

If the supplier will ship three SKUs in four weeks and two in seven, one PO with one expected date is wrong for either three or two of them. Split by ship date so each document’s date is true.

Lines that need different approvals

A routine top-up and a large new-line commitment on the same PO means the routine lines wait for the big decision. Separate them so the routine order goes today.

A supplier who invoices per line

Some suppliers reconcile per SKU. Matching their paperwork to yours is easier when the documents have the same grain. Ask them which they prefer; it costs nothing and it shortens every reconciliation after.

What to do this week

  1. Measure your internal lag on your recent POs: decision date to sent date. Compare the average against that SKU’s planning slack and the supplier’s total lead time — two days is immaterial on a 90-day chain and serious on a 10-day one. If the lag eats into your slack, or if one PO is an outlier, this post is worth finishing.
  2. Create the next PO from the screen that decided it. Select the lines, choose one combined PO or separate POs, set the expected delivery date, create the draft. In SKU Compass: tick rows on the Order Estimator, Create PO from Selected, then Create Draft PO.
  3. Sort open POs by soonest due date and put any approval at the status where it belongs. In SKU Compass: Due date (soonest) on the Purchase Orders list, and Trigger when PO reaches status: under Approval Workflow.

The reorder point tells you when to order. Put your own lead time into a reorder point calculator and make sure the lead time you enter includes the days between the decision and the PO leaving. If you have never measured that leg, the number you have been using is short by exactly its length.

Questions people actually ask

How do I turn a reorder report into a purchase order?

Select the lines on the screen that produced the quantities, so the SKUs, quantities and costs travel as data rather than being retyped. Group them into one PO per supplier or one per SKU depending on how they will ship and be approved, set the expected delivery date, and create the draft from the same screen. The goal is to minimise elapsed time and eliminate retyping between the decision and the document.

What should a purchase order include?

The supplier, a PO number from a sequence, an expected delivery date, and per line the SKU, the quantity in the supplier’s shipping units, the unit cost and the extended cost, with a total. The expected delivery date is the easiest one to leave blank and the one that later lets you measure how long the supplier really takes.

Should I create one purchase order per SKU or one per supplier?

One per supplier when the lines ship together and are approved together; it is one document to send, chase and receive. Separate POs when lines ship on different dates, need different approvals, or may be cancelled independently, because a PO’s expected date and status should be true for every line under it.

How do I track when a purchase order is due?

Write the expected delivery date on the PO when you create it, then keep the list of open POs sorted by soonest due date. The top of that list is the next supplier conversation. Compare the expected date with the actual sellable date when stock lands, and keep that difference per supplier; it is your lead-time variability.

What is a purchase order approval workflow?

A rule that stops a PO at a chosen status until named people approve it. Placing the gate at the latest status your controls allow rather than at draft creation lets routine drafts be built without delay while still catching the orders that need a sign-off.

How do I measure the internal lag in my ordering process?

For your recent POs, record the date the reorder decision was made and the date the PO was sent to the supplier, and subtract. Look at the outliers as well as the average; a single eighteen-day wait for a signature or a template adds more to lead time than a week of port congestion would.

Every figure in this post is illustrative. The eight purchase orders and their dates, the 5.9-day average, the 45-day supplier lead time and the five-SKU order are invented for this article, are not drawn from any customer or supplier, and are shown with their arithmetic so you can substitute your own. Control names quoted for SKU Compass were read off the public HTML of app2.skucompass.com/supply-analysis.html and app2.skucompass.com/purchase-orders.html on 2 September 2026; what happens behind a login is described only where the pages’ own labels and hints say it. Written 15 September 2026.
Scroll to Top