How Ops Teams Actually Use Netsuite (And Where It Goes Wrong)
Netsuite Diaries
If finance is the brain of your business, ops is the heart. And like any heart, it beats fastest when things go wrong.
For most brands, Netsuite is seen as the finance team’s tool. The ERP that keeps books balanced and investors happy. But for operations teams, it’s the command centre. It’s where decisions get made, unmade, and re-made every hour of the day.
So how do ops teams actually use Netsuite? And more importantly, where does it fall short?
The Ops Universe in Netsuite
Ask anyone in operations what their day looks like and you’ll rarely hear “calm and predictable.” Their role stretches across multiple flows:
Inbound / Procurement. Raising purchase orders. Linking POs to containers. Managing inbound shipments. Tracking what’s been received against what was ordered. And working out landed cost along the way.
Outbound / Logistics. Watching orders flow from the website into Netsuite and out to the warehouse. Checking SLAs. Managing edge cases like shortages, partial shipments, and re-routes. Making sure shipping data feeds back accurately into commerce platforms.
Reverse Logistics. Returns. Refunds. Reconciling what the customer sent back with what the warehouse says they received. Tracking customers with repeat discrepancies and making decisions about refund policies.
Inventory & Transfers. Moving stock between locations. Balancing multiple DCs. Raising transfer orders to replenish stores or wholesale customers. Managing stock counts, adjustments, and everything in between.
For ops, Netsuite isn’t just another system. It’s the system. Their entire workflow sits within it – or suffers from the lack of it.
Where It Goes Wrong
If there’s one common thread across operations teams we’ve worked with, it’s this: the happy path is designed perfectly, but the real world rarely follows it.
Trying to Do Too Much Inside Netsuite
Take demand planning. Brands often want to bake it into Netsuite’s native capabilities. In theory, it makes sense – one system to rule them all. In reality, Netsuite’s demand planning isn’t sophisticated enough for most brands’ needs. It ends up creating noise instead of clarity, forcing ops to build manual workarounds or external spreadsheets to fill the gaps.
Overcomplicating Inbound Reporting
Procurement teams want detailed inbound reporting: what’s ordered, what’s shipped, what’s landed, what’s delayed, what’s split across containers. Netsuite can provide some of this, but it’s not built as a freight management or supplier performance tool. Without integrating external data – from freight forwarders, suppliers, and brokers – reporting becomes partial at best.
Landed Cost: The Margin Killer
If there’s one topic that keeps coming up, it’s landed cost. The true cost of getting goods into your warehouse. The supplier price plus freight, duties, tariffs, customs – everything it takes to land the stock ready to sell.
Brands handle landed cost in different ways. Some try to pre-bake it into POs. Some rely on finance to adjust costs later. Others attempt to use Netsuite’s landed cost module. But here’s the kicker: if you don’t think about landed cost at implementation, fixing it later is painful. Historic transactions need amending. Financial periods might need reopening. Inventory costs get recalculated. We’ve seen brands spend months retrofitting landed cost data. It’s like repacking a container mid-ocean.
Ignoring Edge Cases
Shortages, recalls, mass reroutes. They’re not everyday events, but they will happen at some point – and if you’ve had them go wrong before, you know it’s worth bringing up past pain points during implementation, because they will come back around eventually.
Too often, solution designs focus only on the ideal flow – the smooth path from A to B – but real ops work rarely goes that way. But what happens when a container gets delayed? When half the shipment is damaged? When thousands of customer orders need mass editing because the wrong SKU was allocated?
Netsuite can handle these scenarios, but only if the process is designed upfront. Otherwise, ops teams end up fighting the system to fix what it wasn’t set up to fix.
Designing for Real Ops
So what does ‘good’ look like?
It starts with acknowledging that ops is messy. That exceptions are the norm. And that systems need to enable human decision-making, not block it.
For procurement, that means designing PO and container processes that reflect real supplier and freight behaviours. Building landed cost calculation methods that are accurate enough for finance, but operationally simple enough to run without constant manual workarounds.
For outbound logistics, it means enabling mass order edits, bulk SLA checks, and reroute processes as standard – not as panic-driven one-off tasks.
For reverse logistics, it means integrating returns data properly so refunds and inventory updates can happen confidently, without ops having to cross-reference five systems to check if a return is legitimate.
And across all ops teams, it means building dashboards they can trust. Not just data for data’s sake, but actionable, reconciled, real-time insights. Saved searches that actually save time. Reports that drive decisions. And enough training to embed confidence in using them.
Closing Thoughts
Netsuite is the ops command centre. But like any command centre, its power depends on how it’s set up and who’s trained to use it.
If your ops team is spending more time fighting Netsuite than running your operations, it’s time to rethink the setup. Because in the end, it’s not about the system – it’s about keeping the heart of your business beating strong, no matter what chaos the day throws at it.