The Other Side Can Close Your Order
A supplier signed into your portal can mark your purchase order closed. There are four conditions on it, and the fourth — that you have already paid in full — is what makes the whole thing safe.
Our take
Letting the other side close your paperwork sounds alarming until you look at when it is allowed. A supplier may close an order only when it is theirs, only when it is not already closed, and only when you have paid it in full — which means the action can never be used to close an order with money still owed on it, and can never affect a payment decision, because the payment has already happened. What it does is finish a record that both parties agree is finished, at the moment the party who has been chasing it knows it is done. That is a genuinely good use of a portal. The one thing worth improving is attribution: the closure runs through the same function your own nightly sweep uses, so what the record afterwards says is that the order was closed — not that your supplier closed it.
Your supplier has been paid, the goods went weeks ago, and the order is still open on both sides. They can see that. Now they can do something about it.
What a supplier can do in the portal
Four actions on a purchase order, all of them on the same rate limit, all of them guarded by the same ownership check.
| Action | What it does |
|---|---|
| Accept | Marks the order as accepted by the supplier, and can carry your own custom fields for purchase orders. |
| Reject | The other answer, for an order the supplier will not fulfil. |
| Update shipping | Sets the shipping status, so the buyer learns where the delivery is from the party who knows. |
| Close | Marks the order completed — available only on an order that has been paid in full. |
The first three are unsurprising and are what a supplier portal is for. The fourth is the one worth reading carefully.
Four conditions, checked in order
-
There has to be a signed-in supplier
Refused otherwise. No anonymous route reaches this.
-
The order has to be theirs
The order's supplier must be the signed-in supplier. This is the same ownership check that guards every action in the portal, and it is an equality rather than a permission.
-
It must not already be closed
A completed order is refused with a message saying so, rather than silently doing nothing.
-
It must be fully paid
The condition that carries the whole design. An order with any balance outstanding cannot be closed from the supplier side, whatever else is true.
Why the payment condition makes this safe
Closing an order is an administrative act, and the risk in letting an outside party perform it is that closure might influence something financial — an eligibility check, a matching decision, a payment release. Because the order must already be fully paid, there is no such decision left to influence. The supplier is finishing paperwork for a transaction that is over, which is exactly the case where the party with the best information is the one on the other side.
The party who knows it is finished is often not the party holding the file.
It runs the same closure your own sweep does
A supplier closing an order and your own nightly housekeeping closing one call the same function, which sets the order completed, the shipping status delivered, the delivery date where none was recorded, and the sourcing document behind it completed. It also raises an event, dispatched only where your organisation has a rule listening for one.
Sharing the implementation is the right decision — two closure routines would drift, and the second one would be the one that forgets to close the quotation. What it costs is that the resulting record does not distinguish who decided. An order closed by your supplier and an order closed by a scheduled sweep look identical afterwards.
For most purchasing that is immaterial. Where it matters is a dispute about when an order was considered finished, and that is the case for wanting the actor recorded — which is a field rather than a redesign, since both callers know perfectly well who they are.
The wider point about portals
The instinct with a supplier portal is to make it read-only, because the other side is outside your control and writes feel dangerous. The better question is which facts the other side knows first.
- Whether they accept an order — they know, and you find out by waiting or by phoning.
- Where the delivery is — they know, and your own tracking is an inference from a promised date.
- Whether the transaction is finished — they know, and it usually sits open on your side until somebody tidies.
- What was actually delivered — you know, and this is the one that stays yours, because a receipt is your record of what arrived.
The portal here lets the other side write the first three and keeps the fourth. That division is the useful principle: give away the facts they own, keep the ones you have to verify.
What AWRA OpsHub does today
- Four supplier actions on a purchase order — accept, reject, update shipping status and close — each on a rate limit and each guarded by an ownership check.
- A closure available only on an order that is the supplier's own, not already completed, and paid in full, with a distinct message for each refusal.
- Closure running the same implementation your own nightly housekeeping uses, so the two cannot drift apart.
- Closure setting the order completed, the shipping status delivered, the delivery date where none was recorded, and the sourcing document behind it completed.
- An event raised on closure, dispatched only where your organisation has an active rule listening for it.
- Acceptance carrying your own custom fields for purchase orders, so a portal action can collect the information your process needs.
- A supplier-set shipping status, so delivery progress comes from the party that has it rather than being inferred from a promised date.
More we can add to your workspace
- The actor recorded on a closure, distinguishing an order closed by your supplier from one closed by a scheduled sweep or by your own staff.
- A notification to the buyer when a supplier closes an order, rather than the change being visible next time somebody looks.
- A per-organisation switch for supplier closure, for buyers who would rather close their own orders whatever the payment status.
- A supplier-supplied delivery date, so the recorded date is the one they say the goods arrived rather than the moment the record was closed.
- A reason on a rejection, captured from the supplier at the moment they decline an order.
- A supplier view of what is still outstanding on a part-delivered order, so the two sides work from the same figure.
Where we point you to a specialist
- We will not let a supplier record what was received. A receipt is your evidence of what arrived and it is the input to the matching that governs payment; a delivery confirmed by the party being paid for it is not evidence, however convenient it would be.
- We will keep the payment condition on supplier closure. Allowing an outside party to close an unpaid order would let an administrative act touch a record that still has financial decisions attached to it, and no amount of auditing makes that a good arrangement.
- What your suppliers are permitted to do in your portal is ultimately your commercial arrangement with them. We will provide the actions and the controls; deciding that a particular supplier should or should not close orders is yours.
Recording who closed an order is the smallest piece here and the one that matters in a dispute — both callers know who they are, so it is a field rather than a redesign.
Attribution and agreement
The actions work and the conditions are right. What is worth adding is the record of who acted and a way for both sides to see the same outstanding position.
Who closed it
The actor recorded on a closure, so an order closed by a supplier is distinguishable from one closed by a sweep.
Tell the buyer
A notification when a supplier acts on an order, rather than the change waiting to be noticed.
A shared outstanding view
The supplier seeing the same still-owed quantities the receiver sees, so a chase begins from agreement.
We publish scope, not dates.
Scope the supplier portalFive questions to ask about supplier portal actions
Can a supplier change my records?
A good answer sounds like
Named actions, with conditions.
What ours actually is
Four: accept, reject, update shipping and close — the last only on their own order, not already closed, and paid in full.
Could a supplier close an unpaid order?
A good answer sounds like
No.
What ours actually is
No. Full payment is a hard condition, so closure can never touch an order with a financial decision still attached.
Can a supplier confirm delivery of goods?
A good answer sounds like
No — that is the buyer's record.
What ours actually is
No. Receiving is yours, and it is the input to the matching that governs payment. A supplier sets a shipping status, which is a different claim.
Is a supplier closure distinguishable from my own?
A good answer sounds like
Yes, ideally.
What ours actually is
Not today — both run the same closure. Recording the actor is the first item on the list of what would be added.
What stops a supplier acting on somebody else's order?
A good answer sounds like
An ownership check.
What ours actually is
The order's supplier must equal the signed-in supplier, checked on every one of the four actions.
Decide what you want the other side to write
The useful test is which facts your supplier knows before you do. Those are the ones worth letting them record; the rest is yours to verify.
Talk through supplier collaborationFrequently asked questions
Why can a supplier close my purchase order at all?
Because on an order that is fully paid and fully delivered, the supplier usually knows it is finished before you do — and the alternative is that it stays open on your side until somebody tidies up. The action is bounded by four conditions, and the payment condition means there is no financial decision left that closure could influence.
Can a supplier close an order I have not paid?
No. Full payment is checked and the refusal says so in as many words. It is the condition that makes the whole feature safe, because it guarantees that closure is an administrative act on a transaction that is already financially complete.
Will I be told when a supplier closes an order?
Not directly today — the change is visible on the order and through any rule your organisation has listening for a closure event. A notification to the buyer is on the list above and is the piece most organisations ask for after they discover the action exists.
Can a supplier mark goods as received?
No, and this is the line that stays where it is. A receipt is your record of what arrived and it feeds the matching that decides whether an invoice may be paid. A supplier sets a shipping status, which is a claim about where the goods are rather than a confirmation that you have them.
Does the record show that my supplier closed it?
Not distinguishably. Supplier closure and your own nightly closure call the same implementation, which is right — two routines would drift — but it means the order afterwards records that it was closed rather than who closed it. Adding the actor is a field, since both callers know perfectly well who they are.
Can we switch this off?
Not as a setting today. Where a buyer would rather close their own orders regardless of payment status, that is a per-organisation switch and it is named on the list above. In practice most organisations discover the action and keep it, because the orders it closes are ones nobody on their side was going to get to.
