The PO Changed After Entry. What Happens Next?

At Buttonwood Merch, a made-up promo supplier, Lena has just entered an order for 250 navy totes. The blanks are on their way, the job is on the production schedule, and Owen in art has sent the proof.

Then the customer emails: "quick change, make it 300 instead of 250 and actually a different blue." Lena opens the order, Owen opens the proof, and Marcus in production asks the question nobody wants to hear: "Which blue are we making?"

The PO attachment still says 250. The email says 300. The printed job ticket says navy. The customer has asked for "a different blue," a color found somewhere between royal and mind reading.

Someone suggests just updating the order so everyone can see the new details. Marcus points out that "everyone" includes the person about to receive 250 navy blanks. Changing a number on screen won't turn the delivery truck around.

The people here are made up, but the situation probably isn't. Once an order is entered, a change from the customer has to be tied to the right order, laid out clearly, and checked against work that's already happening before anything gets updated.

First, figure out what kind of email this is

A changed PO shouldn't automatically create a second order, and it shouldn't automatically replace the first one. Start by matching it to the right customer, their PO number, and your order number, then look at the items to confirm. If you can't tell for sure which order it belongs to, have someone in order entry look at it before anything gets created or changed.

Look for explicit revision numbers and language like "replace the previous PO," but don't trust the subject line. "Updated order" could mean anything. Then sort the email into one of three buckets:

1. A new order. It's a different job.
2. A resend. Same order, nothing changed. A resent copy can be identical.
3. A change. Something about an existing order is different.

A changed attachment can carry the same filename as the old one. A change can live in the email while the attached PO stays untouched. When the two disagree, someone needs to ask, not pick one. At Buttonwood, the right move is to note the request for 300 totes, flag that the attachment still says 250, and leave the color open until the customer names an actual blue.

Lay out exactly what changed

"Updated PO received" tells production nothing. Your team needs a short list showing the old value next to the new one. Check quantities and sizes, item and color, prices, ship and in-hands dates, destination, artwork, and imprint instructions. Keep both documents, and don't let reshuffled lines look like removed items.

Separate real changes from cosmetic ones. A moved column isn't a new price. But a tiny wording change can matter: "ship by" and "deliver by" lead to different planning questions.

For the totes, a useful summary looks like this:

• Quantity: 250 → 300
• Color: navy → "different blue" (not confirmed)
• Price, dates, imprint: not mentioned, but need to be rechecked

Artwork needs care too. Note which file has been replaced and which lines use it. If the customer sends a new logo for one location, it shouldn't quietly replace the artwork on every product. More totes in a different color may also mean a new quote or a new spot on the schedule, so don't assume the old price or date still holds.

Check what's already happened before changing anything

The order tells you what's supposed to happen. Purchasing, art, and production know what has already happened. You need both before agreeing to a change. Ask:

• Has inventory been reserved, picked, or sent to a decorator?
• Has the artwork been approved, digitized, separated, or used in production?
• Have labels, cartons, or shipping documents been created?
• Has anything been produced, shipped, invoiced, or canceled?
• Are suppliers or subcontractors working from the old version?

The answers change the picture. Buttonwood needs to know whether the 250 navy blanks are still on the truck, whether 300 in the new blue are even available, and whether Marcus has already burned screens or set up the navy job. Your vendor's actual policies decide whether you can cancel, return, swap, or add to the blank order.

If production status is blank, that doesn't mean nothing has started. Missing information is a reason to pause the affected work and ask. And if there's a chance the floor keeps making the old version, put the job on hold using your normal process, then get someone to confirm the hold reached the floor. Before you release the updated job, repeat your pre-production checks, which our post on sales order readiness review covers.

Keep "asked for," "approved," and "done" separate

Give each change its own version number on your side, even if the customer kept the same PO number. Save the email or document, when it arrived, what it asked for, and which version it replaces. Then track every change through five states: requested, under review, approved, applied, or rejected.

While a change is under review, the approved version stays the one everyone works from. If you hold production, write down the scope, who owns the hold, and what releases it. Oracle's change-order documentation describes the same pattern: a change order goes through approval separately, and the active purchasing document is revised only when the change order is implemented.

Without clear states, purchasing might read "change received" as "go buy more blanks," and production might read "approved" as proof the job ticket is updated.

Right before you apply an approved change, read the live order again. If someone else edited it during review, reconcile the two edits instead of overwriting. An approval covers a specific list of changes, not a blank check. Partial approval isn't approval of the whole thing. If Buttonwood can get the extra 50 totes but not the new blue by the due date, that choice goes back to the customer.

Get sign-off from a named person on big changes

Decide ahead of time which changes need an okay. Usually that's anything that affects cost, what you promised the customer, what they already approved, or work that's already started. Quantity, item, color, price, dates, artwork, address, and imprint instructions often fall into that group.

Give the person deciding one packet: old and new values, what's unclear, what's already ordered or started, the likely cost or delay, and exactly what needs deciding. Software can build that packet, but the business call stays with a person. A typo in a contact name can follow a lighter rule. "A different blue" isn't tiny. Until the customer names the color and you understand the impact, keep the change on hold and say which work can keep going.

Update everyone, and confirm they got it

Once the change is approved, update only what it affects: order lines, the blank order, the schedule, the job ticket, the proof, and shipping or billing details. Don't wipe and replace the whole order.

"Order updated" is too vague for a production team deciding which file to run. Say which changes were accepted and which version is now in effect: "Version 2: 300 totes, blue confirmed as the customer's named color, imprint unchanged." For important handoffs, get a confirmation back. An email to production isn't the same as a new job ticket on the floor.

Some partners can't take a reliable update. Hit's ordering guide directs order changes to customer service or sales and says they can't be made online. When a system can't take the change, assign someone a manual task and keep it open until they confirm it's done. If any update fails, show the change as partly done and keep the affected work on hold until everything matches.

Tell the customer what you've agreed to

A received request isn't an accepted change. Tell the customer what you've received, what you've accepted so far, and what you still need, like the actual blue. Say so if price or timing changes. Don't imply the original schedule survived automatically.

Test the awkward revisions

Run duplicate emails, an older revision arriving late, two changes in parallel, a partial shipment, and a failed downstream update through your process. Make sure it resumes after an interruption without applying the same change twice.

PO change checklist

• The change is matched to the right customer, PO number, and order.
• New orders, resends, and changes are handled differently.
• Every change shows the old value and the new one.
• Conflicting documents and unclear requests are flagged.
• Blanks, production, proofs, and labels or cartons are checked, and blank status isn't read as "not started."
• Requested, approved, and applied changes are tracked separately.
• Big changes have a named person who signs off.
• The live order is read again right before updating.
• Every affected team gets the accepted changes and the effective version.
• The customer hears what was accepted, not just received.

Frequently asked questions

1How do I tell if a PO is a change or a new order?

Match the customer, their PO number, and your order number, then compare the details with the existing order. A matching PO number alone doesn't tell you whether it's a resend or a real change. If it's unclear, have someone in order entry take a look.

2Should a changed PO replace the original order?

Not automatically. Keep the original version and the customer's request, review what changed, and only update what was approved. Keep a record of what changed and who okayed it.

3What if the blanks have already been ordered?

Check whether they've shipped or arrived, and what your vendor will actually let you do: cancel, return, swap, or add more. Factor in extra cost, availability, and timing before agreeing to the change.

4Which changes need someone's approval?

Anything that affects cost, delivery dates, what the customer already approved, or work that's already started. That often includes quantity, color, price, dates, and imprint changes. The person approving needs to see what changed and what's already in progress.

5What can be automated when a PO changes?

Software can match the change to the right order, compare old and new details, check where blanks, production, and proofs stand, and put together the approval request. How much it can do depends on your systems and your shop's rules. Unclear requests and real business decisions should stay with a person.

Connect change handling to your order process

PO entry is one of Trelium's order workflow use cases. When you're ready to automate changes too, start by listing what you need: tie a changed PO to the original order, show what's different, check whether production has already started, keep a record of each version, and get the right person's approval. That list becomes your plan for making every "quick change" one tracked decision, not three teams making three different orders.