ISP CRM vs ERP: Define the Boundary Before Buying
Separate customer and service workflows from enterprise finance, procurement and people operations, then integrate them through owned contracts.
Separate customer and service workflows from enterprise finance, procurement and people operations, then integrate them through owned contracts.
The systems answer different questions
An ISP CRM follows prospects, customers, services, contacts and support context. An ERP coordinates general ledger, procurement, inventory valuation, payroll and enterprise reporting. ISP billing and network entitlement sit between them. Confusion begins when one product claims ownership of every record.
CRM
Own relationship, contact, service request and support context.
Billing
Own products, invoices, payments, credits and access entitlement.
ERP
Own corporate books, procurement, assets and statutory reporting.
Integration
Exchange approved events with stable identifiers and reconciliation.
Assign one owner per fact
Customer-facing balance can come from billing while statutory receivables post to ERP. Product speed belongs to the service catalogue; purchased OLT cost belongs to procurement and asset records.
Duplicate editable masters create drift. Other systems may cache a value for display, but changes flow through the owner.
Integrate business events
Use invoice issued, payment verified, refund posted, inventory received and service activated events with idempotent references. Reconcile totals and exceptions rather than assuming delivery.
Map account codes, tax treatment, currency, departments and reseller liabilities before automating journal export.
Choose scope from complexity
A small ISP may need focused billing plus accounting export. A larger operator may justify ERP integration for procurement and multi-entity finance. Buying an ERP does not replace AAA, OLT or subscriber lifecycle controls.
Evaluate permissions, audit, close process, data export and correction workflows across the boundary.
Evidence before rollout
| Signal | Required proof |
|---|---|
| Ownership | Every shared field has one authoritative system. |
| Identifiers | Customer, invoice, payment and item references remain stable. |
| Idempotency | Repeated events do not duplicate journals or actions. |
| Reconciliation | Operational and statutory totals can be compared. |
| Correction | Reversal and adjustment preserve history in both systems. |
Put the plan into operation
- Map. List processes and record owners.
- Gap. Identify what current systems cannot perform.
- Contract. Define events, fields and error states.
- Pilot. Integrate one invoice-to-ledger flow.
- Reconcile. Test duplicates, reversals and period close.
- Expand. Add procurement or inventory only when justified.
The decision standard
The correct architecture is the smallest set of systems with unambiguous ownership, auditable event exchange and routine reconciliation. Product category labels matter less than those boundaries.
Research basis: TM Forum information framework; enterprise architecture separation-of-concerns principles; accounting control guidance. Validate implementation details against the releases, contracts, and local regulations governing your network.