The Order That Closes Itself
A purchase order that has been fully paid for a week closes itself at one in the morning. Closing writes two facts nobody observed — that it was delivered, and when — so the window is worth setting deliberately rather than accepting.
Nobody closes a purchase order. It is the last step of a process that ended weeks ago, and the people who could do it have moved on to the next order.
So the system does it. Each morning it looks for orders that have been fully paid, are not already completed or cancelled, and whose payment landed longer ago than your organisation's window — seven days unless you have changed it. Those are closed.
What closing writes
Three fields on the order and one on the quotation behind it. Two of the three are worth pausing on, because they are assertions rather than administration.
| Field | Set to | Is this observed? |
|---|---|---|
| Status | Completed | Yes — this is the administrative close, and it is what the sweep exists to do. |
| Shipping status | Delivered | No. It is inferred from the order having been paid in full. |
| Delivery date | Today, if it is empty | No. An order with no recorded delivery date gets the date it was closed. |
| The quotation | Completed | Yes — the sourcing document that produced the order is finished with. |
Payment is the trigger, delivery is the inference
The reasoning is sound: an organisation that has paid an invoice in full has, in the overwhelming majority of cases, received the goods. But the sweep is driven by the payment record, not the receipt record, and it writes a delivery status and possibly a delivery date on that basis. If your delivery dates feed a supplier performance measure, the ones stamped by this sweep are the date the order closed rather than the date anything arrived.
The window, and the setting that switches it off
The window is a per-organisation number of days after payment. Seven is the default. Setting it to zero disables the sweep for your organisation entirely, and orders then stay open until somebody closes them by hand.
What the window is really buying you is a period in which a discrepancy can still surface — a short delivery discovered on unpacking, a credit note from the supplier, an invoice that turns out to cover two orders. Closing an order does not make any of that impossible to deal with, but it does move the order out of the working set that people look at.
You pay on receipt and unpack immediately
Seven days is generous
The default already gives you a week after payment. Shortening it to two or three keeps the open-order list genuinely current.
You pay in advance and receive later
Lengthen it, or switch it off
This is the case the default suits worst. An order paid up front and delivered in six weeks would be closed as delivered before it shipped, so either the window has to exceed your lead time or the sweep should be off.
Delivery dates feed a supplier scorecard
Switch it off, or record deliveries properly
A stamped date is a closure date. If on-time delivery is being measured, the measure has to come from receipts rather than from the sweep.
Nobody closes orders and the list is unusable
This is exactly what it is for
Leave it on. An open-order list containing a year of finished business is worse than a few orders closed slightly early.
The sweep closes what payment finished. It cannot see what was never received.
How the sweep behaves when something goes wrong
One order failing does not stop the run. The failure is reported against that order and the sweep continues to the next one, then reports how many it closed out of how many were eligible, across how many organisations. That is the right shape for a nightly batch — a single problematic record should not leave a hundred orders open — and it does mean the failures are in the run's output rather than raised as an alert.
Closing also raises an event, and only if your organisation has an active rule listening for it. That is how an auto-closed order can trigger something else — a notification, a supplier update, a record elsewhere — without the sweep needing to know anything about what you have configured.
Closing on what actually happened
The sweep is small and does its job. What would make it more accurate is driving it from receipts as well as payments, and being explicit about what was inferred.
Close on receipt as well as payment
An order fully received and fully paid closes on the later of the two, so a prepaid order is not marked delivered before it ships.
Mark an inferred delivery as inferred
A delivery date stamped by the sweep flagged as such, so a supplier performance measure can exclude it rather than treat it as observed.
A pre-close list
The orders due to close tonight, visible today, so anything that should not be closed can be held back before it is.
We publish scope, not dates.
Scope order closureFour questions to ask about automatic closure
What triggers a close?
A good answer sounds like
A named condition and a window.
What ours actually is
Full payment, plus your organisation's window of days since the payment landed. Seven by default.
What does closing write?
A good answer sounds like
A named list.
What ours actually is
Status completed, shipping status delivered, a delivery date if one is missing, and the linked quotation completed.
Can I switch it off?
A good answer sounds like
Yes, per organisation.
What ours actually is
Yes — set the window to zero and the sweep skips your organisation entirely.
What happens if one order fails to close?
A good answer sounds like
The rest still run.
What ours actually is
The failure is reported against that order and the sweep continues, then reports how many closed out of how many were eligible.
Our take
Automatic closure is a housekeeping feature and it earns its place, because an open-order list nobody has pruned is a list nobody reads. The design decision worth examining is which event it keys on. Payment is a reliable signal that a transaction is finished and a poor signal that goods arrived, and closing writes a delivery status and sometimes a delivery date on the strength of it. For most organisations, most of the time, that inference is correct and the tidiness is worth more than the precision. For anyone paying in advance, or measuring suppliers on delivery dates, it is the wrong signal and the window is the wrong lever — the honest answer there is to switch it off and close on receipts instead.
What AWRA OpsHub does today
- A nightly sweep at one in the morning closing purchase orders that are fully paid and older than your organisation's window, running once across servers and never overlapping itself.
- A per-organisation window in days, defaulting to seven, with zero disabling the sweep for that organisation entirely.
- Orders already completed or cancelled excluded, so the sweep never touches a finished record.
- Closure setting the order to completed, its shipping status to delivered, its delivery date where none was recorded, and the linked quotation to completed.
- An event raised on closure, dispatched only where your organisation has an active rule listening for it.
- A failure on one order reported and skipped rather than halting the run, with a summary of how many closed out of how many were eligible.
- The same procurement settings record carrying the receiving and payment-matching tolerances, so the whole purchasing policy is configured in one place.
More we can add to your workspace
- Closure driven by receipts as well as payment, so an order paid in advance closes when the goods arrive rather than a week after the money left.
- An inferred delivery date marked as inferred, so supplier performance reporting can distinguish an observed arrival from a stamped closure.
- A list of orders due to close tonight, visible in advance, so one that should stay open can be held back.
- A per-supplier or per-value window, so a large order gets longer to settle than a stationery purchase.
- A closure summary to whoever owns purchasing, rather than the run's own output.
- Reopening a closed order as a first-class action with a reason, for the credit note that arrives after everything looked finished.
Where we point you to a specialist
- We will not close an order that is not fully paid. A partially paid order is an open commitment on both sides, and tidying it out of the working list would remove it from view at exactly the point somebody still owes somebody something.
- Choosing your closure window is an operational judgement about how long a discrepancy takes to surface in your business, and it stays yours. Seven days is a starting position rather than a recommendation, and for anyone paying in advance it is the wrong one.
- Where a funder or an auditor requires evidence that goods were received before an order is treated as complete, that requirement governs and payment is the wrong trigger. We will close on receipts instead; the standard is theirs to state.
Closing on the later of receipt and payment is the contained piece here — both dates are already recorded, and it removes the one inference this sweep currently has to make.
Check your window against your payment terms
The default assumes you pay after you receive. If you pay before, the setting is working against you, and it is one number to change.
Talk through purchasing settingsFrequently asked questions
Why does the sweep key on payment rather than delivery?
Because payment is the most reliable single signal that a transaction is finished — an organisation that has paid in full has usually received the goods and settled any dispute. It is a good proxy and it is still a proxy, which is why closure writes a delivery status that nobody observed. For businesses that pay in advance, the proxy fails in the obvious direction.
Will an order be marked delivered even if nothing arrived?
If it was paid in full and left open past your window, yes. The sweep sets the shipping status to delivered and stamps a delivery date where none exists. The safeguard is the window itself: the point of having one is that an unreceived order should be noticed inside it. If your lead times exceed the window, the window is wrong.
How do I stop this happening?
Set the closure window to zero for your organisation and the sweep skips you entirely, leaving orders open until somebody closes them. That is a real position for a business with long lead times or with supplier scorecards driven by delivery dates, and it costs you an open-order list that somebody has to prune.
Does closing an order stop me handling a later credit note?
It does not make it impossible, but it moves the order out of the working set people look at, which is usually where the problem starts. Reopening a closed order as a deliberate action with a reason is on the list above; today the practical answer is that the credit note is handled against the supplier rather than against the order.
Can different suppliers have different windows?
Not today — the window is one number per organisation. A per-supplier or per-value window is a reasonable request and is named above, and it matters most for businesses whose purchasing spans stationery and capital equipment on the same settings.
Does anything happen when an order closes automatically?
An event is raised, and it is dispatched only where your organisation has an active rule listening for it. So an auto-closed order can trigger a notification, an update to a supplier record or anything else you have configured, without the sweep needing to know what any of those are.
