The PO line I canceled in Cin7 kept a reorder alert quiet for three months

On July 30 I ran a diagnostic across our purchase order data expecting to find nothing. It found seven purchase order lines, spread over six POs, that Cin7 Core no longer knew about. Those seven lines touched five SKUs, two of which had been sitting at zero available since May 2.

I had removed one of those lines myself, back in April, after a supplier told me the item was gone for good. Ninety seconds of work in Cin7. I never thought about it again, and neither did anything downstream.

Nobody had been told. The alerting was running fine the whole time. Those SKUs just looked like they already had stock coming.

Why your system goes quiet when a PO is open

Any inventory layer worth running suppresses a low-stock alert when there's an open purchase order against that SKU. It has to. Without it, the moment you place the order you start getting emailed about the same product every day until the container lands. Six weeks of that and you have trained yourself to archive the whole folder unread.

So the rule is sensible: stock is on the way, we already know, stop shouting.

The rule depends entirely on the words "on the way" being true.

What actually happens to a PO line

Here is the sequence, and if you buy from more than a handful of suppliers you have lived it.

You raise a PO with eight lines. Two weeks later the supplier calls. One item is discontinued, another they can't get until October, and could you swap the third for the newer version. So you open Cin7 Core and edit the PO, and lines come off it. Nothing unusual about any of that. At our volume it happens most weeks.

Cin7 handles its own record fine. The PO now shows six lines. The problem is everything sitting downstream of Cin7, reading that PO through the API on a schedule.

A sync reads what the payload contains and writes it. It updates the six lines it can see. The two that vanished were never mentioned, so nothing happened to them. Absence is not an event. In our data they stayed marked ordered, indefinitely, and everything that reads that field kept treating them as stock on the way.

The whole bug is that boring, which is roughly why it survived twelve weeks.

Three things go wrong at once, and only one of them is loud

The reorder alert stops firing. This is the expensive one. The alert that gives you lead time worth of warning, the one that exists so you can raise a PO before you're empty, was being suppressed by a line that no longer existed anywhere in Cin7. Five SKUs in our audit. Two of them out of stock since May 2, which is close to three months of a silenced alert.

We do still fire a separate out-of-stock alert regardless of open POs, so those two didn't disappear entirely. But an out-of-stock alert only tells you the sale is already gone. The reorder alert was the one that mattered, and it never came.

On-order value goes fictional. The phantom lines carried $14,074 of inventory into our physical count valuation (Australian dollars, since that's what we buy in). Nobody treats that as a soft number. It lands in the balance sheet figure at count time, and anyone looking at total stock investment is looking at goods no supplier has any record of sending.

Days of cover reads long. Reorder math treats on-order quantity as arriving stock. Every SKU behind an orphaned line was being scored as healthier than it was, so it also sorted lower in the reorder queue, below products that genuinely needed less attention.

All of it traces back to lines nobody deleted on our side. From outside the business the only symptom was a customer emailing to ask when a product she'd wanted since early May was coming back.

The check to run this week

You don't need a diagnostic script for this. You need two lists and about forty minutes.

Pull every open PO line from whatever system sits between you and your buying, with the SKU and the outstanding quantity. Then pull Cin7's own on-order figure per SKU from product availability.

Any SKU showing outstanding quantity on an open PO line, where Cin7 reports on-order of zero, is a candidate.

Cin7 computes on-order from the lines it currently holds. If your side says 240 units inbound and Cin7 says none, the two records disagree about reality and Cin7 is the one that's right. Then look at each candidate's available stock. The ones sitting at or near zero are your live problem.

Two independent signals confirmed our seven were genuinely orphaned rather than a timing artifact. Cin7 read zero on-order for every one of them, and each carried a matching quantity change record from the date of the edit that removed it. If both line up, they're real.

If the query comes back empty, you've spent forty minutes proving your PO sync reconciles properly, which is a reasonable price for that.

Don't fix this the obvious way

The tempting fix is a one-liner: anything not in the incoming payload gets canceled. Do that and you will destroy real history the first time an API call returns a partial page.

Guards worth having before you cancel anything automatically:

• Never touch a line marked received or part-received. That's physical stock that came through your door. If it disappears from Cin7, log it as an anomaly for a human, don't quietly delete it.
• Refuse to act if the incoming payload has zero overlap with what you hold. Eight simultaneous deletions is a fantasy; a failed API call is a Tuesday.
• Cap it. If a single pass wants to cancel more than half of a PO's open lines, stop and flag it.
• Soft-cancel rather than delete, so the line is still visible with its history rather than gone.

We also learned to compare against the line set as it stood before the update loop ran, not after. Our first version re-read the local lines afterward, which made every incoming SKU present by construction and left the overlap guards mathematically unable to fire. It looked correct and tested clean, because it never triggered.

Where we landed

Stocura now reconciles the local line set against what Cin7 reports on each PO sync. Removed lines are soft-canceled behind those guards, and they show on the PO page struck through with a badge, so the change is something you can see rather than something you infer. Supplier changes and added lines get logged the same way. Quantity, status and line changes made in Cin7 flow through within about three hours. Not instantly. Three hours is the honest number and I'd rather give it.

Per-SKU on-order now refreshes when any edit moves the quantity, not only when a line is received, so reorder decisions stop running on figures up to a day stale.

The part I keep thinking about

Every operator I know tests whether their alerts fire. Almost nobody tests the conditions under which their alerts stay quiet, and quiet reads like good news for as long as you let it.

Twelve weeks is what that cost us on two products. Go pull your open PO lines against Cin7's on-order figures before you do anything else today.