When Retry Logic Creates the Duplicate

The integration didn't fail.

It succeeded twice — and your retry policy is why.

The Pattern

Here's what happens in a typical NetSuite integration without idempotency controls:

1. Middleware sends a create request — invoice, journal entry, sales order.
2. The request hits NetSuite. NetSuite processes it.
3. The response takes too long. The connection times out. Or a load balancer returns a 503.
4. The middleware sees a non-200 response.
5. Retry logic kicks in and sends the same request again.
6. NetSuite processes it again. It has no reason not to.

Now you have two records. Both valid. Both created by your integration. Neither flagged as a duplicate.

This isn't a bug in NetSuite. It's not a bug in the middleware. It's a missing concept in the integration design.

Why Timeouts Are Not Failures

Most retry logic is built on a simple assumption: if the response isn't a success, the request didn't work.

That assumption is wrong.

A timeout means the response didn't arrive. It says nothing about whether the server processed the request. A 503 means the gateway couldn't reach the backend — but the backend may have already committed the transaction before the gateway gave up.

The dangerous responses aren't the ones that say "no." They're the ones that say nothing.

Retry logic that doesn't distinguish between "the server rejected this" and "I don't know what the server did" treats both the same way: try again.

That's how duplicates get created. Not by failure. By ambiguity.

Where This Hurts

In low-volume environments, duplicates get caught manually. Someone notices a double invoice during review. It gets voided.

In high-volume environments — or environments where records feed downstream processes — the damage compounds:

• Duplicate vendor payments. AP processes the first. Nobody catches the second until reconciliation stops tying out.
• Duplicate journal entries. Financial reporting drifts. Period close takes longer. The variance gets written off as "timing."
• Duplicate sales orders. Fulfillment picks the same order twice. Inventory counts diverge.
• Duplicate customer records. Every downstream system that syncs from NetSuite inherits its own copy. CRM. Billing. Support.

The blast radius of a single retried request is almost never one record. It's every system that trusts that record as a source of truth.

What's Actually Missing

The fix isn't removing retries. Retries are fine. Networks are unreliable. Servers restart. Timeouts happen.

The fix is making retries safe.

External IDs. NetSuite supports external IDs on many record types. Use them deliberately. A plain create should not be allowed to produce a second record with the same external identity. An upsert can resolve to the existing record instead. The exact behavior depends on the integration path and method, but the design goal is the same: the second attempt must resolve to the first transaction, not create a new one.

This is the single most effective control available, and most integrations I've audited don't use it consistently. It gets applied to customers and vendors but skipped on transactions — exactly where the financial risk lives.

Pre-submission lookups. Before retrying a create, check whether a record with matching identifiers already exists. This adds latency. It also prevents duplicates. That's a tradeoff worth making on financial records.

Application-layer idempotency. If your middleware supports it, tag every outbound request with a unique key. On retry, check whether that key has already been processed. This is more work than external IDs, but it catches cases where the record type doesn't support them cleanly or where the integration path makes external ID behavior unpredictable.

Response-aware retry paths. A 400-level error means the request was understood and rejected. A timeout or 5xx means you don't know what happened. Those are different situations. They need different code paths.

The Audit

Start with the retry path, not the happy path.

• Does every create request include an external ID or equivalent idempotency key?
• Does the retry logic differentiate between a rejection and a timeout?
• Is there any duplicate detection before the second attempt fires?
• Do your integration logs capture request IDs or external references for each outbound call, so you can correlate a retry with its original attempt?

If the answers are unclear, run a saved search. Filter by Date Created, Created By (your integration user), and group by record type. Look for records created within the same minute with matching amounts, entities, or line items.

Then check external ID values on those records. If they're blank on transactions — invoices, journal entries, vendor bills — but populated on master records, you've found the gap. That's where the risk lives.

If this integration has been running for more than six months without idempotency controls, the duplicates are likely already there. The volume just may not have made them visible yet.

Bottom Line

Retry logic is not optional. Unreliable networks are a fact of production.

But retry without idempotency is just a duplicate generator with a delay.

Every create request needs a stable identity. Every timeout needs to be treated as ambiguous. Every retry path needs to assume the first attempt may have already succeeded.

The integration didn't break. It did exactly what you told it to do — twice.