commonsku purchase orders, explained for decorators

If you decorate for promotional products distributors, sooner or later a commonsku PO lands in your inbox. It looks different from a normal purchase order in several specific ways, and a few of them cause real problems — wrong customer names in your system, duplicate jobs, and artwork attached to an email nobody kept.

Here is what the document actually is, field by field, and where shops get caught.

The PO you receive is not the same PO the supplier gets

This is the single most useful thing to understand. When a distributor sends blank goods to a third-party decorator, commonsku generates two separate purchase orders from one sales order:

• One PO to the supplier, covering the blank goods and where to ship them.
• One PO to the decorator — you — carrying all the artwork and decoration details.

So your PO is a distinct document type, not a copy. It will reference product that is arriving from somewhere else, and it will not necessarily show the blank goods cost. If you have ever received a PO whose totals seemed to be missing the garments, this is why.

You are the "supplier" on your own PO

On a distributor's purchase order, the distributor is the buyer and you are listed as the Supplier or Vendor. The company name in the header or the Ship To block is usually the end client, not your customer.

This inversion causes more filing errors than anything else on the document. The customer you should be invoicing is the distributor who sent it — not the brand named on the shipping label, and not the individual contact whose name appears near the top. If you are entering these by hand, that is the field to double-check every time.

The date fields, and why one job arrives as three POs

commonsku carries several distinct dates, and they are not interchangeable:

• In-hands date — when the end client must physically have it. This is the one that matters.
• Firm date — flags an in-hands date that cannot move.
• Ship date — when it needs to leave.

commonsku combines products onto a single PO only when the supplier, in-hands date, firm date, ship date, shipping address and shipping method all match. Any difference and it splits them onto separate purchase orders.

That is why a single job sometimes arrives as two or three POs with consecutive numbers — different ship-to addresses, or a rush portion with an earlier in-hands date. They are one production run to you and separate documents to them. Worth reconciling before you quote, or you will bill three times for one setup.

Fields specific to decorator POs

• Decorator Notes — a dedicated field for instructions aimed at you. Read it before the general notes; distributors put the things that ruin jobs in here.
• Sample Order — a flag marking the PO as a sample rather than production. Easy to miss, expensive to miss.
• Shipping Account — set to the client's account, the supplier's, the distributor's, or another. This determines who pays freight and whose account number goes on the label.
• Account number — if the distributor has set you up properly as a supplier account in commonsku, your account number pulls onto the PO automatically.

Artwork comes attached to the email, not the PO

commonsku automatically attaches the artwork from the sales order to the outgoing decorator PO email. That is convenient and it is also fragile: the files live on that specific email. If the PO gets forwarded to your production person without attachments, or the email gets buried, the artwork is effectively gone and you are asking the distributor to resend.

Whatever system you use, the artwork needs to end up attached to the job rather than sitting in an inbox.

Purchase orders are static, and revisions get resent

commonsku POs send as static documents. They do not update in real time. If the distributor changes a quantity, a date or a decoration location, they have to regenerate the PO and send you a revised version.

Two consequences. You may receive a second PO with the same number and different contents, or a new number for what is really the same job. Either way, the risk is running production off a superseded document. When a second copy of a PO arrives, treat it as a version question rather than a new job.

PO numbers themselves are sequential from a number series the distributor's admin controls, and cannot be changed on an individual PO. So consecutive numbers from one distributor usually do mean related work.

What normally goes wrong

• The customer gets filed as the end client or the contact person rather than the distributor who owes you money.
• Split POs get quoted as separate jobs, double-charging setup, or get merged and under-billed.
• The in-hands date gets read as the ship date, costing you the transit days.
• Artwork stays in the email and is missing when production needs it.
• A revision is missed and the job runs off the old version.
• Scanned or image-only PDFs have no text layer at all, so nothing can be copied out and totals frequently come through as zero if you are using automated tools.

How fulflo handles these

fulflo gives you an inbound email address. Forward the PO — attachments and all — and it becomes a job with the PO number, line items, quantities, dates and customer already populated. Artwork lands attached to the job rather than living in an inbox. Image-only scans are handled, not skipped.

Because the parsing was built against real distributor POs received by a working shop, it knows the supplier field on a distributor PO is you, and looks for the buying company rather than the contact name. Anything it is unsure about lands as a draft for you to confirm rather than a wrong job you have to find later.

From there it is the normal flow: job status your customer can see in a branded portal, proofs with an approval record, and an invoice back to the distributor over Stripe, ACH or check.

Common questions