If you’ve ever wondered “Is this a purchase order or a sales order?” — you’re not alone.
In modern fulfillment, manufacturing, and 3PL workflows, those terms often get used interchangeably. Luminous is designed to work the way operators actually think, not the way accounting textbooks do.
This article explains:
Why PO and SO language gets blurry
What those terms mean in practice
How Luminous models demand and purchasing behind the scenes
The important idea: intent matters more than terminology
At a high level, there is only one real question most teams are trying to answer:
“Given what we’ve already committed to ship or produce, what inventory do we need to cover it?”
Whether that commitment came from:
A customer order
A retail sales order
A 3PL shipment request
A co-manufacturer assembly instruction
…the intent is the same: demand now exists.
Luminous starts there.
Why “PO” and “SO” often mean the same thing in real life
Technically:
A Sales Order (SO) means you are selling something
A Purchase Order (PO) means you are buying something
But operationally, they’re two sides of the same commitment.
When you send an order to a partner:
You may call it a sales order
They may treat it like a purchase order
Both sides understand it as authorization to act
This is especially common with:
3PLs
Co-manufacturers
Contract packers
Dropship partners
So when customers say “PO,” they often really mean:
“The order that tells someone to ship or make something.”
What happens in co-manufacturing (this is where it gets confusing)
In a co-manufacturing setup, you may:
Own the raw materials
Send those materials to the co-man
Tell them to assemble finished goods on your behalf
In that case, the instruction you send is:
Not a traditional PO (you’re not buying materials)
Not a traditional SO (they’re not selling you the goods)
Functionally a production authorization
Many teams still call this a PO because:
It authorizes work
It commits capacity
It triggers billing for labor or services
That’s normal — and Luminous supports this reality.
How Luminous models this (the part that actually matters)
Luminous does not force you to think in rigid document types.
Instead, Luminous tracks three core concepts:
1. Demand
Anything that commits inventory or production:
Sales orders
3PL shipment requests
Assembly or co-man production instructions
If it creates an obligation to ship or build, Luminous treats it as demand.
2. Supply
Anything that fulfills demand:
On-hand inventory
Inbound purchase orders
Assemblies (built or planned)
3. Purchasing gaps
Once demand exists, Luminous answers the real question:
“What do I need to buy to fulfill everything I’ve already committed to?”
This can include:
Finished goods
Raw components
A mix of both
You don’t need to pre-build assemblies just to see shortages.
What to call things in Luminous
You may still see familiar terms in the system:
Sales Orders → Customer or downstream demand
Purchase Orders → Buying inventory or services
Assemblies → Converting components into finished goods
But under the hood, Luminous connects them through demand, not document labels.
If it creates obligation → it affects demand
If it provides inventory → it affects supply
Everything else is just naming.
The takeaway
If you ever find yourself thinking:
“I don’t care what this is called — I just need to know what to buy.”
That’s exactly how Luminous is designed to work.
Demand comes first.
Inventory planning comes next.
Paperwork follows.