Orders Are Not Reaching the ERP: Where to Start

The sentence "orders are not reaching the ERP" usually points at the wrong place. People assume the connection dropped, when in most cases the order was received and simply could not be written. That distinction decides where you look.

An order that could not be written is not lost, but it will not write itself either. It waits until the cause is found and cleared, and while it waits the warehouse does not see it, no invoice is issued and nothing ships. The channel's delivery clock, meanwhile, keeps running. So the first job is not to rescue orders one by one but to narrow down the cause.

The two-minute split: reading or writing

Before anything else, ask this: does the order appear in the panel?

• If it does, the connection is working and the problem is on the write side.
• If it does not, look at the read side.
• If it does not appear in the marketplace seller panel either, it may not have been released to you yet. On some channels an order reaches the seller only after payment is verified.

Every check made before drawing this line is wasted time. Trying to fix a write-side fault by renewing access details means finding the same fault in the same place the next day.

The order appears in the panel but is not written to the ERP

Almost every write-side fault comes from one place: the record does not satisfy a rule in the ERP. The ERP refuses it, and if the integration does not show you that, the order waits silently. The headings below are in order of frequency.

Customer and account records

This is the most common cause. Writing an order in an ERP requires a customer account. If a marketplace customer is ordering for the first time and no account exists, the write stops. Some setups use one collective account per channel, others open one per customer; either way, if the rule is undefined nothing is written.

Orders requesting a corporate invoice are finer work: if the trade name, tax office and tax number do not arrive in the shape the ERP expects, no account can be opened. The same tax number arriving twice under different trade names is another common blockage.

Check: can a counterpart be produced on the ERP side for this order's customer, and if not, which field is missing?

Product code counterparts

If a line item is not defined in the ERP, the record cannot be written. This usually happens with newly added products, renamed products, or codes that were corrected by hand: live on the marketplace, absent in the ERP or present under a different code.

Two details make it harder. The first is variant level: if the parent product is matched but the colour and size breakdown is not, only some sizes get stuck and the pattern looks random. The second is extra lines inside an order; a campaign gift or an item coming out of a bundle needs its own code in the ERP. How matching is built is covered in matching products by SKU and barcode.

Check: do all line items exist in the ERP, and is matching at variant level?

Mandatory fields

If a field the ERP treats as mandatory arrives empty, the record is refused. The usual suspects are tax details, payment type, carrier definition, warehouse code and order type. Orders requesting a corporate invoice carry more fields, so faults concentrate there; what an invoice is issued from is the subject of marketplace invoicing and ERP integration.

Check: which fields does the ERP treat as mandatory for this order type, and do they all arrive from the channel?

Carrier and warehouse definitions

The carrier is usually chosen by the channel. When the channel changes its contracted carrier or adds a new one, a carrier name with no counterpart in the ERP arrives and the write stops. The same applies to warehouses: if it is not defined which warehouse fulfils the order, the write does not complete. How the carrier side is set up is covered in carrier integration.

The symptom is unmistakable: if only orders carrying one particular carrier get stuck, do not look anywhere else.

Split packages

When one order is split into several packages, a setup that follows the order number either writes missing lines or produces the same record twice. Both surface at month end during reconciliation, and at that point working out which line went where takes days.

Check: is the number being followed the order number or the package number?

The ERP is not answering right now

During maintenance, a backup, a period close or a temporary access problem, the ERP will not accept writes. This is not a rule-related fault and it passes on its own. What matters is that orders arriving in that window are not lost: the record waits with its reason and is retried once the problem clears. Find out whether that behaviour exists during onboarding, not during the incident.

The order does not appear in the panel either

Reading may have stopped silently

On the order side a stoppage announces itself in one way only: the count drops. A channel that was flowing yesterday has produced nothing today, and no red marker appears anywhere on screen. To tell that apart from an absence of sales, compare against the marketplace seller panel; if the order sits there and not with you, reading has stopped. If the channel's last order pull is on record, you do not even have to make that comparison.

The permission scope may have changed

A connection does not close all its doors at once. When the right to read orders lapses, stock and price sends can carry on; the panel looks ordinary and only the order list stays empty. Narrowing the permission scope on the seller account, or changing the user who created the connection, produces the same result. So it should be on record who connected with which rights; that is the first place to look when this happens.

Date and status filters

Some setups only collect orders in certain states. When a status definition changes on the marketplace side, or the channel adds a new state, orders outside the filter never appear at all. If you do not know what the filter is, find that out first; that single question sometimes ends the search.

A third picture: written, but written wrong

Less frequent than an order not being written at all, but more expensive, because it takes weeks to notice. Three symptoms are familiar: a line present in the order is missing in the ERP, the same order is written twice, or the carrier and payment type land on the wrong counterpart in the ERP.

The first two usually come from split packages. The third comes from a gap in the mapping tables: no counterpart was defined between the name the channel uses and the code the ERP expects. That gap widens once cancellations and partial refunds arrive; the whole flow is covered in order cancellation and partial refund workflow.

The fastest method: line up the failures

If no orders are landing, look at the connection. If some land and some do not, the connection is sound and you are looking for a shared attribute. Take the last five that failed; put customer type, payment type, carrier, products and package count side by side, and the common field almost always shows itself at first glance.

The short route from symptom to cause runs like this:

• No orders from any channel today: read side, most likely the connection or permissions.
• Only one channel quiet: that channel's access details or status filter.
• Only corporate-invoice orders stuck: mandatory fields and the customer account rule.
• Only orders containing new products stuck: product code counterparts.
• Only multi-line orders stuck: split packages.
• Only one particular carrier stuck: the carrier definition.

The durable fix: end silent failure

The real problem is not that an order could not be written, it is that nobody noticed. A record that fails should sit in a list with its reason, that list should raise an alert when it is not empty, and the record should be retried once the reason is cleared. Add last-run time per channel and everything above stops being a fault hunt and becomes a two-minute daily check.

If you are moving to a new setup, put the same discipline in place before handover. While the system reads only for a while, you see how many orders would fail and why; the method is described in shadow mode integration testing. For the twin fault on the stock side, see stock not updating on the marketplace.

In Bulutegra, when an order cannot be written to the ERP the record is not lost; it waits on the system health screen with its reason and is retried once the problem is cleared. Channel monitoring runs continuously, so a channel that goes quiet raises an alert and a notification reaches your phone. The whole panel is described on the Why Bulutegra? page, or you can request a demo.