Reconcile orders with your ERP

For most Mittelstand companies the ERP is the system of record for the order once it exists. That makes the boundary between the two systems the place where reconciliation problems live — and there are only three fields that matter at that boundary.

The three references

Three numbers, three owners. Every reconciliation question is answered by one of them, and confusing two of them is how a payment gets matched to the wrong order.

customer_order_number is the one your customer cares about. Their AP department matches your invoice against their PO. An invoice without it is frequently returned unpaid, and no amount of your own order numbering helps.

external_ref is the one your colleagues care about. When Innendienst has the ERP open and the shop order in front of them, this is the field that links the two screens.

Acknowledgement is the handover

acknowledged_at is the moment the fulfilling system takes ownership. It is stamped when the ERP confirms the order and writes back its own reference.

After it, the order is frozen here: addresses, buyer details and references can no longer be edited, because the ERP is now planning against what it received. A tenant can allow late modification, and some ERPs tolerate it — but understand what you are turning on before you do.

Where to look when an order did not arrive

1. The order's History tab. Every transition is here with its actor. If the placement event is present and nothing follows, the order was placed correctly and the problem is downstream.
2. Integration Studio › Integrations › Runs. This is the screen that answers "the order never reached SAP" — see Monitor your syncs.
3. The event itself. Integrations react to the placement event, not to a row appearing. An order created in pending awaiting approval has not been placed, and a consumer that reacts to the wrong signal will fulfil orders nobody approved.

The double-processing trap

An order's life is published twice on purpose: as named events for each thing that happens, and as a raw audit feed of every transition.

If you are debugging duplicated orders in your ERP, check this before anything else. It is the most expensive configuration mistake at this boundary and it looks like an ERP problem from the ERP end.

The two doors back in

An external system changes an order in exactly two ways:

• Acknowledge — once, carrying the ERP's reference.
• Create shipment — as often as there are deliveries, carrying positions, quantities, carrier and tracking.

Everything else — the buyer, the addresses, the totals — is fixed by the order. If your ERP wants to change the totals on an order, that is not a reconciliation problem, it is a disagreement about what was sold, and it belongs in a conversation with the customer.

A weekly reconciliation

Five checks, in this order:

1. Unacknowledged orders older than your turnaround. Should be zero.
2. Orders with no customer_order_number where your customers require one. Fix the checkout, not the orders.
3. Order count for the period against your ERP's count for the same period. A gap of one is one order; a gap that grows daily is a broken integration.
4. Delivered but unpaid — fulfillment_status = fulfilled, payment_status = open — against your ERP's open items.
5. Shipments recorded here against delivery notes issued there. A gap means the warehouse is shipping outside the platform.

Numbers 3 and 5 are the ones that catch silent failures. A daily alarm on number 1 catches them faster.

Next

• Orders that get stuck — the per-order diagnosis.
• Sync errors — when the integration itself is failing.