When a plant tells us “we want to put in an order management system,” it is rarely the case that everyone in the room is picturing the same thing. Sales is describing the inbound side, purchasing is describing the outbound side, and production control is describing requirements calculation. This article does not compare products or rank vendors. It works through a different question: how far should a single system reach, and at what point should you hand the work over to purchasing management, MRP, and production control — plus how to present the cost and the return of that decision internally.
What this article covers, and what it does not
Most content on this subject is weighted towards product comparisons and vendor feature lists. What actually stalls a real factory first, though, is not the number of features. It is the decision about coverage: how much you are willing to entrust to one system. Collect quotations before that is settled and each vendor will scope differently, which makes the price comparison meaningless from the outset.
Here is the scope of this article.
| Covered here | Not covered here |
|---|---|
| How to divide scope across sales orders, purchase orders, procurement and MRP | Evaluations or rankings of named products |
| What material requirements planning does and does not calculate | The assumption that “installing MRP reduces inventory” |
| Design responses to paper that survives because of trading partners | An approach that assumes you can ask every partner to go digital at once |
| Issues specific to a factory in Thailand (customs, multi-currency, BOI, e-tax, language) | Definitive rulings on whether Thai schemes apply to you |
| A framework for estimating cost across five layers | A single “market rate” figure |
| How to construct the payback argument internally | A claim that “it pays back in X years” |
We have already published a related article, Production Management System Comparison 2026, which sets out the comparison axes for the wider system landscape. This article drills into just one part of that picture: the entry and exit points of a transaction.
Why “order management system” fails to mean the same thing to everyone
One term covering three different jobs
The phrase “order management system” is used to refer to at least three distinct activities. They handle different data, involve different counterparties, and fail in different ways.
| How it is described | The activity it actually refers to | Main counterparty | What happens when it goes wrong |
|---|---|---|---|
| Sales order management | Receiving customer orders, confirming them, answering on delivery dates, releasing to shipment | Customers and their procurement departments | Slow delivery date answers, stockouts, shipping errors |
| Purchase order management | Issuing orders to suppliers, chasing delivery dates, matching against receipts | Suppliers and subcontractors | Material does not arrive and production stops; excess inventory builds up |
| Purchasing management | Deciding what to buy, at what price, from where, approving it, and controlling it through to payment | Internal requesters, finance, audit | Approval becomes a formality, unit prices go uncontrolled, audit findings appear |
When someone in your organisation says “let’s systematise our order processes,” the first thing to establish is which of these three they mean. Sales usually has sales order management in mind, while purchasing has purchase order management and purchasing management in mind. Both can sit in the same meeting and be drawing entirely different pictures.
Why inbound and outbound should not be blended
Sales orders and purchase orders look similar in that both involve exchanging order documents. The decisive difference is who holds the initiative.
On the inbound side, the format and the transmission method are generally decided by your customer. It is rare to be in a position where you can demand “please send it in this format.” On the outbound side, by contrast, you have some room to ask suppliers to receive documents the way you prefer. So even within the same goal of “digitising order documents,” the inbound side is a technical problem of automating receipt, while the outbound side is an operational problem of standardising what you send.
Ignore this asymmetry and design for a single sweep of “digitising order processing” and you will always get stuck on the inbound side, because reality intervenes: formats differ by customer, Web-EDI portals are separate for each one, and some partners still send nothing but fax. The realistic design approach is to split the two and take a different route for each.
Have the decomposition conversation first
The first thing to do internally is produce a single sheet along these lines. It is not difficult work, but its presence or absence changes the quality of every conversation you then have with vendors.
| Item to establish | Inbound (sales orders) | Outbound (purchase orders) |
|---|---|---|
| Monthly volume | How many customers, how many orders per month | How many suppliers, how many orders per month |
| Main method of receipt or dispatch | Fax, email attachment, Web-EDI, EDI | Email, fax, telephone, portal |
| Who decides the format | The customer | Your company (with room to negotiate) |
| Where it is entered today | Which Excel file or which system it is transcribed into | Same |
| Number of transcriptions | How many times per order, and by whom | Same |
| Frequency of change and cancellation | Frequency of forecast and firm-order changes | Frequency of delivery date change requests |
| Connection to downstream steps | How it flows into production planning, shipping and invoicing | How it flows into receipt inspection, inventory and payment |
The “number of transcriptions” line matters most, because it becomes the foundation for the cost-benefit argument later. Whether one order is entered three times inside your company or only once is well worth measuring before any system is installed.
Dividing scope across sales orders, purchase orders, purchasing, MRP and production control
Five domains side by side
This is the core of the article. The single biggest reason these projects wander is that nobody shares a common understanding of how far each system is supposed to reach. Start by laying the five representative domains side by side.
| Domain | The central question | Data it primarily holds | What it typically does not hold |
|---|---|---|---|
| Sales order management system | How to confirm a customer order, and when to respond | Sales order records, customer part numbers, prices, delivery dates, shipping instructions | Bill of materials explosion, process load calculation |
| Purchase order management system | How to issue supplier orders and how to chase delivery dates | Purchase orders, supplier part numbers, prices, confirmed dates, receipt records | The calculation of what to buy and how much |
| Purchasing management system | Whose approval, and on what terms, the purchase proceeds under | Purchase requisitions, approval history, contract prices, supplier master, payment terms | Calculation of requirements based on the production plan |
| MRP system (material requirements planning) | To meet the production plan, what should be ordered, when and in what quantity | Bill of materials (BOM), inventory, lead times, open order balances | Verification of actual equipment capacity, operator assignment |
| Production management system | Managing plan, actuals, inventory and cost as a single flow | Production plans, work results, inventory, process progress, cost | Individual accounting entries, detailed cash flow |
The point to take from this table is that it is MRP, not the purchase order management system, that calculates what to buy and how much. A purchase order management system issues what has already been decided and then tracks it. Confuse the two and you end up in the familiar position of having installed a purchase order system while still calculating requirements in Excel.
What material requirements planning calculates, and what it does not
MRP is not a universal answer. Expectations drift here more than anywhere else during a selection process, so it is worth being direct.
| Item | What MRP calculates | What MRP does not calculate (needs another mechanism) |
|---|---|---|
| Required quantity | Explodes gross requirements from the production plan and the BOM | Correction for a BOM that no longer matches reality |
| Order timing | Offsets by item-level lead time to produce an order date | Detection of lead times that have diverged from actuals |
| Net requirements | Deducts inventory and open order balances | The gap between book inventory and physical inventory |
| Lot sizing | Rounds to order lots and minimum order quantities | Judgement on whether the resulting inventory increase is acceptable |
| Capacity verification | Produces order dates assuming infinite capacity, ignoring constraints | Actual load levelling of equipment and people (a separate scheduler is required) |
| Procurement execution | Goes as far as producing the information on what to order | Supplier selection, price negotiation, approval, payment |
| Exception handling | Can produce a list of exceptions | Judgement on which exceptions to handle first |
The accuracy of MRP output is determined by the accuracy of three master data sets: bill of materials, inventory and lead time. Run MRP while those three are out of step with reality and nobody will trust the order proposals, and the operation reverts to “the buyer fixes it from experience.” When MRP comes up in a selection discussion, it is more useful to check the current state of those three masters before debating features.
Note also that standard MRP calculates as though equipment capacity were infinite. If you need a plan that accounts for capacity constraints, the design has to combine MRP with something else, such as a production scheduler. We set out that whole picture, including this dividing line, in Production Management System Comparison 2026 — worth reading alongside this article if you are at the stage of taking on requirements calculation.
Three patterns for “how much sits in one system”
In practice the options come down to roughly three patterns. None is inherently correct; the answer follows from your existing assets and your organisation.
| Pattern | Configuration | Situations it suits | Points to watch |
|---|---|---|---|
| Separated | A dedicated mechanism for order handling; requirements calculation and inventory in the production management system | A production management system already exists and only order handling is still on paper | Integration design and maintenance are mandatory. Always budget for integration cost |
| Integrated | One product covering sales orders, requirements calculation, purchase orders, inventory and cost | You are replacing everything, and you operate a single site | Broad scope, so the duration and the internal workload are both large |
| Front-end only | Digitise only the exchange of sales and purchase orders, leaving the core system alone for now | You want to stop manual entry from paper and fax first, and core replacement is further out | Requires integration design so it does not simply become “one more place to type” |
The front-end-only pattern shows results quickly, but it is also the pattern where design mistakes are easiest to make. If received order data does not flow automatically into the core system, your staff end up working in both the new screen and the old Excel file, which increases effort rather than reducing it. If you choose this pattern, decide up front at what point, in what unit, and in which direction data will be handed over.
Paper and fax survive because of a trading-partner structure
The numbers show the baseline is rising
Japan’s Small and Medium Enterprise Agency reports on ordering practices in its White Paper on Small and Medium Enterprises on an ongoing basis. The 2025 edition states that ordering by telephone and fax accounts for more than 20%. At the same time, a 2024 survey found that the proportion of businesses answering that their operations are “centred on paper or verbal exchange and not digitised” had fallen substantially compared with the 2023 survey. In other words, the overall baseline is rising, while a meaningful layer of telephone and fax remains.
The 2026 edition of the same white paper further notes that companies that have achieved optimisation of labour input tend to be the ones investing in labour saving, applying AI, and pursuing digitisation. The framing is telling: digitising order processing is not treated as an end in itself, but as part of the question of how to optimise the labour you put in.
The reason is not your own negligence
This is the point we most want to emphasise. Much of the reason paper and fax persist in order processing lies not in your own lack of effort, but in the structure of the other side of the transaction.
| Why it persists | Who decides it | What you can do about it |
|---|---|---|
| The customer uses only their designated Web-EDI portal | Customer | Automate the retrieval of data from that portal |
| Document formats differ from customer to customer | Customer | Hold the conversion rules on your own side |
| Small suppliers cannot afford system investment | Supplier | Standardise the format in which you send purchase orders |
| Drawings and specifications circulate as attachments to orders | Both | Decide where attachments are exchanged and stored |
| Urgent changes by telephone have become customary | Both | Consolidate changes into a single place of record |
| Paper copies are retained for audit and tax purposes | Regulation and internal policy | Confirm the electronic retention requirements, then decide the practice |
The foundation of business-to-business ordering in Japan is centred on adopting the Ryutsu BMS standard, or on adapting to whichever Web-EDI the trading partner designates. Which is to say, the situations where you get to choose the ideal method are limited. The realistic design objective is therefore not “get every partner onto one standard,” but “whatever form it arrives in, normalise it into a single form inside our own company.”
Design receiving automation and sending standardisation separately
Given that structure, the countermeasures split into two.
Automating receipt (mainly inbound) is a set of technical measures taken on the assumption that you cannot change the other party. Options include reading structured documents from email attachments, retrieving data from Web-EDI portals on a schedule, and taking fax receipts as images where a person confirms only the specified fields before committing them. The important point here is not to aim for 100% automation. Automating in descending order of volume, starting with your highest-volume customers, and having people handle the small number of exceptions, gives a far more stable return on the investment.
Standardising what you send (mainly outbound) is an area where you hold a reasonable degree of authority. The work is mainly operational: consolidating purchase order formats, shifting dispatch towards email (PDF plus data), and setting rules for how delivery date confirmations come back. Internal operating rules and communication to suppliers matter more here than technology.
Blend these two into one plan labelled “digitising order processing” and the difficulty of the inbound side will drag the outbound improvements to a halt with it. Splitting them into phases gets you further, faster.
Issues specific to running an order management system at a Thai factory
The import procurement ratio determines how heavy the work is
Japanese manufacturing in Thailand runs deep. JETRO confirmed the activities of 6,083 Japanese-affiliated companies in Thailand in a survey conducted between August and December 2024. Alongside that concentration, however, the procurement structure carries its own weight.
JETRO’s reporting on the automotive industry states that EV manufacturing cost in Thailand is roughly 20% higher than for Chinese producers, citing among the reasons the transport cost arising from around 60% of procurement being dependent on imports from China. That figure is usually discussed in terms of price competitiveness, but from an order-processing perspective it means something else: the higher the import procurement ratio, the heavier the work attached to each individual purchase order.
| Difference from domestic procurement | Additional work under import procurement | Implication for the order management system |
|---|---|---|
| Lead time | Separate stages for shipping, transport, customs clearance and domestic delivery | Can lead time be held per item in stages? |
| Documents | Invoice, packing list, certificate of origin and others | Can you fix where documents linked to an order are stored? |
| Currency | Order currency differs from accounting currency | Can you decide how the order-date rate and the receipt-date rate are handled? |
| Quantity variance | Difference between quantity received and quantity ordered | Can variances be recorded at inspection and fed back? |
| Duty and exemption | BOI raw material duty exemption quota, customs duty, VAT | Can you track the items and quantities inside the exemption quota? |
| Unit of tracking | Management by container or by lot | Do receipt lots connect to inventory and manufacturing lots? |
If you use MRP, the question of holding lead time in stages feeds directly into accuracy. Round an imported item’s lead time into a single number of days and, the moment customs is delayed, the order proposals will part company with reality.
Alignment with the BOI raw material duty exemption quota
At factories receiving BOI (Thailand Board of Investment) incentives, the raw material exemption quota has to be reconciled with actual receipts and issues. If order data and receipt data are not managed in a system, that reconciliation stays in a hand-maintained Excel file.
Thailand’s investment environment itself is in motion. Applications for BOI investment promotion in the first half of 2026 were reported at around THB 1.47 trillion, of which applications under the production efficiency improvement measures accounted for 132 cases worth THB 17.158 billion, centred on adoption of digital technology, machinery replacement, and automation and robotics. The BOI also announced new investment promotion measures on 15 January 2026, replacing schemes that expired in 2025.
That said, whether software investment such as an order management system qualifies for BOI incentives depends on conditions including industry, the nature of the investment and the application category. Nothing in this article should be read as a conclusion that your project qualifies. If you are considering it, always confirm directly with the relevant authority or with the BOI. In practice, the safe approach is to model the cost twice — once assuming incentives are granted and once assuming they are not.
The relationship with e-Tax Invoice / e-Receipt
Any discussion of digitising order processing eventually raises the question of where Thailand stands on electronic invoicing. This is an area with a lot of misunderstanding, so here is the position as it stands.
| Item | Position as at July 2026 |
|---|---|
| B2B electronic invoicing | Voluntary, not mandatory. No mandate is scheduled for either 2026 or 2027 |
| Direction of travel | A digital reporting roadmap towards 2028 is anticipated |
| The full route | Structured XML plus electronic signature, submitted to the Revenue Department by the 15th of the following month |
| Smaller businesses | Businesses with annual revenue of THB 30 million or less may use the simplified route (e-Tax Invoice by Email) |
| Tax incentives | 200% deduction for investment related to e-Tax Invoice / e-Receipt / e-Withholding, and the 1% e-Withholding rate extended to the end of 2027 |
| Status of the incentive process | Approved by cabinet in June 2026. Royal decree and ministerial regulations not yet published as at the date of this article |
| Responsible bodies | Technical standards from ETDA; scheme administration by the Revenue Department |
The important point is that the scheme is currently voluntary. An argument along the lines of “it will be mandated eventually, so we should act now” is weak ground for an internal approval paper, and it puts you in a difficult position later if the assumption changes. The more useful lever is that the 200% deduction and the e-Withholding incentive are stated as running to the end of 2027, which gives a genuine deadline to work against. Even so, the conditions and the procedure are awaiting subordinate legislation as at the date of publication, so confirm with your finance and tax staff and your tax advisers before building it into a plan.
For system selection purposes, the substantive requirement is not “support electronic invoicing immediately,” but whether the underlying data will be retained in structured form when XML output becomes necessary in future. Leave it in paper and Excel and a change of rules means rebuilding from scratch.
Approval authority and language
A recurring debate at Thai sites is how much purchasing approval authority to delegate locally. This is a matter of internal policy more than system functionality, but it feeds directly into system design.
| Issue | Problem that commonly arises | Design response |
|---|---|---|
| Scope of delegated approval | Every purchase routed through head office in Japan regardless of value | Split approval routes by value band and item category |
| Approver absence | Approvals stall during travel or leave, and orders are delayed | Define delegated approval and what happens when a deadline passes |
| Number of approval steps | Too many steps, squeezing lead time | Model the relationship between step count and order lead time before deciding |
| Screen language | Local staff cannot use it, so a Japanese expatriate enters data on their behalf | Make screen and document languages a selection criterion |
| Master data notation | Item names exist only in Japanese, so local staff cannot match them | Check whether multilingual fields exist for item names |
| Work instructions | Only Japanese procedures exist, so the system never takes hold | Specify local-language procedures as a contract deliverable |
On language, it is not unusual for a Japanese-affiliated factory in Thailand to be running Japanese, Thai and English simultaneously: reporting to head office in Japanese, local operator work in Thai, supplier correspondence in English. Check the screen language, the document language (purchase orders, delivery notes), the language of the procedures, and the language your support desk operates in — each separately. That is what prevents the post-go-live state where somebody has to keep translating forever.
The number of approval steps deserves particular attention. Steps tend to get added with the intention of tightening control, but every additional step delays the order, and that delay comes back as a delivery date problem. Set the risks you are protecting against alongside the delivery risk created by slow approval, compare them, and settle on a position for each value band.
Viewing the cost of an order management system across five layers
Why quotations end up impossible to compare
The common situation where several quotations arrive but cannot be compared usually arises because each vendor has included (or excluded) a different set of layers. Split the cost into the following five layers and ask every vendor to price at the same granularity, and the differences start to appear as differences in approach.
| Layer | What it contains | What to confirm in the quotation | How easily it is underestimated |
|---|---|---|---|
| 1. Licence | Right to use, user count, module configuration | How users are counted (concurrent or registered), annual revision terms | Low |
| 2. Initial build | Configuration, screen and document adjustments, testing, training | The line between what standard functionality covers and what becomes custom development | Moderate |
| 3. Integration with existing systems | Data exchange with accounting, production management, inventory and EDI | Integration method, data in scope, frequency, handling of failures | High |
| 4. Master data preparation | Items, suppliers, customers, prices, BOM, lead times | Who prepares which data, and by when | Very high |
| 5. Operation and maintenance | Maintenance fees, support, regulatory updates, version upgrades | Coverage hours, availability of local response, language, terms for fee revision | Moderate |
Of these five, layer 3 (integration) and layer 4 (master data) are the two biggest causes of delay. The complexity of integrating with existing systems is one of the largest obstacles this type of project faces. And both of these tend to look small in a vendor proposal while consuming more of your internal effort than anything else.
What to confirm about integration (layer 3)
Integration is often dismissed with “yes, it connects.” In reality the following questions apply. We recommend confirming at this level of detail before signing.
| Item to confirm | What to ask specifically |
|---|---|
| Method | API integration, file-based (CSV and similar), or direct database connection |
| Direction | One-way or two-way, and which side is the master of record |
| Data in scope | Which of items, suppliers, prices, purchase orders, receipts, inventory and journal entries |
| Frequency | Real time or daily batch, and how it relates to period-close timing |
| Keys | Which codes are used to match items and trading partners across both systems |
| Failure handling | When integration fails, who is notified, how, and how it is re-run |
| Division of responsibility | Which vendor is responsible for defects in the integration layer |
| Future changes | Who bears the cost of modifying the integration when the existing system is upgraded |
The last two are frequently absent from contracts. Leave division of responsibility vague in particular, and when something breaks both vendors point at each other while the shop floor stays stopped.
Master data preparation (layer 4) is your own work
Master data preparation is not something you can outsource wholesale. Consolidating item codes, deduplicating suppliers, setting price validity periods, reconciling the bill of materials against reality — none of these can be judged by anyone who does not know how your business actually runs.
| Master data | Judgements required during preparation | Example of the owner (responsible department) |
|---|---|---|
| Items | Treatment of obsolete parts, consolidation of similar items, unified numbering rules | Engineering, production control |
| Bill of materials (BOM) | Agreement with the latest drawing revision, treatment of substitutes | Engineering |
| Suppliers | Duplicate registrations of the same company, treatment of branch offices | Purchasing |
| Customers | Separation of bill-to and ship-to, credit information | Sales, finance |
| Prices | Validity periods, currency, quantity-break settings | Purchasing, sales |
| Lead times | Divergence from actuals, breaking imported items into stages | Purchasing, production control |
| Inventory | Reconciliation of book and physical stock, definition of storage locations | Production control, warehouse |
When you build the implementation plan, decide the owner for each master data set first. Any master without an owner will go unprepared right up to the go-live date. And it will surface after go-live as “the data does not match.”
If inventory master data is the harder problem in your case, Factory Inventory Management System Comparison 2026 sets out how to choose the mechanisms that bring physical and book stock into agreement.
How cost appears under a phased rollout
If you phase the work rather than installing everything at once, the cost profile changes with it. Here is one way to slice it.
| Phase | Scope | Layers mainly incurred | What this phase gives you |
|---|---|---|---|
| Phase 0 | Measure current volumes, transcription counts and lead times | Internal effort only | A baseline for measuring effect; evidence behind the requirements |
| Phase 1 | Standardise and digitise outbound purchase orders | 1, 2, 4 | Less transcription on ordering; a starting point for price control |
| Phase 2 | Connect receipt inspection and inventory | 2, 3, 4 | Visibility of receipt variances; better inventory accuracy |
| Phase 3 | Automate inbound receipt, starting with the largest customers | 2, 3 | Less order entry; faster delivery date answers |
| Phase 4 | Begin operating requirements calculation (MRP) | 1, 2, 4 | Standardised ordering; less dependence on individuals |
| Phase 5 | Connect to costing and accounting | 3, 4 | Better accuracy of actual cost |
Do not skip Phase 0. Without pre-implementation measurement you will be unable to say anything stronger than “it feels better,” which makes approval for the next phase hard to obtain. Manual recording is fine — just capture one to two months on a consistent basis.
How to explain the return on the investment
Talk in terms of processing cost per purchase order
The benefit of an order management system is difficult to express as “we need fewer people,” because the staff handling orders also carry other work. A framework that translates more easily is processing cost per purchase order.
A useful reference point here is the “Manufacturing Procurement Benchmark 2026” published by JAGGAER on 28 July 2026, along with its companion benchmark broken down by company size. The analysis covers more than 200 manufacturing organisations and more than 200 global customer projects, using data and benchmarks from The Hackett Group. These benchmarks present the following figures.
| Item | Figure presented |
|---|---|
| Realistically achievable ROI | 200–600% |
| Highest single case | 58.61x (one upper mid-market manufacturer) |
| Large enterprises above EUR 5 billion in revenue | 5–10% cost reduction from strategic sourcing alone |
| Mid-market companies with EUR 1–5 billion in revenue | Processing cost per purchase order reduced from over USD 15 to under USD 5 |
| The factor that determines the return | Not breadth of modules, but depth — embedding a small number thoroughly |
The necessary caveat is that this is a Western-centric benchmark and cannot be applied directly to Thai wage levels or trading practices. Paste “USD 15 becomes USD 5” straight into an approval paper for a Thai site and the argument collapses the moment somebody asks about the assumptions.
What is worth taking from this benchmark is not the money but two things: the framework of expressing the benefit as processing cost per purchase order, and the finding that depth, not breadth, determines the return.
How to set your own numbers
To calculate it for your own site, build it up as follows, using measured values throughout.
| Item | How to set it | How to measure it |
|---|---|---|
| Annual number of purchase orders | Decide first whether you count lines or documents | Aggregate from the existing system or from Excel |
| Time input per order | Total across raising, approval, sending, delivery date follow-up, receipt matching and payment processing | Record a few days by stopwatch or self-report |
| Hourly rate | Personnel cost including social contributions, divided by hours | Obtain from finance |
| Current processing cost per order | Time input × hourly rate | The product of the above |
| Expected reduction | Set out, activity by activity, which work reduces and by how much | Split by activity and attach the reasoning |
| Annual benefit | Reduction × annual volume | The product of the above |
Framed this way, the assumptions become debatable internally. You can answer questions like “how many minutes did you assume per order?” and “does that time go to other work, or does headcount actually fall?” with numbers. Present “effort will fall by X%” instead, and the discussion stops, because nobody can see the assumptions.
Note that where the time saved is redeployed to other work, personnel cost in cash-flow terms does not fall. In that case it is more accurate to restate the benefit as “how many more orders the same headcount can process.”
Build benefits in separate components
Benefits other than processing cost are also more convincing when they are built up separately.
| Benefit component | How to quantify it | Cautions |
|---|---|---|
| Reduced transcription effort | Entries eliminated × time per entry × hourly rate | Requires measured transcription counts |
| Fewer entry errors | Incorrect orders per year × loss per incident | Requires historical data |
| Enforced price control | Gap between contract price and actual order price | Measure the current gap first |
| Fewer expedited shipments | Annual reduction in express and air freight cost | Only the portion caused by missed ordering |
| Less excess inventory | Inventory reduced × cost of capital | Depends on MRP accuracy; do not overstate |
| Faster delivery date answers | Hard to quantify | Reinforce with lost-order and chasing history |
| Audit response effort | Annual hours spent locating and submitting evidence | Consider both BOI and tax purposes |
Enforced price control is the benefit most often overlooked. Once contract prices sit in the master data and are checked at the point of ordering, the gap between contract and actual becomes visible. How large that gap actually is varies widely by factory, so measure your current position first.
If you want to take purchase order data through into costing, Manufacturing Cost Management System Selection works through the granularity at which material cost should be captured.
Depth over breadth
The benchmark finding that depth rather than breadth determines ROI matches practical experience closely. In the ordering and purchasing space, products with longer feature lists look better. But the wider the set of modules you deploy, the greater the burden of preparing master data and embedding each one, and the more likely it is that all of them end up half-used.
The realistic approach is to pick one area with high volume, standard rules and a clearly identified owner, embed it completely, and only then move on. If you can reach a state where “issuing purchase orders and following up delivery dates goes through the system for every single order, without exception,” that data is then usable for inventory, for costing and for delivery date answers. Data from five modules each half-used is usable nowhere.
Order data as a delivery date management system
Where the basis for a delivery date answer comes from
A common motivation for looking at an order management system is that delivery date answers are slow, or that late deliveries are not coming down. What is worth understanding here is that an order management system on its own will not improve the accuracy of delivery date answers.
Answering on a delivery date requires at least the following information.
| Information required | Where it comes from | What happens without it |
|---|---|---|
| Stock on hand | Inventory or production management system | You answer based on stock that “should be there” |
| Work-in-progress status | Shop-floor results collection | You end up phoning around for progress |
| Sales orders already accepted | Sales order management | You promise the same stock to several customers |
| Open purchase orders and confirmed dates | Purchase order management | You cannot read the arrival date of materials |
| Equipment and labour availability | Production planning or scheduler | You answer assuming it can be made, and it is late |
| Standard manufacturing lead time | Accumulated actuals | You fall back on experience and intuition |
In other words, a delivery date answer only has a basis once sales orders, inventory, actuals and purchase orders are connected. Install only an order system with nothing connected to it, and your staff will enter data into the new screen and then telephone the shop floor for progress exactly as before. That is the “one more place to type” state.
Separate the causes of delivery delay
When you address late deliveries, saying “we will solve it with a system” without separating the causes sets expectations wrongly. The effective countermeasure changes with the cause.
| Cause of the delay | How much an order system helps | What to tackle first |
|---|---|---|
| Missed ordering | Strong effect | A mechanism to match order proposals against actual orders |
| Orders placed but confirmed dates not tracked | Strong effect | Recording confirmed dates and a chasing routine |
| Delay on the supplier’s side | Early detection possible, but the delay itself is not prevented | Accumulate delay history by supplier |
| Customs and transport delay on imports | Can be made visible through staged lead time | Record actual days for each stage |
| Waiting for internal approval | Strong effect | Review approval routes and step counts |
| Insufficient production capacity | Limited effect | Planning and load mechanisms (a different domain) |
| Specification and design changes | Communication of changes can be improved | Change control rules |
| Incorrect inventory information | Limited effect | Practices that reconcile physical and book stock |
The point of this table is that how much an order system helps varies completely by cause. Missed ordering, untracked confirmed dates and internal approval waits can all be improved directly by tidying up the ordering process. Supplier delays and customs or transport delays on imports cannot be prevented as such, but they can be detected early and accumulated as history. Insufficient production capacity and incorrect inventory data, on the other hand, belong to other domains entirely. If your reason for considering an order management system is to reduce late deliveries, start by confirming from your own records which causes your delays actually cluster around. Depending on that distribution, the investment you should prioritise may sit on the process side instead. We cover the process-visibility side in Process Management System Cost and Selection.
The value of accumulating supplier-level history
Once order data accumulates, you gain something as a by-product: on-time delivery performance by supplier. If your requested date at the time of ordering, the supplier’s confirmed date, and the actual receipt date are all recorded, supplier-level patterns become visible.
That information is useful in the following situations.
- Adjusting the lead time you set at ordering to match each supplier’s actual performance
- Building pre-emptive chasing into the process for suppliers who tend to run late
- Reviewing allocation where the same item can be sourced from several suppliers
- Presenting an evaluation that includes delivery performance during price negotiations
- Updating the lead time master in MRP with actual data
That last point matters most. When the lead times in MRP diverge from actuals, the reliability of the order proposals it produces falls away. Actual order history is the only material available for correcting that divergence.
Pre-purchase checklist
Before you move to selection and purchase, here are the items worth confirming, split between what to ask vendors and what to decide internally.
Decide internally first
| Item | What happens if you do not decide it |
|---|---|
| Whether the scope is inbound, outbound, or both | Each vendor proposes a different scope and comparison is impossible |
| Whether requirements calculation sits in this system | You sign with the MRP boundary unclear and additional cost appears later |
| The owner (responsible department) for each master data set | Nobody prepares it, and the data is not ready on go-live day |
| Approval route step counts and value bands | Approval design becomes excessive and orders are delayed |
| Which existing systems stay and which are replaced | Integration scope is never fixed and no quotation can be produced |
| The scope of work to be completed locally | Waiting on head office approval becomes the normal state |
| Screen and document languages | Local staff cannot use it and expatriates enter data on their behalf |
| Baseline measurement before implementation (volume, time, delays) | You cannot explain the effect after go-live |
Ask the vendor
| Item | What to ask specifically |
|---|---|
| Proposal scope | Which of the five layers the quotation covers |
| Standard functionality versus custom development | How far configuration goes, and where development begins |
| Integration method | API, file-based or direct database, and where responsibility divides |
| Master data migration | Which side migrates existing data, and in what format |
| Multi-currency | Order currency and accounting currency, and when rates are applied |
| Language | Languages for screens, documents, procedures and support |
| Local support | Whether there is a support desk inside Thailand, its hours and its languages |
| Tax compliance | Whether the data structure can meet future electronic tax requirements |
| Implementation duration | The duration of each phase and the internal effort expected |
| Acceptance criteria | What constitutes completion, and how performance and data are verified |
| Data extraction | In what format data can be extracted at the end of the contract |
That last item, data extraction, is rarely discussed at contract time but starts to matter a few years in. Transaction records have to be retained long term for tax and audit purposes, so it is worth confirming at the outset what format you can get them out in should you change systems.
How to bring trading partners along
Even when you are ready internally, nothing changes in practice without cooperation from trading partners. Asking every company at once, however, does not work. Split it into stages.
| Stage | Target | What you ask for |
|---|---|---|
| Stage 1 | Highest-volume key suppliers | A standard format for receiving purchase orders, and how to return confirmed dates |
| Stage 2 | Mid-tier suppliers | The same, presented with the results achieved in stage 1 |
| Stage 3 | Small and spot suppliers | Accept the existing method and absorb it on your side |
| Inbound | Highest-volume customers | Assume you adapt to their method, and look at automating retrieval |
Note that stage 3 is framed as “absorb it on your side” rather than “get them to comply.” Asking small suppliers to invest is not realistic, so accepting that you will handle that portion through your own operations moves the whole programme faster.
The whole path on a timeline
Rearranging everything above along a timeline gives the following. Durations vary greatly with circumstances, so treat this as a guide to sequence.
| Phase | Main activities | Roles required internally | What external help can cover |
|---|---|---|---|
| Decomposition | Separate whether the problem is sales orders, purchase orders or purchasing | Sales, purchasing, production control | Support in structuring the exercise |
| Measurement | Capture volumes, transcription counts, time input and delay history | Purchasing, production control | Design of what to measure |
| Scope decision | Fix the coverage of the five domains and the frame of the five cost layers | Management, IT | Structuring based on other companies’ experience |
| Master data review | Confirm the current state and the owner of each master data set | Engineering, purchasing, sales, finance | Design of the preparation procedure |
| Selection | Receive proposals from several vendors on identical conditions | IT, purchasing | Consolidating the requirements |
| Build | Configuration, integration, testing, training | All departments | Configuration, integration development, training |
| Migration | Master data loading, parallel running, cutover | Purchasing, production control, finance | Design of and support for the migration procedure |
| Embedding and measurement | Comparison against the baseline, adjustment of operating rules | Purchasing, production control | Review and improvement proposals |
The column worth studying is “roles required internally,” which is populated in almost every phase. Because an order management system deals with the work itself, outsourcing does not reduce your internal effort to zero. Build a schedule without allowing for those hours and the project will stall at master data preparation.
Frequently asked questions
What is the difference between an order management system and a purchasing management system?
An order management system handles the exchange of order data and the follow-up afterwards. Its centre of gravity is issuing purchase orders, receiving confirmed delivery dates, and matching against receipts. A purchasing management system centres instead on control — whose approval, on what terms — and handles purchase requisitions, approval history, contract prices, supplier evaluation and payment terms. In real products the two sets of functionality are frequently bundled together, so rather than judging by product name, decide first whether the problem you want to solve is the effort of the exchange or the control of approvals and prices, then evaluate features from that angle.
How much does an order management system cost?
It varies so much with scope that no single figure applies. There is, however, a framework for collecting quotations you can actually compare. Split the cost into the five layers set out in this article — licence, initial build, integration with existing systems, master data preparation, and operation and maintenance — and ask every vendor to price at the same granularity. Layers 3 (integration) and 4 (master data) in particular tend to look small in a proposal while consuming the most time and internal effort in practice. Because master data preparation involves a great many judgements that cannot be outsourced, budget for it separately as internal effort.
Does a smaller factory need an MRP system?
Size alone does not decide it. The useful indicators are the number of items, the depth of the bill of materials, and the frequency of ordering. If item counts are limited, the structure is shallow, and one person can hold the whole picture, the operation will run without MRP. Conversely, once item counts grow, common parts are numerous, and ordering depends on one person’s memory, MRP starts to earn its place. Bear in mind, though, that the accuracy of MRP output is determined by the accuracy of three master data sets: bill of materials, inventory and lead time. Deploy it while those three are out of step with reality and the order proposals will not be trusted, and you will end up back with manual work. Check the current state of all three before implementing.
Can it be used at a factory in Thailand? What should we watch for?
Yes, with several things to confirm. Multi-currency handling (order currency versus accounting currency, and when rates are applied); whether import lead time can be held in stages for shipping, transport, customs clearance and domestic delivery; whether the BOI raw material exemption quota can be reconciled against receipts and issues; whether screens, documents and procedures support several languages including Thai; and whether there is a support desk in-country. In addition, how much approval authority to delegate locally is a matter of internal policy, but too many approval steps will squeeze order lead time and come back as a delivery date problem. Consider splitting approval routes by value band.
Do we need to support Thailand’s e-Tax Invoice immediately?
As at July 2026, B2B electronic invoicing in Thailand is voluntary, not mandatory. No mandate is scheduled for 2026 or 2027, and the position is that a digital reporting roadmap towards 2028 is anticipated. The full route uses structured XML with an electronic signature, submitted to the Revenue Department by the 15th of the following month. Smaller businesses with annual revenue of THB 30 million or less may use the simplified route (e-Tax Invoice by Email). Note also that a 200% deduction for investment related to e-Tax Invoice / e-Receipt / e-Withholding and the 1% e-Withholding rate were approved by cabinet in June 2026 for extension to the end of 2027, but the royal decree and ministerial regulations are not yet published as at the date of this article. Confirm the conditions with a tax specialist. From a selection perspective, the more substantive requirement is not “support it now” but “will the underlying data remain structured when XML output becomes necessary?”
If we adopt EDI, does that solve our ordering problems?
EDI is an effective tool, but it does not solve the problem on its own. The foundation of business-to-business ordering in Japan is centred either on adopting Ryutsu BMS or on adapting to whichever Web-EDI the trading partner designates. On the inbound side, that means adapting to the other party’s method is the premise, and you are left supporting different portals and formats for different customers. The realistic design objective is not “unify every partner onto one method” but “whatever form it arrives in, normalise it into a single form inside our own company.” Note too that if the received data does not flow into the core system, your staff will be working in both the old and new screens, which increases effort. If you are considering EDI, design it through to where the received data goes.
How should we explain the payback?
Translating it into processing cost per purchase order makes the internal discussion much easier. Measure your own annual order volume, the time input per order (raising, approval, sending, delivery date follow-up, receipt matching and payment processing combined) and the hourly rate, then set out how much each activity reduces, with reasoning attached. For reference, the manufacturing procurement benchmark published by JAGGAER on 28 July 2026 puts realistically achievable ROI at 200–600%, and cites mid-market companies with EUR 1–5 billion in revenue reducing processing cost per purchase order from over USD 15 to under USD 5. That is a Western-centric benchmark, however, and cannot be applied directly to Thai wage levels or trading practices. Borrow the framework of talking in cost per order, not the figures themselves.
Are we better off deploying a wide set of modules from the start?
Not necessarily. The JAGGAER benchmark referenced above reports that companies which embedded a small number of modules deeply achieved a better return than those which deployed modules broadly — breadth does not determine ROI, depth does. That matches practical experience. The more modules you add, the greater the burden of preparing master data and embedding each of them, and the more likely it is that all end up half-used. Picking one area with high volume, standard rules and a clear owner, getting every transaction through it without exception, and only then moving on, also leaves you with data in a usable form.
Can BOI incentives be applied to an order management system?
Eligibility varies with industry, the nature of the investment, the application category and other conditions, so no definitive answer is possible. As background, applications for BOI investment promotion in the first half of 2026 were reported at around THB 1.47 trillion, of which applications under the production efficiency improvement measures accounted for 132 cases worth THB 17.158 billion, centred on adoption of digital technology, machinery replacement, and automation and robotics. The BOI also announced new investment promotion measures on 15 January 2026, replacing schemes that expired in 2025. If you are considering it, always confirm directly with the relevant authority or with the BOI. In practice, the safe approach is to model both cases — with and without incentives — and confirm that the investment is still acceptable without them.
Where should we start?
With measurement. Record four things for one to two months, manually if necessary: annual purchase order volume (having decided whether you count lines or documents), how many times one order is entered inside your company, how many minutes each person spends between raising an order and matching the receipt, and which causes your late deliveries cluster around. With those numbers, requirement priorities settle themselves, and vendor proposals become comparable on the same basis. Start from product comparisons without them and you will have no choice but to judge on feature counts.
Summary
Ordering discussions fail to align because one phrase — “order management system” — refers to three different jobs: sales order management, purchase order management and purchasing management. Breaking that apart and establishing which one you actually want to solve is the starting point.
On scope, the basic division is that MRP calculates what to buy and how much, purchase order management issues and tracks what has already been decided, and purchasing management controls whose approval and on what terms. The accuracy of MRP output is determined by the accuracy of three master data sets — bill of materials, inventory and lead time — and the fact that standard MRP assumes infinite equipment capacity is worth holding on to when setting expectations.
Much of the reason paper and fax persist lies not in your own lack of effort but in the structure of the trading relationship. The realistic design therefore splits into automating receipt on the inbound side, where you cannot change the other party, and standardising what you send on the outbound side, where you hold the authority.
Split cost into five layers — licence, initial build, integration with existing systems, master data preparation, and operation and maintenance — and ask every vendor to quote at the same granularity. Integration and master data tend to look small in a proposal while consuming the most time and internal effort. Deciding the owner of each master data set in advance is what determines whether the data is ready on go-live day.
The payback is easiest to explain when it is translated into processing cost per purchase order and built from your own measured values. Western-centric benchmarks cannot be applied directly, but the insight worth borrowing is that a broader module footprint does not produce a better return — embedding a small number deeply does.
Finally, order data only becomes the basis for a delivery date answer once it is connected to inventory, actuals and open sales orders. Implemented without those connections, it becomes one more place to type. Confirm from your own records whether your delays cluster around missed ordering and approval waits, or around production capacity and inventory accuracy, and decide where to invest from there.
You are welcome to talk to us before you have decided how much should sit in the order management system and where purchasing management or MRP should take over. In fact, the conversation is usually more productive before that decomposition is finished, because we can work through the assumptions together. Describing the situation as it is on the floor is enough — “orders still arrive by fax,” “purchase orders are typed out of Excel,” “every delivery date answer takes half a day.” Feel free to get in touch through our contact form, and we will work through a realistic path with you, including where the boundary with your existing production management system should sit.
References
- JAGGAER “Manufacturing Procurement Benchmark 2026”
- JAGGAER “Procurement ROI by Company Size: 2026 Benchmark”
- VATupdate “Thailand: E-Invoicing Remains Voluntary — 2026/2027 Updates and Tax Incentives”
- Fiscal Solutions “Thailand’s e-Tax Invoice System”
- The Nation Thailand (BOI applications, first half of 2026)
- Alvarez & Marsal “Thailand’s Renewed BOI Incentives (2026–2027)”
- Small and Medium Enterprise Agency, 2025 White Paper on Small and Medium Enterprises, Section 5: Digitisation and DX
- Small and Medium Enterprise Agency, Overview of the 2026 White Papers on Small and Medium Enterprises and Small Businesses
- JETRO, Survey on Japanese Companies Operating in Thailand, FY2024
- JETRO, “Thailand (2): The Current State of the Automotive Industry, Global Supply Chains and the Japanese Response”
