Nobody is cheating. Somebody is winning.

In every constrained order book, someone eventually learns to jump the queue using nothing but standard functionality. Companies discovered this decades ago – and the walls they built to stop it are quietly costing them more than the problem ever did.

It is not an error. It is an asset.

The most valuable object in many order books is a sales order that will never be delivered.

Created eighteen months ago. Still open. Nobody has closed it – and that is not negligence. Your most experienced customer service specialist knows exactly what that order is worth, and they are not going to explain it to you, because from where they sit they are not doing anything wrong. They are doing their job. Getting their customers supplied. Using nothing but standard functionality and a very good understanding of how the queue works.

This article is about that order, the queue it exploits – and what your organisation gave up, years ago, to defend it.

Every prioritisation ends in FIFO

Modern order promising gives you many ways to express commercial intent. Customer priority. Channel. Allocation. Supply protection. Advanced ATP extended this enormously – you can encode a genuinely sophisticated policy.

But every scheme eventually runs out of criteria. When two requirements are equal on everything you declared, something still has to decide which one gets the last pallet. That final tiebreaker is almost always a date: order creation date, item creation date, requested date.

This is not a design flaw. A deterministic tiebreaker is exactly what you want.

The problem is what happens next. The moment a date decides who gets supplied, that date stops being a record and becomes a currency. And in any company with real operational freedom – freedom to create deliveries first for one order rather than another, to influence supply assignment, to change an order – someone eventually notices that the currency is spendable. (We have written before about how much depends on who reaches the delivery step first, and how Supply Assignment changes that game: see our article on Supply Assignment (ARun).)

Bypassing the queue

Most of the order book assumes there is only one door: the queue, oldest date first, everyone waits their turn. There is a second door. It has no line, because almost nobody knows it is there.

Three specific ways to use that gate:

Read those three in order and something uncomfortable emerges: each pattern defeats the standard remedy for the one before it. This is not a defect you close once. It is an escalation ladder – and the people climbing it are usually your best employees.

The golden order: a trick sitting on a trick

The patterns above get you into the queue once. The really valuable discovery is that an old order can be harvested again and again.

It works like this. The old order, thanks to its age, wins a confirmation. But the confirmation was never meant for that order – it was meant to be moved. During the day, the specialist rejects the old item, which releases the confirmed quantity; confirms the order that actually needs it; then removes the rejection again. By evening, the old order sits in the order book exactly as before – unrejected, undelivered, and still carrying its ancient timestamp.

Tomorrow it wins again.

This is why we call it a golden order in our practice: it is not a one-time exploit but a renewable resource. A well-tended golden order is a permanent private siphon on constrained supply – a season ticket to the front of the queue that renews itself every night. And every step in the cycle is a routine, permitted transaction: a rejection, a confirmation, an un-rejection. Three keystrokes that no report will ever flag.

The cycle is most powerful in companies where confirmation and delivery are loosely coupled – where whoever reaches the delivery step first wins, regardless of what the availability check decided. If that describes your process, our article on Supply Assignment (ARun) covers that race in detail, including the classic case of a delivery created first for a different order than the one the confirmation belonged to.

There are more patterns than the ones described here. We have found several others in practice, and I am not publishing those. What is published is enough to establish the point – and the point was never “here are some tricks.” The point is that this class of problem cannot be closed by tightening rules, because every rule creates the conditions for the next pattern.

Nobody is cheating

It is tempting to treat this as misconduct. That would be both wrong and useless.

Every action described above is a permitted transaction, performed by an authorised user, on a real customer requirement. You asked customer service to fight for their customers. You gave them a system with a queue and a degree of freedom. You never told them the queue was load-bearing.

A specialist who works out how to get their customer supplied, inside standard functionality, is behaving exactly as the organisation has incentivised them to behave.

No incident, no fix

Here is what makes this problem different from most supply chain problems: it produces no incident.

Every rule was followed. Every document is valid. Nothing appears in exception reporting, because there is no exception. A late shipment triggers an escalation; a biased queue triggers nothing. Problems that produce incidents get fixed. Problems that produce no incidents get processed around – and then the workaround cements.

The quiet costs run for years. When several regional teams compete for the same constrained supply and only some of them know the game, your allocation outcome is decided by back-office tenure – a policy no executive team would ever sign off, enforced faithfully by the system every day. Declared policy and effective policy diverge exactly where it matters: at the margin, in shortage. And your demand signal carries a bias nobody models, because part of the order book is a statement about user fluency rather than about the market.

Why publish this now

For years, describing these patterns publicly would only have spread a problem that had no good answer. That has changed: solutions now exist that make these exact patterns irrelevant – SAP has shipped functionality addressing the root cause, and mitigations we have developed in our own practice close further seams. That is a narrower claim than “the problem is solved,” and I will come back to the difference. But it is enough: once a specific manipulation can be neutralised, describing it stops being a risk and becomes overdue transparency.

Because silence protects exactly the wrong thing. Unpublished, the knowledge stays where it is: with the people who already hold it. Your veteran teams keep the advantage. Your newer teams keep losing and never learn why.

The walls companies built instead

With no clean fix available, the companies that half-discovered these patterns reached for blunt instruments:

They removed the freedom – central scheduling, no discretionary deliveries, no manual reassignment. Customer service became order entry.

They locked the documents – no material changes, no reactivating rejected items, every change routed through days of approval.

They aged out the old – old requirements quietly de-prioritised, which punishes genuine backlog and rewards keeping the order book artificially young.

Each was rational. Each traded responsiveness for integrity. And the trade was never revisited: the restriction outlived the people who built it, and today the answer to “why can’t customer service change an order item?” is simply “that’s our process.” Nobody remembers it was defending a tiebreaker.

So the real cost isn’t the manipulation – it’s the rigidity poured around it like concrete. And rigidity looks like discipline, so nobody counts it.

What you actually delete

Your customer service knows things your system does not. Customer A said this morning they can wait three weeks; Customer B is about to test the product and publish a review. One of them should get the last pallet – and it is not the one your master data prefers.

That knowledge is situational, perishable within days, and lives only in the head of the person who took the call. A customer classification or an allocation table cannot hold it. Lock the order book and you don’t control that judgement – you delete it. Or, more often, you push it off the record: the exception gets made anyway, as a phone call to the planner that nobody can audit or learn from.

To stop a few people moving supply for the wrong reasons, companies stopped everyone from moving it for the right ones.

And the walls travel

It gets expensive on the day you redesign. The restrictions don’t stay behind – they travel as requirements. The as-is workshops write them down faithfully and rebuild them on the new platform, often at real custom-development cost, and nobody asks the one question that matters: what does this restriction defend against – and does the new platform still have that weakness?

A requirement list is partly an archaeology of old defences. Migrate it unexamined and you pay three times: to rebuild the wall, to live with its rigidity, and in the standard functionality it now blocks.

So the process and architecture review belongs before the project commits – while every restriction can still be made to name its threat. The ones guarding yesterday’s queue retire on the spot; S/4HANA 2025 alone retires a whole family of them. The ones guarding real threats stay – as conscious decisions, not inherited concrete.

What changed in S/4HANA 2025

SAP has now addressed the root of this directly, in the S/4HANA 2025 on-premise documentation: SAP Help Portal – S/4HANA On-Premise 2025.

The mechanism is simple and precisely aimed. Until now, the queue sorted on dates that documents happened to carry – order created, item created. The new functionality introduces a separate prioritisation date that the system maintains automatically. By default it equals the creation date, so for an honest order book nothing changes. But every time a critical change happens, the date moves:

Un-reject an item, or change its material – the prioritisation date resets. The item may be a year old; the demand is new, and now the queue knows it. Patterns one and two die here.

Increase a quantity – the date is kept at schedule-line level, so the order splits its seniority: the original quantity keeps its old, high priority, while the added delta gets a new date and joins the back of the queue. Pattern three – the one no standard setting could touch – dies here.

Notice what this is: the queue finally sorts on when the demand arose, not on which document it is attached to. That is fairness by construction. Adding an item, reactivating one, increasing a quantity – these become ordinary changes to a sales order, which is all they ever should have been. And a golden order loses most of its shine, because the easiest things to harvest are gone.

Two things are worth saying plainly.

First, this capability is genuinely hard to find. It is not filed under anything containing the word FIFO, and it is not what anyone would search for. If your company is on a recent release, there is a fair chance you already own the answer and do not know it.

Second – and this is the point of the whole article – the feature is only half the value. The other half is everything you can now dismantle.

The fix is not the finish line

One thing should be said honestly, because overselling it would undermine everything above: the current version of this functionality closes the patterns described here. It does not close the class.

There are other patterns. We keep finding new ones in practice – not because anyone is inventing them maliciously, but because that is the nature of the problem: wherever a sequence decides who gets supplied and users retain any freedom at all, ingenuity finds the seams. Expecting one release to end this permanently would be repeating the original mistake – believing the queue can be defended once and for all by a single rule.

What actually works is treating fairness as something you maintain, not something you install. In our practice, the remaining gaps are closed with small, standalone additions to the standard – clean-core by design, each targeting one specific seam. None of them is a project; together they keep the sequence honest as new patterns surface.

I am not going to publish those patterns, for the same reason I stopped at three above. But if you are responsible for a fulfilment process and want to know whether they apply to yours, that is a conversation we are happy to have – in that setting, with names on the door, the details serve the right side.

Controlled freedom: the redesign this enables

If your restrictions exist to defend the queue, and the queue now defends itself, the restrictions are pure cost.

That is not a software upgrade. It is a mandate to redesign how customer service works with availability:

Give the freedom back. Let customer service add items, change materials, adjust quantities, clean up the order book – because none of it converts into queue position anymore. The approval workflows built to guard the sequence can go. The situational judgement you deleted comes back into the system, where it can be seen, rather than into a phone call, where it cannot. And the response time your customers feel comes back with it.

Keep the governance central. Fairness stops being a training document and a shared understanding. It lives in the sequencing logic, uniformly, for every team – including the ones that never knew the game existed. Regional equality by construction, not by vigilance.

Re-read your demand signal. An order book that people were afraid to touch is full of noise: items kept alive for their timestamps, quantities parked “just in case,” rejections never processed. When touching the order book becomes safe again, the order book becomes true again – and everything downstream that consumes it, from planning to allocation, gets sharper.

Most companies will not make this move, because the restrictions don’t hurt enough on any single day to trigger a project. They just cost a little, every day, forever. The companies that do make it will run customer service organisations that are simultaneously freer and fairer than their competitors’ – and will quietly wonder why everyone else still routes an order change through a three-day workflow.

Once a manipulation is mitigated, it is no longer a manipulation. And once the queue defends itself, the walls around it are just walls.