TL;DR
- ERP stands for Enterprise Resource Planning; it grew out of the MRP software factories used for material planning in the 1960s and 1970s, and took its current name in the 1990s.
- Most ERP systems cover five core areas: accounting and finance, inventory, purchasing, sales orders, and HR and payroll, usually switched on in phases with finance first.
- CRM owns leads, contacts and pipeline; ERP owns orders, stock, invoices and payments; the two meet at the quotation or sales order, and each field needs one owning system.
- Thailand's Revenue Department runs the e-Tax Invoice & e-Receipt system, so check that an ERP can output electronic tax documents plus the reports behind the monthly P.P.30 VAT return.
- The most common ERP failures are dirty master data, rebuilding old workarounds through customisation, and leaving CRM and marketplace integrations until the final week.
ERP (Enterprise Resource Planning) is software that runs a company's core back-office work, such as accounting, inventory, purchasing, sales orders and HR, on one shared database, so a single transaction updates every department that depends on it. In practice, ERP means a sales order entered once can reserve stock, trigger a purchase request, post revenue to the general ledger and appear in management reports without anyone retyping it. This guide covers what the acronym means, which modules sit inside a typical ERP, how data moves between them, how ERP differs from CRM, why it should connect to your CRM and online sales channels, how cloud and on-premise deployments compare, and how to implement one while avoiding the usual failures.
What does ERP stand for?
ERP stands for Enterprise Resource Planning. The name comes from manufacturing. In the 1960s and 1970s, factories used MRP (Material Requirements Planning) software to work out which raw materials to order and when. MRP II later added capacity planning and shop-floor control. When vendors extended the same idea to finance, HR, sales and distribution in the 1990s, the broader product was called ERP.
The word "planning" is now a little misleading. A modern ERP is mostly a system of record: it stores the official version of each transaction (invoices, receipts, stock movements, payroll runs) and enforces the rules around it, such as approval limits, costing methods and document numbering. Planning features like demand forecasting, production scheduling and budgeting still exist, but many companies use ERP first as the place where the numbers become official.
The defining feature is the shared database. Before ERP, a company might run a standalone accounting package, a spreadsheet for stock and a separate payroll tool. Each held its own copy of customer, product and employee data, and month-end meant reconciling them by hand. ERP replaces those copies with one master record per customer, product, supplier and employee.
What are the core modules of an ERP system?
Vendors package modules differently, but most ERP systems cover the same five areas. A company rarely switches all of them on at once.
Accounting and finance
The general ledger, accounts receivable, accounts payable, bank reconciliation, fixed assets and financial reporting. Every other module eventually posts journal entries here, which is why finance is usually the first module to go live and why the chart of accounts has to be designed carefully.
Inventory and warehouse
Stock quantities by location, lot or serial tracking, stock transfers, stock counts and the costing method, for example FIFO or average cost. Inventory is where website and marketplace orders most often break the numbers, because each channel reduces stock separately unless the systems are connected.
Purchasing
Purchase requests, approvals, purchase orders, goods receipts, and matching supplier invoices against what was ordered and what was received (the "three-way match"). Reorder rules can generate draft purchase orders when stock falls below a set minimum.
Sales and order management
Quotations, sales orders, delivery orders, invoicing and returns. Price lists, discounts and credit limits live here. This module is where ERP and CRM overlap the most, which is covered further down.
HR and payroll
Employee records, leave, attendance, payroll calculation and statutory deductions. In Thailand this includes social security contributions and personal income tax withheld at source, and payroll outputs have to match what the company files with the authorities.
Many systems add modules for manufacturing (bills of materials and work orders), project accounting, field service or point of sale. A workable rule: buy for the modules you need in the next two years, and check that the rest can be added later without re-implementing the whole system.
How does data flow through an ERP?
The value of ERP shows up when you follow one transaction across modules. Here is an illustrative order-to-cash flow for a company that sells air purifiers:
- A sales rep confirms a quotation for 20 units, and it becomes a sales order.
- The inventory module reserves 20 units from the Bangkok warehouse. If only 12 are available, a reorder rule creates a draft purchase request for the shortfall.
- Purchasing approves the request and sends a purchase order to the supplier. When the goods arrive, the receipt increases stock and records a liability awaiting the supplier's invoice.
- The warehouse picks and ships the order. The delivery order reduces stock and posts cost of goods sold to the ledger at the item's calculated cost.
- Accounting issues a tax invoice. Revenue and output VAT post to the general ledger automatically.
- When the customer pays, the bank statement line is matched to the invoice and the receivable closes.
Nobody retyped the order. Finance sees revenue and gross margin on the same day the goods leave, and purchasing sees demand before stock runs out. The opposite is the "swivel chair" setup, where staff copy an order from one system into another. Every copy is a chance for a typo, a delay and a mismatch that only surfaces at month-end close.
How is ERP different from CRM?
CRM manages the relationship before and around the sale: leads, contacts, opportunities, pipeline stages, campaigns and service tickets. ERP manages the transaction and everything after it: orders, stock, invoices, payments and costs. Put simply, CRM answers "who is likely to buy, and what have we told them?", while ERP answers "what did we sell, did we deliver it, and have we been paid?"
The boundary sits at the quotation or the order. Some companies create quotations in CRM and push them to ERP as sales orders. Others quote in ERP and send the outcome back to CRM. Either works as long as one system is clearly the owner of each record. CRM has its own explainer on this blog, so this section only covers where the two systems meet.
| Question | ERP | CRM |
|---|---|---|
| Main users | Finance, warehouse, purchasing, HR | Sales, marketing, customer service |
| Core records | Orders, stock, invoices, payments, payroll | Leads, contacts, opportunities, activities |
| Typical output | Financial statements, stock valuation, tax reports | Pipeline forecast, campaign results, follow-up lists |
| What it receives from the other | Confirmed orders and new customer records | Invoice status, payment status and order history |
Why connect ERP with CRM and your online store?
An ERP only knows about the sales that reach it. If orders also arrive from a website, a marketplace shop and LINE chat, and those channels are not connected, the ERP holds an incomplete picture and stock figures drift away from reality.
ERP and CRM
Connecting the two puts invoice status, outstanding balances and order history inside the CRM record, so sales staff stop promising stock that is not there or chasing a customer who has already paid. In the other direction, a won deal can create the customer and the sales order in ERP without retyping. The usual synchronisation covers customer master data, products and price lists, orders, and invoice or payment status.
ERP and e-commerce or marketplaces
For online sellers the critical link is stock. If a product sells on your own website and on two marketplaces, each channel needs the same available quantity, and each order has to reach the ERP so it can reserve stock, create the delivery and issue the invoice. Without that link, two customers can buy the last unit at the same moment on different channels. The integration should also bring marketplace fees and payouts back to finance, so settlement amounts can be reconciled against individual orders.
Why marketing cares
Ad platforms optimise toward the conversion values you send them. When order value, returns and margin come from the ERP rather than from a front-end tag alone, marketing can report on revenue that actually stayed after cancellations and refunds. That same data is what makes profit-based bidding possible later on.
Integrations are built with native connectors, through middleware that maps fields between systems, or with custom API work. Whichever route you take, decide which system owns each field (for example, ERP owns price and stock while CRM owns contact preferences) and how conflicts are resolved when both sides change the same record.
Cloud ERP or on-premise ERP?
Cloud ERP is hosted by the vendor or a partner and accessed through a browser, usually on a subscription. On-premise ERP runs on servers the company controls, in its own office or data centre. The comparison is less about which is better and more about who carries which responsibility.
- Upfront cost versus running cost. Cloud shifts spending to a recurring fee. On-premise needs servers, licences and IT staff up front, with lower recurring fees in some licensing models.
- Upgrades. Cloud versions update on the vendor's schedule, which keeps you current but can change screens and behaviour under your users. On-premise upgrades happen when you choose, which in practice often means they get postponed for years.
- Customisation. On-premise usually allows deeper code changes. Cloud products restrict changes to configuration and defined extension points, which limits flexibility but makes upgrades safer.
- Security and data location. Cloud providers handle infrastructure security, but you still own user access, passwords and permissions. If you have rules about where data must be stored, ask where the vendor hosts it.
- Integration. Cloud ERPs tend to expose web APIs that e-commerce and CRM tools can call directly. Older on-premise systems may need middleware in between.
Hybrid setups are common as well: cloud ERP for finance and sales, with a local system kept for a factory line or a legacy warehouse tool until it can be retired.
How do you implement ERP, and what usually goes wrong?
Implementation steps
- Map current processes. Write down how orders, purchases, stock counts and month-end close work today, including the spreadsheet workarounds. Those workarounds are requirements.
- Define scope and owners. Choose the modules for phase one, name a business owner for each, and agree what "done" means, for example the first month-end closed entirely in the new system.
- Select the system. Test vendors with your own scenarios: a partial delivery, a return, a foreign-currency purchase, a marketplace order. A demo on the vendor's sample data proves little.
- Design master data. Chart of accounts, product codes, units of measure, customer and supplier records, warehouse locations. Clean duplicates before migration, not after.
- Configure and integrate. Set up the modules, approval rules and document templates, then build the connections to CRM, the website and marketplaces.
- Migrate and test. Load opening balances and open orders, then run end-to-end tests with real users on realistic transactions.
- Train and go live. Train by role rather than by module. Plan the cut-over around a period close, and keep support available for the first weeks.
- Review after go-live. Compare month-end close time, stock accuracy and order errors against the baseline you recorded in step one.
Common risks
- Copying old processes into new software. Rebuilding every legacy workaround through customisation raises cost and makes future upgrades harder.
- Dirty master data. Duplicate customers and inconsistent product codes carry straight into the new system and break reports on day one.
- Scope creep. Adding modules mid-project delays go-live. Park new requests for phase two.
- No internal owner. If the project belongs only to IT or only to the vendor, business rules get decided by whoever happens to be in the room.
- Integrations left to the end. Channel and CRM connections tested in the final week tend to fail under real order volume.
- Too little training. Users who do not trust the system go back to spreadsheets, and the shared database stops being complete.
ERP and e-Tax in Thailand
For Thai companies, the ERP is usually where tax documents are produced, so it has to fit local requirements. A few mechanics are worth checking during selection:
- Tax invoices and receipts. The Revenue Department runs the e-Tax Invoice & e-Receipt system, which lets businesses issue these documents electronically instead of on paper, and it also offers an e-Tax Invoice by Email channel. Ask whether the ERP can produce documents in the required electronic format, or whether a service provider handles submission.
- VAT reporting. VAT-registered businesses file a monthly VAT return on form P.P.30, supported by output tax and input tax reports. The ERP should generate those reports from posted invoices, not from a separate spreadsheet.
- Withholding tax. Payments to suppliers and service providers often involve withholding tax and a withholding tax certificate issued to the payee. Check that the purchasing and payment flow can calculate it and issue the certificate.
- Thai language and Buddhist-era dates. Tax documents and reports may need Thai text and the Buddhist calendar, so test the templates, not only the screens.
Rules, formats and eligibility conditions change over time, so confirm the current requirements with the Revenue Department or your auditor before go-live rather than relying on a vendor's checklist alone.
What this means for Thai businesses
Many Thai SMEs start with an accounting package and add online sales through marketplaces, social commerce and LINE before they consider an ERP. By the time stock counts and month-end reconciliations start to hurt, orders are already scattered across several channels. The practical order of work is usually: standardise product codes and customer records, decide which system owns stock, connect the sales channels, and only then add planning features. A useful first measurement is how many hours a month the team spends copying orders and reconciling stock by hand, because that number is what the project should bring down.
Frequently asked questions
What is ERP in simple terms?
ERP is one system that holds a company's accounting, stock, purchasing, sales order and HR data in a single database, so a transaction entered once updates every department. It replaces separate tools and spreadsheets that each keep their own copy of the data.
Does a small business need ERP?
A small business needs ERP when manual reconciliation between sales, stock and accounting starts costing real time or causing errors, not when it reaches a particular headcount. A company selling one product through one channel can run well on accounting software; a company selling hundreds of SKUs across a website and marketplaces usually cannot.
Can ERP replace CRM?
ERP can replace CRM in a small company, because some ERP suites include a CRM module that covers basic contacts and quotations. Larger sales and marketing teams often keep a dedicated CRM for pipeline and campaign work and connect it to the ERP for orders and invoice status.
How long does an ERP implementation take?
There is no standard duration, because an ERP implementation depends on scope, the number of modules, data quality and integrations. A phased rollout, with finance and sales first and other modules later, reduces the risk of one long all-at-once project.
If your orders, stock and customer data sit in separate systems, our ERP and CRM integration service maps and connects them, and data integration and consolidation brings channel, finance and marketing data into one reporting layer. For wider process change, see our digital transformation service. If the online store is part of the problem, our e-commerce website design work builds stores that connect to back-office systems from the start.







