Created is not released: credit holds in automated order entry

Your integration is measuring the wrong thing

Most order entry automations define success as a write. The workflow parses the incoming order, maps the lines, posts them to the ERP, gets an order number back, and marks the run green. Dashboards get built on that number. Nobody asks what the order number means.

It means a record exists. Whether anything ships is a separate question, answered somewhere else.

A sales order can sit in a perfectly healthy ERP for a week without moving, because finance put the account on credit hold. The record is complete. The lines are correct. The picking release never fires. And the workflow that created it has already sent an order confirmation and moved on.

Where the hold actually fires

The timing is what makes this hard to see.

Some systems evaluate credit when the order is saved. You post, you get a blocked status straight back, and an integration that reads the response can react to it. Others wait until a delivery note is created, or until picking release, or until the nightly batch that builds the next day's pick lists.

In those later cases the order looks entirely normal for a day or two. It has a number, a date, a delivery address. Everything an integration would think to check is present. The block arrives afterwards, in a different module, triggered by a process nobody wired the workflow into.

An automation that only inspects the order at the moment it creates it can only catch the first kind of hold.

The limit is a moving number

Credit exposure is not a field on the customer. It is a calculation, and it moves every day without anyone touching it.

Open invoices count against it. So do orders that are entered but not yet shipped, and deliveries that went out but have not been invoiced. Depending on the system, incoming payments that have not been posted yet do not count at all, which means the customer has paid and the exposure has not budged.

An order that cleared on Monday can be blocked on Wednesday because two invoices crossed their due date, or because the same customer placed three more orders in between. Automated entry contributes to this directly: a workflow that posts forty small orders in an hour consumes headroom faster than a human order desk ever did.

A check performed once, at intake, is valid at intake. It tells you nothing about the day the goods are meant to leave the building.

Somebody outside your company may own the number

If you carry trade credit insurance, the insurer sets the limit. They can reduce it or withdraw it without notice and without any internal change on your side. A customer who has paid on time for eight years can turn up Monday morning with a fraction of the cover they had on Friday.

So a workflow that read the limit once and stored it in a lookup table is working from a number that has been retired. It will approve orders the ERP is about to block, and it will keep doing so quietly.

Group structures break per-account checks

The second failure point is which entity the limit belongs to.

A hospital group orders on six account numbers, one per site. The credit limit sits on the group. Check each account individually and all six pass; the combined exposure is well over. Retail chains and buying groups behave the same way, with invoices routing to a central settlement entity while goods go to thirty delivery points.

The incoming order carries a site-level account number, so that is the level a workflow naturally checks. The level that matters is one step up, and it is not in the document that arrived.

Payment terms are a separate gate

Credit limits are not the only reason an order stops.

Prepayment customers have no limit problem at all and still must not reach the pick face before funds arrive. Accounts frozen at a dunning stage are blocked regardless of headroom. Both live in different fields from the limit amount, often on a different tab of the customer master.

A check that reads only the exposure figure lets them through. The result is stock shipping to an account that credit control has been chasing for a month.

What retries do to a blocked order

If the workflow has no state for "held", it will usually classify the hold as a failure. The standard response to a failure is a retry, and a retry posts the same order again.

Now there are two held orders for the same goods, consuming double the exposure between them, which makes it likelier that the customer's next legitimate order gets blocked too. If somebody later releases one and misses the other, the shipment goes out twice.

The confirmation is where the damage happens

A held order is a normal event. Credit control did its job. Somebody now has to make a commercial decision, and that is fine.

The damage comes from the confirmation that went out before anyone knew. Commercially, an order confirmation is an acceptance of the offer. Your customer plans around it. In hospital supply that plan includes procedure schedules; in distribution it includes a commitment your customer has already made to their own buyer.

Told on day one that an invoice is overdue, a customer can pay it and have goods moving the same week. Told on day six, they have lost six days and so have you.

What we build instead

Three outcomes at intake, not two: created and released, created and held with a reason, rejected. The middle state needs somewhere to go or it disappears.

Read the status back. After posting, fetch the order again and inspect the block indicator rather than inferring health from the HTTP response.

Let the ERP do the assessment. Pulling the limit and the open items yourself and doing the subtraction produces a second number, and it will diverge from the ERP's the moment the two disagree about which documents count.

Tie the outbound message to the state. A held order gets an acknowledgement of receipt, not a promise of delivery.

Route held orders to a named person with a deadline. A report someone could open is not a route. The notification has to reach somebody authorised to decide.

Re-check before shipment, because the exposure has moved since intake.

Never set a blanket release flag in the mapping. That flag exists in most systems, it makes held orders disappear during testing, and it survives into production more often than anyone admits. If certain accounts genuinely bypass the check, define which ones and write it down.

Redefine done

The number on your dashboard says how many orders the workflow created. Put a second number next to it: how many of those orders shipped.

In a normal month the two sit close together. The gap is where this problem lives. Until somebody puts that gap on a screen, the only person reporting it is the customer, and they call six days late.