# Automated Purchasing: Getting the Purchase Order to Your Supplier Before the Item Runs Out *An alert doesn't buy anything. The real gap between "we knew we were low" and "the order is in the supplier's hands" — and how to close it without anyone chasing it.* > **In short:** An alert doesn't place the order. A practical guide to purchase automation: min/max levels, suggested vs auto-sent orders, safety limits, supplier replies. - **URL:** https://www.snad.io/en/blog/alshiraa-altilqai-atmatat-almushtarayat - **Arabic original:** https://www.snad.io/blog/alshiraa-altilqai-atmatat-almushtarayat - **Category:** Guides — Business & Inventory Management - **Tags:** Inventory Management, Purchasing, Reorder Point, Suppliers, Automation, Digital Transformation, Snad - **Published:** 2026-07-31 - **Updated:** 2026-08-02 - **Publisher:** Snad (snad.io) Automated purchasing closes a gap every business knows: the system warns that an item is running low, and the item runs out anyway — because an alert is a notification, not an action, and between that notification and the order reaching your supplier lies a manual journey that stalls at a person at every step. This guide explains how to close that gap: two numbers per item, a daily stock check, and a purchase order that gets prepared, sent and confirmed without anyone chasing it — and where your hand should stay on the switch. ## Why stock still runs out even though the system "alerts" you Most inventory systems know when an item is running low, and they tell you. Then the item runs out anyway. The failure isn't in the arithmetic. It's that **an alert is a notification, and a notification is not an action**. It appears on a screen somebody opens in the morning alongside twenty others, so they see it and put it off, or they see it and don't have the authority to raise an order, or they never see it at all because they're on leave. So the shortage gets discovered the oldest way there is: a customer asks for the item and it isn't there. Only then does anyone move. The problem, then, isn't "how do we know" but "who orders". That is an execution gap, not an information gap, and no smarter alert will close it. The only thing that closes it is moving the action itself into the system. ## The manual journey after the alert: five stations, every one of them stalls Assume the alert arrived, and assume somebody actually read it. There are still five stations between you and the goods, and each one stops at a person: - **Someone opens the item record** to find out how much is really left, how much you usually order, and whether there's an earlier order still in transit. - **Someone knows the supplier** — which supplier carries this particular item, at what price last time, and how long they take to deliver. - **Someone writes the order** in a form the supplier can act on: items, quantities and prices, not a message dashed off in a hurry. - **Someone sends it** and confirms it actually landed, rather than sitting in drafts or going to an old number. - **Someone follows up** — did the supplier reply? Can they supply the full quantity? When? And at what price, now that prices have moved? Every one of these works fine when there's a single item. The problem is that you have hundreds of items, and the five stations repeat for every item, every supplier, every day. So what always happens, happens: the item the customer shouted about gets ordered, and the rest are forgotten until another customer shouts. ## Two numbers, not one: the minimum and maximum levels Automating the order takes two numbers, not one, because they answer two different questions. **The minimum level** answers "when do I order?" It's the balance at which an item must be reordered — the reorder point — and it's built from your consumption rate, your supplier's lead time, and a safety margin. **The maximum level** answers "how much do I order?" It's the balance you want stock to reach once the order lands. The gap between the two numbers is the order quantity, calculated at the moment of ordering rather than fixed in advance. The practical benefit of separating them is that you get two independent behaviours to tune: when you move, and how much you buy each time. A cheap, fast-moving item can carry a low minimum and a high maximum — you order late and buy plenty. An expensive, slow-moving item inverts the equation entirely. Working out the two levels is a subject in its own right, with its own formula and worked examples. What concerns us here is what happens **after** the system knows both numbers. ## What the system should be doing instead of your employee For the system to take over those five stations, comparing a balance against a level isn't enough. It has to do three more things, and each one is a common failure in naive automation. **Check on a fixed rhythm, not continuously.** Once a day, at an hour you choose. Checking on every sales transaction produces orders scattered across the day for the same supplier, and your supplier hates that as much as you do. **Deduct what's already on order but not yet received.** This is the most dangerous of the three. If the system looks at stock on hand alone, it will see the item short again tomorrow — even though you ordered it yesterday — and order it a second time. The figure the calculation must use is: what's in the warehouse plus the quantities sitting on open purchase orders. **Group one supplier's items into a single order.** If ten items from the same supplier fall short, that's one order, not ten. That's the difference between a system that serves your supplier and one that pesters them. Those three together are what separates an automated alert from automated purchasing. ## Suggested order or automatic send? There's no single right answer, and the choice depends on how much you trust your levels, not on how brave you are: | Mode | When it suits you | What you gain | What it costs you | | --- | --- | --- | --- | | Suggested order | In the first few weeks, with expensive items, or when supplier prices move often | You review and adjust every order before it goes out, so you catch badly set levels at no cost | The order sits there until somebody opens the screen, so a weekend delays it | | Automatic send | Once your levels have settled and proved themselves over a cycle or two | The order goes out even if nobody logs in, which is the whole point of automation | A wrong level turns into a real purchase order, which makes safety limits a necessity rather than a nicety | The practical route is to start in suggested mode with one or two items and compare what the system proposes against what you would have ordered yourself. When the two match twice in a row, move to automatic — and start with the cheap, fast-moving items, not the expensive ones. ## The safety limits that stop the wrong order One question stops most people from switching on automatic sending: "what if it gets it wrong?" The answer isn't trust. It's written ceilings: - **An approval threshold:** any order above an amount you set is never sent automatically, whatever the circumstances — it waits for a human eye. - **A daily spending cap:** the total that can be ordered in a single day. This protects you from the catastrophic case — a bad stock count that drops the balances of dozens of items at once and has the system order every one of them. - **The check hour and days:** you pick the hour in your own time, and exclude days off if your suppliers don't work them. - **A preview button:** it shows you exactly what would have been ordered today, in what quantities and from which supplier, without creating an order and without sending a message. This is the best place to start, before you switch anything on. - **A log that explains every decision:** including why an item you expected to be ordered wasn't — because its balance is above the level, or because it has an open order, or because it has no supplier on file. Automation that can't explain itself never earns anyone's trust. Those five make switching on a reversible decision, which is what makes it an easy one. ## Your supplier won't install an app: how to close the confirmation loop This is where most attempts come apart. The system sent the order — then what? If the answer is "we wait for the supplier's reply and key it in", you've let the employee back into the loop through the back door. The realistic solution starts from a simple fact: **your supplier will not open an account in your system, will not install an app, and will not attend a training session.** Any solution that assumes otherwise dies at the first supplier. What does work is a reply page behind a single link inside the message itself. The supplier opens it, sees the order exactly as it was sent, confirms what they can supply, sets a delivery date, adjusts quantities or prices if they've changed, or declines. No password, no sign-up. And the value of that is greater for you than for them: you get an instant notification, and their numbers appear next to yours on the same screen — you asked for a hundred, they confirmed eighty, at SAR 2 more per unit, delivering in a week rather than three days. That's information you would otherwise have discovered on delivery day; now it's in your hands today. ## A purchase order is not an invoice: where automation ends and accounting begins One point should be clear before you switch anything on: **a purchase order changes neither your stock nor your books.** It's a request directed at a supplier, nothing more: it doesn't raise an item's balance, it doesn't create a journal entry, and it doesn't appear in the trial balance. The inventory and accounting impact stays exactly where it is today: in the **purchase invoice**. When the goods arrive you convert the order into an invoice using the figures the supplier confirmed, stock goes up, and entries are posted the same way your business posts them now. That's why automatic conversion from order to invoice is off by default, and should stay that way: **a supplier's confirmation means "I will supply it", not "it has arrived".** Between the two lies a week, a quantity that may fall short, and an item that may turn up damaged. Convert automatically on confirmation and you're building book stock that doesn't exist on the shelf — which is worse than running out, because it's a shortage you don't know you have. ## Automated purchasing in Snad: the full cycle In the [Purchases app](/purchases) the cycle runs on eight steps. You set the first one up once; the rest repeat without intervention: - **Setup:** you set the two levels for each item, or press "suggest levels" and the system calculates them from your actual sales and each supplier's lead time, and you make sure every item has a supplier and every supplier has a contact channel. Bulk assignment lets you set a whole group of items at once using search and filters. - **The daily check:** once a day, at the hour you chose, the system compares each item's balance against its minimum level. - **Preparation:** it works out the shortfall, deducts what's on order but not yet received, and groups one supplier's items into a single order. - **Approval:** if you chose suggested-order mode, you review and adjust, then approve or cancel. - **Sending:** the order goes out on WhatsApp and email together as a PDF carrying your business's logo, with the status of each channel visible to you, and an alert to you if both channels fail. - **The supplier's reply:** through their own page, with no account and no app. - **Receiving and invoicing:** "convert to purchase invoice" in one click, using the confirmed figures. - **Closing the loop:** the higher balance makes the system skip the item tomorrow, and if it's still short, only the difference is ordered rather than the full quantity all over again. Levels can differ from one warehouse to another, so the branch that sells more deserves a higher minimum. And because [inventory management](/inventory) and [accounting](/accounting) live in the same system, goods that arrive raise the balance and post the entry with no second round of data entry. **Read also:** for the two levels themselves, with the formula and worked examples, see our guide to the reorder point; for estimating future consumption, see our guide to demand forecasting and inventory planning; and for choosing the supplier in the first place, see our guide to supplier evaluation and management. ## Frequently asked questions ### What's the difference between a reorder alert and automated purchasing? An alert tells you an item is running low and stops there, so it's still on somebody to open the item record, work out the supplier, write the order, send it and follow it up. Automated purchasing performs those same steps: it calculates the shortfall, prepares the purchase order, and sends it to the item's supplier on WhatsApp and email. The difference is practical, not semantic — the first is information, the second is action. ### How do I set the levels for a new item with no sales history? Start with a conservative estimate: how much you expect to sell weekly, multiplied by the supplier's lead time, plus a safety margin. Then run the item in suggested-order mode for a cycle or two and compare what the system proposes against what you would have ordered yourself. Once real sales have accumulated, the "suggest levels" button becomes more accurate than your estimate, because it calculates from your data rather than your expectations. ### Could the system send a purchase order by mistake? It's possible if the levels are set wrong or the balances are inaccurate, which is why there are three layers of protection: suggested-order mode, which holds every order for your approval; the safety limits (an approval threshold and a daily spending cap); and the preview button, which shows you what would have been ordered today without creating an order and without sending a message. Start with the preview before you switch anything on. ### What if an item has more than one supplier, or no supplier on file at all? The order is prepared for the supplier assigned to the item, so if the item has no supplier it won't be ordered — and that will show up in the log as the reason it was skipped, not as unexplained silence. That's why setup includes making sure every item has a supplier and every supplier has a contact channel, and bulk assignment handles a whole group of items in one go. ### Does a purchase order affect stock or the accounting entries? No. A purchase order is a request to a supplier and nothing more: it doesn't raise an item's balance and it doesn't create a journal entry. The inventory and accounting impact stays in the purchase invoice, and is recorded when you convert the order into an invoice after the goods arrive. That separation is deliberate, and it protects your books from stock that only exists on paper. ### How does the supplier reply if they don't have an account in the system? Through a reply page specific to that order, opened from a link inside the message itself. They confirm what they can supply, set a delivery date, and adjust quantities and prices if they've changed — with no account, no app and no training. You get an instant notification of their reply, and their numbers appear next to yours. --- ## About the publisher **Snad (سند)** — a private Saudi software company based in Riyadh, founded 2025. Legal form: Sole proprietorship. Commercial registration: 7038154642 VAT number: 310959226500003 Only official domain: snad.io > Snad is a private commercial business-management platform. It is not a > government body, not a bank, and not a government services portal, and it > is not affiliated with any government entity. Any site or app with a > similar name is unrelated to Snad.