Why ERP integration matters
The ERP is the system of record for finance, inventory and operations — but it is rarely the only system. eCommerce stores, CRMs, warehouse systems, shipping tools, banks, payroll and BI all need ERP data or feed data into it. Without integration, staff re-key orders, stock levels go out of date and month-end becomes a reconciliation marathon.
Problems we solve
- Online orders typed manually into the ERP
- Stock levels in the store that do not match the warehouse
- Customer and pricing data maintained in several places
- Bank and payment data reconciled by hand
- Reports built from exports of several systems
What’s included
eCommerce ↔ ERP
Orders, customers, products, prices and stock between store and ERP.
CRM ↔ ERP
Accounts, quotes, orders and invoice status for sales teams.
WMS & 3PL
Shipments, receipts and inventory movements.
Banks & payments
Statement import, payment files and processor settlements.
EDI
Orders, ASNs and invoices with large trading partners.
BI & data warehouse
ERP data for analytics and reporting.
Designing reliable ERP integrations
- Clear ownership — which system is the master for each data type.
- Event-driven where it matters — orders and stock in near real time; bulk data on a schedule.
- Idempotency — no duplicate orders or invoices when messages are retried.
- Exception handling — failed records queued, alerted and easy to fix and replay.
- Respecting ERP limits — API governance and batch sizes tuned to avoid performance issues.
ERPs and tools we work with
Integration patterns
| Pattern | Good for |
|---|---|
| Real-time API calls | Prices, stock checks and order submission |
| Event-driven (webhooks, message queues) | Status updates and decoupled systems |
| Scheduled batch sync | Large catalogues, nightly financial data |
| Integration platform (iPaaS) | Many connectors with low-code maintenance |
Making integrations reliable
- Clear ownership of each data type — one system is the master
- Retries with backoff and dead-letter queues for failed messages
- Idempotent processing so retries do not create duplicates
- Monitoring dashboards and alerts for failures and delays
- Logs that show what was sent, when and with what result
Typical integrations
Common ERP connections include e-commerce stores, CRM, warehouse systems, shipping carriers, payment providers, banks and BI tools. See enterprise integration, SAP integration and Dynamics 365 development.
Example: order-to-cash integration
-
Order placed
Web store or CRM sends the order with customer, items and prices.
-
Validation
Integration checks customer, credit limit and stock in the ERP.
-
Order created
ERP creates the sales order and returns its number.
-
Fulfilment
Warehouse picks, packs and ships; tracking is sent back.
-
Invoice and payment
Invoice created in the ERP; payment status synced to store and CRM.
Each step is logged, so if an order stalls, support staff can see where and why without asking a developer. Error queues allow failed messages to be corrected and reprocessed.
Questions to answer before you start
Integration scope depends on the data flows and systems involved:
- Which ERP version and modules are in use, and which APIs are available?
- Which data must flow in which direction, and how quickly?
- What volume of transactions is expected at peak?
- Who is responsible for monitoring and fixing failed messages?
Data ownership: which system is the master?
Most ERP integration problems trace back to two systems both believing they own the same data. Before building anything, we agree a system of record for each data type and which direction changes flow.
| Data | Typical master | Flows to |
|---|---|---|
| Products, prices and stock | ERP | E-commerce, CRM, marketplaces, POS |
| Customers and accounts | CRM (prospects) then ERP (trading accounts) | Both, with matching rules |
| Orders | Sales channel where they are placed | ERP for fulfilment and invoicing |
| Shipments and tracking | ERP or WMS | Sales channel, customer notifications |
| Invoices and payments | ERP / accounting | CRM and customer portal |
A typical pattern; your processes may differ. The point is that every field has one owner.
Testing ERP integrations properly
- A sandbox ERP environment with realistic master data, not an empty company
- Test cases for partial shipments, back-orders, returns, credit notes and cancelled orders
- Duplicate and out-of-order messages, to prove idempotency
- Tax, currency and rounding differences between systems
- Peak-volume tests before seasonal spikes
- Sign-off by finance on reconciliation reports, not just by IT on message delivery
Common ERP integration mistakes
- Syncing everything in real time when a scheduled batch would be simpler, cheaper and easier to recover
- Hard-coding mappings such as tax codes and warehouses instead of using maintained lookup tables
- Ignoring API limits of cloud ERPs, which throttle high-volume integrations
- No reconciliation, so missing orders are discovered by customers or at month-end
- Integrating around bad master data instead of cleaning duplicate customers and products first
Each of these is cheap to avoid at design time and expensive to fix after go-live.
Running integrations after go-live
An ERP integration is a living system: new products, warehouses, tax rules and sales channels are added every year. We hand over documentation of every mapping, a monitoring dashboard and runbooks for replaying failed messages, and we can provide ongoing support with agreed response times.
-
MonitorDaily
Automated checks on message failures, queue backlogs and reconciliation totals.
-
ReviewMonthly
Errors, performance and upcoming changes such as ERP updates or new channels.
-
AdaptAs needed
Mapping changes and new flows as the business evolves.
See also enterprise integration, ERP migration and e-commerce development.
Batch, near-real-time or real-time?
| Timing | How it works | Good for |
|---|---|---|
| Scheduled batch | Runs every few minutes, hourly or nightly | Price lists, product catalogues, accounting summaries, large volumes |
| Near-real-time | Changes are queued and processed within seconds to minutes | Orders, shipments, stock levels for most stores |
| Real-time (synchronous) | One system calls the other and waits for a response | Credit checks, live price or availability lookups at checkout |
Real-time integration is not automatically better. Synchronous calls make one system depend on the other being available; queued, near-real-time flows are more resilient and recover automatically after an outage.
Cloud ERP API limits and performance
Cloud ERPs such as NetSuite, Dynamics 365 and Business Central limit how many API calls or concurrent requests an integration can make. High-volume integrations designed without these limits in mind slow down or fail at peak times. We design with limits from the start: batching updates, using bulk APIs where available, caching reference data and spreading heavy jobs outside business hours.
- Check the published limits for your ERP edition and licence
- Use change tracking or webhooks instead of polling for changes
- Load test with realistic peak volumes before seasonal spikes
- Monitor throttling responses and alert before they cause backlogs
These design choices are documented in the integration specification, so the team running the integrations later understands why each flow works the way it does.
Before go-live, finance and operations confirm that reconciliation totals match for at least one full business cycle — a day, a week or a month-end, depending on the flow — so everyone trusts the numbers from day one.
Related services
Part of ERP development. See also enterprise integration, B2B eCommerce and SAP integration.
This page is part of ERP Development Services — see the full overview for related services, approach and pricing.