WooCommerce Orders Not Syncing to Your ERP or Fulfilment System: Find and Recover Missing Orders

The short answer

For every WooCommerce order expected in another system, establish this chain:

WooCommerce order
→ eligible for synchronization
→ discovered by the integration
→ durably accepted for processing
→ delivered toward the destination
→ accepted by the destination
→ external ID recorded
→ business state reconciled

The first unproven boundary is where the investigation starts.

Do not classify an order as missing only because one dashboard does not show it.

Do not classify it as synchronized only because one HTTP request returned successfully.

"Order exists in WooCommerce" is only the first fact

WooCommerce can expose orders through its current REST API and notify external systems through webhooks.

The /wp-json/wc/v3/orders collection supports pagination and filters including creation and modification windows.

That establishes what WooCommerce can provide.

An integration still has to decide:

• which orders qualify
• when they qualify
• how they are discovered
• how complete result sets are collected
• what representation the destination expects
• how failures are stored
• how destination records are mapped back
• how missing or uncertain records are found later

That logic often lives partly outside WooCommerce.

Begin with two independent facts:

WooCommerce contains order 18452.

and:

The expected destination record cannot currently be confirmed.

Everything between those facts still needs evidence.

Build an order-reconciliation ledger

For missing-order incidents, create a temporary reconciliation ledger.

This becomes the central diagnostic record.

For each suspect order, populate as much of the chain as the evidence supports.

Useful classifications include:

• never eligible
• eligible but never selected
• selected but never durably accepted
• accepted locally but processing failed
• destination rejected
• destination accepted but acknowledgement was lost
• destination record exists but mapping was lost
• delayed
• fully synchronized
• still unknown

That is much more useful than a single state called "sync failed".

Failure boundary 1: the order was never eligible

A common source of "missing orders" is eligibility logic.

An integration may intentionally sync only orders with:

• selected statuses
• particular payment methods
• certain products
• selected countries
• particular shipping methods
• specific customer types
• required metadata
• an approved value range
• a custom business flag

A connector may, for example, export an order only after it reaches Processing or Completed.

WooCommerce statuses carry different business meanings. A paid physical-product order commonly reaches Processing, while On hold can mean payment is still awaiting confirmation. Stores can also introduce custom statuses.

The important question is:

At the time the integration evaluated this order, did it satisfy the configured synchronization rule?

Do not compare only the order's current status.

It may have become eligible later.

Timing is part of the evidence.

Eligibility should have an inspectable reason

A reliable integration should make exclusion explainable.

Instead of silently ignoring an order, the system should make it possible to establish something like:

Order 18452 was not exported because status on-hold is excluded.

or:

Order 18452 was deferred because the external customer mapping was incomplete.

That converts an apparent synchronization defect into an explicit business rule.

Current MyWorks troubleshooting documentation gives a useful real-world example. When WooCommerce orders do not automatically sync to QuickBooks Online, its checks include automatic-sync settings, selected order statuses, payment-method mappings and the sync log.

Those details are connector-specific.

The broader engineering requirement is:

If an order was excluded, you should be able to explain why.

Failure boundary 2: the order qualified but was never discovered

Some integrations are webhook-driven.

Others poll WooCommerce periodically.

Some use both.

Their failure modes are different.

Webhook-driven discovery

WooCommerce webhooks can notify an endpoint when order events occur.

A workflow can fail to start when a webhook is:

• paused
• disabled after repeated delivery failures
• pointed at the wrong endpoint
• rejected by authentication or firewall rules
• delivered to a receiver that fails before durably recording the event

WooCommerce exposes webhook delivery evidence, including request/response logging.

That history should not be treated as permanent forensic storage. WooCommerce's webhook API documentation retains only a limited number of the most recent delivery logs.

For an important integration, keep your own durable correlation evidence for accepted events and business operations.

Polling-based discovery

A polling integration typically asks WooCommerce for orders created or modified within a controlled window.

WooCommerce's current Orders API supports filters including:

• after
• before
• modified_after
• modified_before

along with explicit date/GMT interpretation.

Those are useful synchronization primitives.

They are not a complete synchronization algorithm.

The integration still needs explicit rules for:

• ordering
• checkpoint meaning
• page completion
• overlap
• failure recovery
• concurrent updates

Time windows can create gaps if checkpoint semantics are weak

Suppose one run records a checkpoint around 14:00 and the next run asks only for records strictly after that point.

Now ask what the system guarantees when:

• source and integration clocks differ
• an older order is modified during a running batch
• a checkpoint is advanced before every item is safely accepted
• retries occur after the source cursor has moved
• the query's ordering and checkpoint field do not match

The safe design depends on the integration.

A common reliability pattern is a controlled overlap window combined with repeat-safe processing and reconciliation.

Overlap can produce repeated candidates.

That is manageable when duplicate work is controlled.

A silent gap is much harder to detect when there is no reconciliation process.

Pagination is part of synchronization correctness

WooCommerce collection endpoints are paginated.

The REST API exposes page controls and response headers such as total resources and total pages.

An integration has to process the complete intended result set.

Do not assume:

first successful API response = all eligible orders processed

If 250 eligible orders exist and a client retrieves only the first page, the remaining orders can appear "missing" even though WooCommerce responded correctly.

Dynamic datasets need deliberate ordering and checkpoint behavior as well.

New or modified records may appear while a long synchronization is still processing.

That is not inherently a WooCommerce defect.

It is part of integration design.

Failure boundary 3: discovery succeeded but durable processing did not

An integration can successfully read an order and still lose it before the real work begins.

A fragile sequence is:

read WooCommerce order
advance checkpoint
attempt processing later
process crashes

The next synchronization cycle may begin beyond that order's source position.

A safer responsibility boundary is:

discover
durably record or enqueue
advance checkpoint

The implementation can vary, but the principle is durable:

Do not move the source cursor beyond work the integration has not safely accepted.

If Action Scheduler or another queue is involved, verify that the expected job was actually created.

If the job exists but is delayed or failing, that becomes the separate queue-health problem covered in WooCommerce scheduled-action backlog diagnosis.

Failure boundary 4: processing started but validation rejected the order

The connector may accept the WooCommerce record but reject it before any destination API call.

Common reasons include:

• unmapped product or SKU
• missing customer mapping
• unsupported country or state
• invalid address structure
• required tax data missing
• unsupported currency
• payment-method mapping missing
• required custom field absent
• inconsistent product or variation relationship

Current WooCommerce-hosted ERPNext integration documentation illustrates the same class of operational concerns: order-status mapping, payment mapping, scheduled synchronization, logs and manual resynchronization all influence whether an order reaches the downstream ERP correctly.

The implementation details vary by connector.

The broader principle is stable:

A valid WooCommerce order is not automatically a valid destination document.

The integration needs to expose which destination requirement prevented progress.

Correct the mapping boundary, not the commercial history

Suppose the ERP rejects an order because an SKU mapping is missing.

You correct the mapping.

That does not automatically mean the original WooCommerce order should be edited.

The WooCommerce order may already represent the correct commercial transaction.

The defect may belong to:

• the mapping table
• transformation logic
• destination master data
• replay procedure

Historical order data should not be mutated merely to make an integration accept it unless the business meaning of that change is understood.

Correct the responsible boundary.

Then recover the order through that corrected path.

Failure boundary 5: the destination rejected the request

Once the integration calls the external system, classify the response.

Authentication failure

Examples include:

• expired token
• revoked API key
• invalid signature
• changed permission scope

The destination has not necessarily accepted the business operation.

Validation failure

The destination understood the request but rejected its contents.

Examples include:

• unknown SKU
• customer record missing
• invalid tax account
• unavailable warehouse
• malformed field
• invalid state transition

Rate limiting

The destination is temporarily refusing additional work.

A retry may be appropriate when the operation is repeat-safe.

Server failure

A remote 5xx indicates a server-side failure or unavailable dependency.

Again, retry policy matters.

Define:

• retryable failures
• retry delay
• maximum attempts
• maximum age
• terminal failure state
• reconciliation procedure

Do not turn every error into an infinite retry loop.

Transport success is not always business acceptance

This distinction matters when middleware sits between WooCommerce and the final destination.

The integration sends an order to middleware.

Middleware returns:

202 Accepted

or:

200 OK

That may mean:

I accepted your request for further processing.

It does not necessarily mean:

ERP sales order ERP-78291 now exists.

A successful transport response can also contain a deferred or business-level failure state.

For synchronization, distinguish:

transport acceptance

from:

destination business acceptance

Operations ultimately need evidence such as:

• destination order ID
• confirmed sales document
• fulfilment record
• accounting transaction ID
• accepted destination state

Failure boundary 6: the destination succeeded but acknowledgement was lost

This is where blind replay becomes dangerous.

Consider this sequence:

1. WooCommerce order 18452 is sent.
2. The ERP creates ERP-78291.
3. The response is lost or the integration crashes before saving it.
4. Local state still says the order is unsynchronized.
5. Someone retries creation.
6. A second ERP record may be created.

The visible incident looked like:

order missing from ERP

but the external operation had already succeeded.

The real failure was:

success could not be confirmed locally.

Before replaying an uncertain operation, search the destination using stable identifiers.

Possible evidence includes:

• WooCommerce order ID
• external reference field
• order number
• integration operation key
• customer, amount and timestamp as supporting evidence

Avoid fuzzy matching as the primary identity mechanism when a stable identifier can be designed.

This is the same duplicate-side-effect problem addressed in prevent duplicate WooCommerce webhook processing.

Every synchronized order needs a stable cross-system identity

At minimum, the integration should be able to answer:

Which destination record corresponds to WooCommerce order 18452?

That answer should not require manually comparing customer names.

Store a durable mapping such as:

WooCommerce order ID → destination record ID

For example:

18452 → ERP-78291

Depending on system ownership, the mapping may live in:

• WooCommerce metadata
• a dedicated integration table
• middleware
• the destination
• more than one observable system where appropriate

Reliable mapping, retries and reconciliation are part of WooCommerce API and integration engineering rather than incidental connector details.

Order ID and displayed order number are different identifiers

WooCommerce exposes an internal resource id and a separate order number.

Custom numbering extensions can affect what users see as the order number.

An integration should not silently assume:

displayed order number = immutable WooCommerce resource ID

Define the machine identifier used for source mapping.

If the destination creates its own immutable ID, store that separately as well.

Human-readable labels help operations.

Stable machine identity makes recovery dependable.

Failure boundary 7: the record exists downstream but staff cannot see it

Sometimes synchronization succeeded and the operational view is misleading.

The downstream record may be:

• in a rejected or review queue
• in a draft/import state
• assigned to another warehouse
• filtered from the current view
• under a different status
• associated with another customer record
• hidden by permissions
• waiting for downstream batch processing

Before declaring an order absent, search the destination more broadly using stable identifiers.

"The warehouse dashboard does not show it" is not the same statement as:

the destination API or database has no corresponding record.

The missing boundary still needs proof.

Failure boundary 8: the queue is delayed rather than broken

Suppose orders usually appear in the ERP within one minute.

Today they take twenty.

That does not necessarily mean orders are lost.

The synchronization pipeline may be backlogged.

If background processing is involved, inspect:

• oldest pending work
• throughput
• arrival rate
• repeated failures
• external latency

Do not manually replay an order while its original synchronization job is still pending unless duplicate protection is established.

The original and manual attempts may both execute later.

Define an order-completeness state model

Each order expected in the external workflow should fit into an explicit state.

For example:

Not eligible

Business rules say it should not be exported.

Eligible

The order satisfies the export rule but has not yet been selected.

Accepted locally

The integration has durably accepted responsibility for the work.

Delivering

Processing toward the external system is in progress.

Rejected

A known validation or dependency problem prevented acceptance.

Accepted externally

The destination confirms the intended business record exists.

Reconciled

Source identity, destination identity and expected business state agree.

Terminal failure

Automatic recovery ended and human action is required.

The names can vary.

What matters is eliminating the undefined state:

maybe synced

Reconciliation is different from retry

A retry says:

Try the operation again.

Reconciliation says:

Establish the actual state in both systems, then decide what operation, if any, is still required.

Suppose WooCommerce contains order 18452.

Local integration state says failed.

The ERP contains ERP-78291.

Creating another ERP order is wrong.

Reconciliation says:

Destination record already exists. Restore the mapping and mark the operation complete.

Now consider order 18453.

WooCommerce contains it.

No durable integration acceptance record exists.

The ERP contains no corresponding record.

Reconciliation says:

The required destination operation is genuinely missing. Safely enqueue creation.

Different evidence leads to a different recovery action.

Build a reconciliation report, not just a resend button

For operationally important integrations, produce a report that answers:

This turns synchronization into an auditable business process.

A stronger integration question is:

Which WooCommerce orders should exist downstream but currently do not?

That is more useful than asking only whether yesterday's cron ran.

Define authority before reconciliation

Before comparing systems, define which system owns which facts at each stage.

For outbound order creation, WooCommerce may be authoritative for:

• checkout order identity
• purchased items
• customer-entered addresses
• payment-derived order state

The ERP may later become authoritative for:

• warehouse allocation
• fulfilment document
• invoicing
• dispatch state

Ownership varies.

A reconciliation process should not blindly overwrite one system with another because two values differ.

First ask:

Which system owns this field or state at this stage of the workflow?

That becomes even more important for inventory, shipment and refund synchronization.

Recover a missing order only after proving it is missing

Before replaying an order-creation operation, verify:

1. The WooCommerce order is valid for synchronization.
2. No confirmed destination mapping is already stored.
3. Destination lookup finds no existing corresponding record.
4. Original processing is not still pending.
5. Another worker does not currently own the operation.
6. Required mappings and configuration now pass validation.
7. The replay path is idempotent or otherwise duplicate-safe.
8. The business timing still makes the operation valid.

Only then should a missing creation be attempted.

This is deliberately more careful than clicking "retry all failed".

A public DevFluxr case study already documents WooCommerce API integration case study patterns built around stable identifiers, queued work, bounded retries and reconciliation. The same controls matter during recovery.

Recover in controlled batches

If three orders are missing, recovery is usually straightforward.

If 30,000 are uncertain, recovery becomes a production workload.

Do not resend the full range immediately.

Use staged recovery:

sample → verify destination → small batch → observe → increase carefully

Monitor:

• destination rate limits
• queue growth
• API latency
• duplicates
• local resource usage
• downstream operational volume

A recovery that overwhelms the ERP is not successful recovery.

Partial batches deserve item-level evidence

Suppose a batch intended to send 500 orders.

The first 327 succeed.

Then the destination starts failing.

If the only state recorded is:

batch failed

the recovery is ambiguous.

Did none succeed?

Did 327 succeed?

Was the last acknowledgement lost?

Reliable batch processing should retain item-level outcomes or provide a reconciliation path capable of reconstructing them.

Recovery should target:

the missing subset

rather than replaying the entire batch, unless the whole operation is demonstrably repeat-safe.

Webhooks and reconciliation solve different problems

Webhooks are useful for low-latency notification.

For a revenue-critical integration, they should not be the only control protecting order completeness.

A common reliability pattern is:

Webhook → fast event notification

plus:

Periodic reconciliation → detect missed or uncertain orders

A reconciliation job might ask:

Which WooCommerce orders became eligible in this controlled window, and which lack a confirmed destination mapping?

That creates a recovery path when:

• webhook delivery failed
• an endpoint was temporarily unavailable
• queue processing failed
• a deployment interrupted processing
• mapping state was lost

Webhooks improve responsiveness.

Reconciliation improves recoverability.

Reconciliation must not become another source of duplicate load

A poorly designed reconciliation process can create repeated work of its own.

Avoid repeatedly fetching store history and resending anything that appears incomplete.

Prefer:

• bounded time windows
• stable identifiers
• explicit state
• incremental checkpoints
• controlled overlap where appropriate
• repeat-safe decisions
• enough evidence to explain each outcome

Logging should answer business questions

HTTP status codes are useful.

They are not enough for operations.

For each order, ideally be able to answer:

• Was it eligible?
• Was it discovered?
• Was it accepted locally?
• Was a destination request made?
• What did the destination return?
• What external ID was assigned?
• What is the current recovery state?

That is operational observability.

It lets support, fulfilment and engineering discuss the same incident using one chain of evidence.

Do not mark synchronization complete too early

"Queued successfully" does not mean the destination accepted the order.

"HTTP request sent successfully" does not mean the ERP created the intended document.

Use state names that describe what actually happened.

For example:

queued → delivery_attempted → destination_accepted → reconciled

is more informative than a single boolean:

synced = 1

A boolean discards the intermediate evidence needed when a workflow fails halfway through.

Avoid one-sided health checks

An integration can look healthy from WooCommerce because:

• API requests return successful transport responses
• queues are empty
• no local exception is visible

Meanwhile, the destination may be rejecting a subset of orders into a validation queue.

The reverse can happen as well.

A meaningful completeness check compares:

expected source records

against:

confirmed destination records

This is why reconciliation is stronger than monitoring only one application.

Verification after recovery

Do not close the incident as soon as the missing order appears downstream.

For each recovered order, establish:

• destination record exists once for the intended business operation
• cross-system identity mapping is stored
• correct customer is associated
• items and quantities match
• totals and currency are correct
• shipping information is correct
• expected destination status is correct
• downstream fulfilment/accounting continues normally
• no duplicate job remains pending
• new orders synchronize without manual intervention

Then observe subsequent orders.

Yesterday's records can be repaired manually while tomorrow's orders remain vulnerable to the same defect.

Recovery and recurrence prevention are separate deliverables

A complete incident has two outcomes.

Incident recovery

Restore the specific missing or uncertain business records.

Reliability correction

Remove the condition that allowed them to disappear silently.

Example:

Recovery: create three ERP orders proven to be genuinely missing.

Correction: fix the eligibility rule and add reconciliation so future excluded or unprocessed orders become visible.

Another example:

Recovery: restore mappings to ERP records that already existed.

Correction: persist destination identity safely before advancing the integration's completion state.

Both matter.

A practical diagnostic sequence

1. Define what "missing" means

   Record:

   • source order
   • expected destination
   • expected timing
   • expected destination document or state

2. Select representative examples

   Use:

   • one missing order
   • one successful order from the same period
   • another failure if available

   A successful control helps locate the first divergence.

3. Check eligibility

   Compare:

   • status
   • payment state
   • product/customer requirements
   • mapping prerequisites
   • business filters

4. Check discovery

   Was the order:

   • included in webhook activity?
   • returned by the intended polling window?
   • included in the expected API result pages?
   • recorded by the integration?

5. Check durable acceptance

   Did the integration safely accept responsibility for the order before moving its checkpoint?

6. Check queue or background processing

   Did the expected job exist?

   Did it run?

   Did it fail?

7. Check destination delivery

   Record:

   • request
   • response
   • transport error
   • business validation result

8. Search the destination independently

   Do not trust only local synchronization state.

   Search using the stable cross-system identity.

9. Classify the failure

   Choose the best-supported state:

   • excluded
   • missed
   • delayed
   • rejected
   • accepted but unmapped
   • already synchronized
   • unknown

10. Recover only the required operation

    Do not replay work already confirmed downstream.

11. Verify the intended business outcome

    Confirm that one intended source order produces the expected destination result without an accidental duplicate.

12. Add reconciliation

    Make future silent gaps detectable.

The useful success criterion

A reliable integration is not one where:

the webhook endpoint is online.

It is not one where:

the cron ran.

It is not even one where:

the API returned 200.

The useful criterion is:

Every WooCommerce order that should enter the external workflow can be accounted for: either it has a confirmed destination record, an explicit reason it is not eligible, or a visible recoverable failure state.

That is order completeness.

Anything less leaves the business depending on silence.

Preventing missing-order incidents

For important WooCommerce-to-ERP or fulfilment integrations, define these contracts explicitly.

Eligibility

Which orders enter the external workflow, and when?

Stable identity

How does a WooCommerce order map to the external record?

Discovery

Webhook, polling or both?

Checkpointing

When is source progress safe to advance?

Pagination and windowing

How are complete result sets collected without gaps?

Validation

How are destination requirements checked?

Processing state

Can operations distinguish queued, attempted, accepted and reconciled?

Retry

Which failures are safe to repeat?

Idempotency

How are duplicate external records prevented?

Reconciliation

How are missing or uncertain records detected later?

Observability

Can one WooCommerce order be traced from source to destination?

These are the recovery model for a revenue-critical integration.

When to escalate

Specialist investigation becomes appropriate when:

• paid WooCommerce orders are missing from an ERP or fulfilment platform
• only some orders fail to synchronize
• connector logs report success but operations cannot locate the record
• manual resend risks creating duplicates
• order-status rules or custom statuses affect eligibility
• API pagination or date windows are involved
• synchronization uses background jobs that may be delayed
• destination validation fails for selected products or customers
• webhook delivery and connector state disagree
• external IDs are not stored consistently
• a batch partially succeeded
• teams compare systems manually to find missing orders
• previous retries recovered some orders but nobody can explain why others disappeared

The objective is not to resend orders until the counts match.

It is to:

Reconstruct order completeness across both systems, identify the first unproven boundary, recover only the operations that truly did not happen, then make future gaps visible and reconcilable.