1. Define what failed and how widely

Start with one missing order and one comparable successful order. Record their Magento identifiers, store views, timestamps, payment methods, product types, and expected ERP destinations. Compare orders from the same period so an older configuration does not distort the investigation.

Determine whether the issue affects every order or a specific pattern. Failures limited to one store view suggest routing or configuration. Failures involving bundles suggest item mapping. A sudden stop after a deployment suggests changed credentials, code, schema, or infrastructure.

Build a short incident timeline with the last known successful export and the first confirmed failure. Add deployments, ERP maintenance, certificate changes, and traffic spikes. This narrows the search without treating every recent change as the cause.

Clarify the expected delay. A scheduled integration may intentionally export every few minutes, while an event driven connector may start immediately. Define a reasonable processing window and distinguish delayed orders from permanently rejected ones. Do not assume the storefront's order confirmation proves that downstream fulfilment has started.

2. Build a traceable evidence record

Capture the Magento order number, internal order ID, connector job ID, correlation ID, destination, attempt count, response status, and ERP reference. These identifiers serve different purposes. A storefront order number should not be silently substituted for an API's internal entity identifier.

Line up timestamps using a consistent timezone. Compare the original order, middleware logs, API gateway logs, and ERP import history. Keep the outbound payload and response together, with credentials and unnecessary customer details removed. A generic message saying “sync failed” is insufficient for assigning responsibility.

Record the mapping version and connector release as well. Otherwise, a successful replay after a deployment may be impossible to explain. Preserve the original failure evidence before clearing jobs or restarting services, because cleanup can remove the strongest clues.

For each error, capture the rejected field or operation and the receiving system's explanation. Compare transformed values rather than just checking that a field exists. An empty string, a missing property, and a null value may have different meanings to the destination API.

Never infer success from log severity alone: an informational message may describe submission, while the actual rejection appears in another system.

3. Check order eligibility and polling logic

Review the export rule explicitly. Does it require payment authorisation, invoicing, a particular order state, or a custom status? Magento distinguishes programmatic order states from descriptive statuses. A custom status label does not automatically change the business workflow or satisfy a connector's eligibility condition.[1]

For polling integrations, inspect filters, sorting, pagination, and saved progress. Adobe's REST search conventions support search criteria and sort orders, but the connector must use them correctly.[2] A poller based only on creation time can miss older orders that become eligible later.

Use an appropriate update window and deterministic ordering, with overlap and deduplication where needed. Advance the checkpoint only after work is durably captured. Test multiple orders sharing a timestamp and records changing while pages are fetched; these boundaries expose gaps that normal testing misses.

Walk a test order through the status changes used by your business, including delayed payment confirmation. Check whether the connector notices each relevant transition. Keep intentionally held orders visible with a reason, so operations staff can distinguish a business decision from a broken export.

4. Verify access and destination configuration

Confirm the base URL, environment, store scope, ERP company, and integration identity. A valid request sent to a test tenant can look successful while production users see nothing. Check recent credential rotation, integration reauthorisation, and connector configuration changes.

For deployments using Commerce Admin integrations, API resource permissions are part of the integration setup. Verify access to the specific resources the workflow needs.[3] Avoid solving an access error by permanently granting every permission. Authentication setup differs across Commerce deployment models.

Investigate DNS resolution, certificate validation, firewall rules, and network timeouts from the system actually making the request. A developer's laptop reaching the endpoint does not prove that the connector worker can. Separate transport failures from application responses before changing payload mappings.

A successful read request verifies only part of the path. The integration may still lack permission to create or update the required object. Reproduce the necessary operation in an approved test environment using the same identity and configuration pattern as the failing worker.

5. Validate the complete order mapping

Compare a failed payload with the ERP's current contract. Check required fields, types, maximum lengths, accepted codes, and relationships between records. Missing customer accounts, unavailable warehouse codes, or unknown SKUs can block an otherwise valid order.

Inspect configurable and bundled products carefully. Parent and child items may represent different commercial or fulfilment concepts. Agree which lines become ERP order lines so quantities, discounts, and totals are not counted twice.

Compare amounts before transformation, after transformation, and after ERP calculation. Define whether each field contains a gross amount, a net amount, or a value in minor currency units. Small rounding differences need an agreed handling rule, while unexplained discrepancies require investigation.

Test guest orders, multiple currencies, discounts, partial fulfilment, cancellations, and refunds. Keep mapping rules versioned and review examples with the teams responsible for accounting and warehouse operations. A technically accepted order can still be operationally wrong.

6. Inspect cron, queues, and worker health

If jobs are created but never finish, follow the execution mechanism. Check scheduled task results, failed jobs, active consumers, broker connectivity, and worker restarts. Magento cron information is available in var/log/cron.log; compare it with connector and process manager logs.[4]

Adobe documents managing queue consumers through cron or an external process manager.[5] Confirm the relevant consumer and its configuration for your connector. Do not assume every ERP integration uses Magento's asynchronous API consumer; some run their own queues or external workers.

Monitor backlog size and the oldest waiting job. A growing queue can indicate inadequate throughput, while an old isolated job can indicate repeated failure. Inspect database locks, memory pressure, and downstream limits before adding workers, which can increase contention or duplicate processing.

Look for a repeatedly failing message that blocks later work in the relevant queue or partition. Isolate it through the connector's supported exception process, retain its evidence, and confirm that healthy jobs resume. Purging the entire queue can turn a recoverable backlog into missing orders.

7. Separate acceptance from completion

For Magento asynchronous APIs, an accepted request receives a UUID and enters a queue for later execution.[6] This acknowledgement does not establish that the requested business operation succeeded. Apply the same distinction when an ERP or middleware returns a job receipt.

Where Magento bulk or asynchronous endpoints are used, retain the bulk_uuid and inspect operation status and result messages. Adobe exposes status endpoints that distinguish completed, open, rejected, and failed operations, including failures requiring a change before retrying.[7]

Persist the ERP identifier and the verified outcome in your integration's tracking record. Avoid marking an order exported merely because the HTTP connection succeeded or the middleware accepted a message.

Inspect individual results inside batch responses. One accepted batch can contain operations with different outcomes, and retrying the entire batch can repeat successful work. Track completion per order, preserve error details, and select only the unresolved operations for the next recovery step.

8. Design retries that cannot multiply orders

A timeout leaves an uncertain outcome: the ERP might have committed the order before the response disappeared. Search by a stable external reference before replaying the create operation. Where supported, use a consistent idempotency key for the same intended operation; a new key on each attempt defeats duplicate detection.[8]

Include source identity and operation type in the key design. Creating an order and creating its refund are different intentions. Enforce uniqueness or equivalent duplicate protection at the receiving boundary; two workers can race past a simple “does it exist?” check.

Use bounded retries with increasing delays and jitter for suitable transient failures.[9] Respect provider limits and relevant Retry-After guidance, including supported rate limiting responses.[10] Send exhausted or invalid jobs to a visible exception workflow with an owner.

Choose which component owns automatic retries. Independent retries in the connector, middleware, and HTTP client can multiply traffic during an outage. Document the receiving system's duplicate protection guarantees and retention period; do not assume an arbitrary custom header provides idempotency.

9. Reconcile records across both systems

Compare eligible Magento orders against ERP records for a defined period, allowing for normal processing delay. Match stable identifiers first, then compare currency, amounts, line quantities, and lifecycle state. Total record counts alone can hide one missing order and one duplicate.

Repair a small, verified batch first. Confirm that recovery creates the intended records without repeating fulfilment, payment capture, or customer notifications. Keep unresolved differences visible until someone explains and resolves them.

Exclude intentionally ineligible orders according to documented rules. An ERP record without a Magento match might originate from another sales channel or a manual entry. Establish its source before treating it as a duplicate, importing it, or changing either system.

10. Make the fix observable and repeatable

Publish a short runbook covering eligibility rules, identifiers, common errors, retry limits, escalation contacts, and recovery steps. Monitor export latency, rejection rate, duplicate attempts, and acknowledgement failures. Alert on business outcomes alongside service availability.

Add regression scenarios for expired credentials, unknown SKUs, lost responses, and delayed acknowledgements. Give support staff enough visibility to identify affected orders and communicate realistic next steps, while technical owners retain responsibility for replay and reconciliation decisions.