The Order the Supplier Said Yes To
“Accepted” is the least useful thing a supplier can say about a purchase order. It does not say when, it does not say whether all of it, and it leaves the buyer to find out at the receiving dock. What an acknowledgement has to carry, how a supplier sends it from the portal, the app or their own system, and what happens when the two sides disagree.
The short version
An acknowledgement is only useful if it is a promise: a date for the order, and for each line whether it is confirmed, part-shipped with the rest on backorder, fully backordered, or not available at all. Ours takes exactly that, from the supplier portal, the app or the supplier’s own system through one service, flags every line that falls short to the buyer, refuses a shipment notice before the order is acknowledged, and keeps one message thread per order in which either side can raise a dispute and only the buyer can close it.
The order was for forty cartons of sanitiser, twelve dispensers and two hundred refill pouches, due on the 14th. The supplier clicked Accept the same afternoon. On the 14th, a van delivered forty cartons and twelve dispensers. The pouches, it turned out, had been out of stock since before the order was placed. The supplier had known that when they clicked Accept; Accept had no way to say it. The buyer found out from the storekeeper, the storekeeper found out from the delivery note, and the pouches arrived nineteen days late with nobody having planned for the gap.
What “accepted” leaves out
Most purchasing systems give a supplier two buttons on an order: accept and reject. Both are about the order as a whole, and neither carries a date. That suits the supplier, who would rather not commit in writing, and it suits nobody else, because the questions the buyer actually has are per line and per day.
| The buyer needs to know | Accept answers it | An acknowledgement answers it |
|---|---|---|
| Will it come at all? | Yes | Yes, per line |
| When? | No | A promised date for the order and for each line |
| All of it? | No | Confirmed, partial, backorder or cannot supply |
| If not all, when is the rest? | No | Backorder quantity and its own date |
| Anything we should know? | No | A note on the order and on each line |
The acknowledgement, line by line
In the supplier portal an issued order now has Acknowledge and Decline. Acknowledging takes a promised delivery date for the order and, for each line, a status. A confirmed line can carry its own date. A partial line says how much will follow on backorder and when. A backordered line gives its date. A line that cannot be supplied says so, with a note. Acknowledging again later — because a date slipped, or the backorder arrived early — updates the promise; it does not start a second record.
The sanitiser order, acknowledged properly
The buyer learns about the pouches the afternoon the order is acknowledged, not on the 14th at the dock — nineteen days of notice instead of none.
On the buyer’s side, the order carries a Supplier commitment & messages card: the promised dates, and a flag for every promise later than the buyer’s own due date and every line that is partial, backordered or unavailable. Supplier actions also land in the buyer’s notification bell, under their own setting.
Shipment notices, after the promise
A supplier can send a shipment notice with a delivery note attached — a PDF or a photo of the paper one. Two rules keep it honest. A notice cannot be sent before the order is acknowledged, so the promise always comes first. And a notice cannot advise more of a line than is still unadvised, so two notices for the same forty cartons are refused rather than double-counted. Sending one marks the order in transit.
A notice is the supplier’s statement
Receiving still counts the goods. A shipment notice tells the dock what to expect; it never books stock in. The receipt is what posts, and the three-way match compares the order, the receipt and the bill — not the notice.
When the two sides disagree
Each order has one message thread shared by the buyer and the supplier. Either side can mark a message as a dispute: wrong price on the order, goods sent back, a delivery the supplier says was signed for. Only a buyer holding the permission to approve purchase orders can resolve a dispute, and resolving it needs a note. The thread and its resolution stay on the order, so the next person to ask "what happened with the pouches?" reads it there rather than in two inboxes.
A dispute that only the supplier can close is a complaint box. One that closes itself is a timer. Ours closes when a buyer writes down how.
Three doors, one set of rules
Small suppliers acknowledge in the web portal or the mobile app. Larger ones want their own order system to do it. All three — the portal, the app and the supplier integration API — go through the same service, so a rule added for one applies to all of them. That is tested directly: an acknowledgement from the portal and one from the app leave the same record.
What AWRA OpsHub does today
- Acknowledge and decline in the supplier web portal, the mobile app and the supplier integration API, through one shared service.
- A promised date for the order and per line, with each line confirmed, partial with a backorder quantity and date, backordered, or not available, and a note on each.
- Re-acknowledging to update the promise, without starting a second record.
- Flags to the buyer for a promise past their due date and every line that falls short, on the order’s card and in the notification bell.
- Shipment notices with a delivery document, only after acknowledgement and never for more than is still unadvised, setting the order in transit.
- One thread per order in which either side can raise a dispute and only a buyer with order-approval permission resolves it, with a note.
More we can add to your workspace
- Late-delivery queues measured against the supplier’s promised date, alongside the buyer’s own due date, so an order promised late is flagged before it is overdue.
- A follow-on order raised from a backordered line, carrying the backorder quantity and date.
- A response clock on an open dispute, with a reminder to the buyer when it runs past a set number of days.
Where we point you to a specialist
- We will not let a shipment notice book stock. What the supplier says was sent and what the dock counts are different facts, and only the second one posts.
The promised-date queue is the most useful of the three and sits directly on dates the acknowledgement already stores.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThree questions for your purchase-order process
How do we find out a line is out of stock?
What you will probably hear
When it does not arrive.
How to read it
Then the acknowledgement is not carrying the information the supplier already has. A per-line status turns a surprise at the dock into a decision made days earlier.
Can a supplier change their delivery date after accepting?
What you will probably hear
By email.
How to read it
An updated promise should replace the old one on the order, with the buyer flagged, so the date on the order is the date people plan to.
Who closes a dispute with a supplier?
What you will probably hear
Whoever answers last.
How to read it
Insist on a named role and a written resolution. A dispute nobody closed is the first thing an accounts-payable team trips over at bill time.
See the vendor collaboration portal
Quotes, order acknowledgements with promised dates, shipment notices, documents and messages, for suppliers on the web, in the app and through their own systems.
Explore the supplier portalFrequently asked questions
Can a supplier accept only part of a purchase order?
Yes. When acknowledging, the supplier gives each line a status: confirmed, partial with a backorder quantity and date for the rest, fully backordered with a date, or not available. The buyer is flagged on every line that falls short.
Can a supplier change the promised date later?
Yes. Acknowledging again with a new date or new line details updates the promise on the order. It does not create a second acknowledgement.
Does a shipment notice add stock to inventory?
No. A shipment notice tells the buyer what the supplier says was sent and marks the order in transit. Stock is only booked in when the goods are received and the receipt is approved.
Who can resolve a dispute raised on an order?
Only a buyer who holds the permission to approve purchase orders, and resolving it needs a written note. Either the buyer or the supplier can raise the dispute in the order’s message thread.
Can large suppliers acknowledge orders from their own system?
Yes. The supplier integration API accepts acknowledgements and shipment notices using a scoped token, and it applies exactly the same rules as the portal and the mobile app.
