Every ERP has a sales order module. So the question is never whether your ERP can take orders — it can. The question is whether order orchestration is a thing your business does often enough, and differently enough, to deserve a system of its own.
The answer is knowable from your own data, and it does not require a vendor conversation to work out.
The test: how often does an order split?
An order splits when its lines cannot all ship from one place at one time. Two lines from two warehouses. One line now and one on backorder. One line from a store and one from a third-party logistics provider.
Splitting is the thing ERPs handle badly. Not because the module is weak, but because an ERP sales order is designed as a financial document that happens to trigger a shipment. Once one document produces three shipments on three dates from three locations, you are asking a financial record to behave like a workflow engine.
So measure it. Take a month of orders and count the proportion that shipped in more than one consignment, or from more than one location.
Your ERP is enough. Handle the exceptions manually. Buying an OMS to solve a twentieth of your volume adds an integration and a licence to save a few hours a week.
It depends on trend and pain. If the number is growing because you are adding channels, plan for an OMS. If it is stable and your team copes, wait.
You want a dedicated OMS. At this level splitting is not an exception, it is your business model, and forcing it through an ERP sales order will cost more in workarounds than the OMS costs.
Three secondary questions
If the split test leaves you in the middle band, these usually decide it.
How many channels sell the same stock? One storefront is straightforward. A storefront plus two marketplaces plus a sales team plus EDI is four order shapes that need normalising before anything downstream can treat them alike. That normalisation layer is essentially an OMS, and you will build a worse one inside your ERP.
Who needs to change the routing rules? If a merchandiser or an operations manager should be able to change which warehouse serves which region, they need a system where that is configuration. In most ERPs it is a development ticket.
What does customer service need to see? If answering "where is my order" requires opening two systems, you have already got the answer, whichever module you keep it in.
The wrong version of this decision is choosing the OMS because it is more capable. The right version is counting your splits.
Implementation lead, AxonRaysWhat the ERP keeps either way
This is the part that gets muddled. Choosing an OMS does not move your order data out of your ERP. The ERP remains the system of record for the customer, the price, the invoice and the revenue. The OMS owns the orchestration: sourcing, splitting, holds, routing and the status a customer sees.
Draw that line explicitly at design time and write it down. Most OMS implementations that go badly do so because both systems believe they own the order status, and neither will yield.
The cost nobody quotes
An OMS adds a system to the estate, which means an interface, a monitoring requirement and a person who understands it. That is a real recurring cost, and it is why the split test matters: below the threshold, the cost of the seam exceeds the cost of the problem.
Above it, the calculation inverts, and the ERP workarounds start costing more every time you add a channel.