Salesforce is where the deal is won. NetSuite is where it becomes an order, an invoice and revenue. Between them sits one of the most common integrations in mid-market and growth companies – and one of the most common sources of quiet data drift.
A NetSuite Salesforce integration looks simple on a whiteboard: accounts, opportunities and orders flow one way; invoices and payment status flow back. In production, it has to cope with duplicate customers, changed orders, partial fulfillment, credit memos, multiple subsidiaries and NetSuite’s governance limits. This article covers the design decisions that keep the two systems in agreement.
Decide the system of record, object by object
Most problems in this integration trace back to one missing decision: which system owns each object, and for two-way objects, which system owns each field.
| Object | Usual owner | Flows to | Notes |
|---|---|---|---|
| Account / customer | Salesforce until first order, then shared | NetSuite | Financial fields (terms, credit limit, tax) owned by NetSuite |
| Contact | Salesforce | NetSuite | Billing contacts may need to be owned by finance |
| Product and price | NetSuite | Salesforce | Pricing changes should not be made in two places |
| Opportunity / quote | Salesforce | – | Becomes an order in NetSuite at an agreed stage |
| Sales order | NetSuite once created | Salesforce (status) | Changes after creation need a defined path |
| Invoice and payment | NetSuite | Salesforce (status, balance) | Read-only in Salesforce |
Write this table down for the client’s actual objects before building anything. Most “sync bugs” are two systems both believing they own the same field.
Stop duplicates before they start
Duplicate customer records are the most common long-term failure of this integration. They come from a few predictable sources:
- Matching on names. “Acme Inc” and “ACME, Inc.” become two customers. Match on a stored external ID, not on names or email domains.
- Retries without idempotency. A timeout after NetSuite created the record, followed by a retry, creates a second one. Use external IDs so a retry updates rather than inserts.
- Records created in both systems. If sales and finance can both create customers, they will. Decide where creation happens and enforce it.
- No exception handling. When a match is uncertain, the integration should stop and ask, not guess.
Cleaning up duplicates after a year of production is far harder than preventing them.
Orders change after they are created
The opportunity closes, the order is created, and then the customer changes the quantity, the ship date or the billing contact. The integration needs an answer for each change:
- Which changes in Salesforce are allowed after the order exists in NetSuite?
- Are they applied automatically, or routed to someone in order management?
- What happens to an order that is partly fulfilled or already invoiced?
A common, sound approach is that Salesforce owns the commercial agreement until the order is created, after which NetSuite owns the order and Salesforce shows its status.
Design for NetSuite’s governance limits
NetSuite limits concurrent requests and script usage, and a busy integration can hit those limits at the worst moment – month-end, or a large import. Design for them rather than discovering them:
- Use SuiteTalk for record-level integration, and SuiteQL or saved searches for set-based reads instead of thousands of individual calls.
- Queue outbound work and process it at a controlled rate, with retries and backoff.
- Use SuiteScript or Map/Reduce where logic is better done inside NetSuite than through a round trip.
- Monitor concurrency errors and alert on them before they become a backlog.
NetSuite and Salesforce limits depend on edition and licensing. Check the client’s account before sizing the design.
Subsidiaries, currencies and tax
OneWorld accounts add subsidiaries, currencies and intercompany rules. The integration must know which subsidiary an order belongs to, which currency it is priced in, and which tax rules apply – and those decisions usually belong to finance, not to the integration.
Prove it agrees
A sync that runs without errors is not the same as two systems that agree. Build a reconciliation report from the start that compares, for a period:
- Customer counts and mapping exceptions.
- Closed-won value in Salesforce against order value in NetSuite.
- Invoice and payment status in NetSuite against what Salesforce displays.
The report should run on a schedule and list exceptions for someone to resolve.
Illustrative scenario: replacing a connector that drifted
This scenario is a composite. It is representative of the CRM-ERP integration work we do, but it does not describe a specific client, and nothing in it is a reported result.
A growing software company connected Salesforce and NetSuite with a packaged connector at launch. Two years later, finance maintains a spreadsheet of “real” customers because NetSuite holds duplicates, and sales sees invoice statuses that are days out of date.
The work starts with a system-of-record table agreed between sales operations and finance. Customers are matched once, by hand where necessary, and linked by external ID in both systems. A new integration replaces the connector: order creation at closed-won with idempotent external IDs, product and price owned by NetSuite, and invoice and payment status returned to Salesforce on events rather than overnight. A weekly reconciliation report lists any record the two systems disagree on.
What a good outcome looks like: the spreadsheet is retired, new duplicates stop appearing, and sales trusts the invoice status they see.
Related reading
- Integration reconciliation reports: proving two systems agree
- Rescuing an ERP or Salesforce project
- Idempotent webhooks: duplicates, retries and out-of-order events
Working with eProxim
eProxim does not run a NetSuite or Salesforce implementation practice. We work alongside the partners who own those platforms and build what keeps them consistent: two-way synchronization with conflict rules, deduplication and survivorship, SuiteTalk and SuiteQL integration designed around governance limits, and reconciliation reporting finance can sign off against.
Bring us the CRM-to-ERP work you would rather not hire for. See our NetSuite partner page, our services for Salesforce partners, or start a partner conversation.