تعتمد المشتريات في معظم الشركات الصغيرة والمتوسطة على رسائل WhatsApp الصوتية، وعروض أسعار محفوظة كصور، وقيد في Tally يُسجَّل بعد وصول البضاعة. تابع طلبًا تجريبيًا — PR-0241 لـ 24 مجموعة محرّك — عبر ثماني مراحل متصلة، واكتشف أين تُفيد الأتمتة وأين يجب أن يبقى القرار بيد الإنسان.
Key takeaways
- 01Procurement automation is one connected record trail — requisition to receipt — not a bot that buys.
- 02Automate the handoffs: routing, reminders, numbering, matching. Keep people on approvals, supplier choice and exceptions.
- 03Compare the full offer against the requirement. The lowest rate that meets the delivery window beats the lowest rate.
- 04The 3-way match (PO, GRN, invoice) is where short receipts, rate drift and GST credit problems get caught before payment.
- 05Suppliers can stay on WhatsApp. It just can't be where your purchase records live.
- 06Start with the software you already have. Move to a connected ERP when locations, volume or approval rules outgrow it.
Where purchasing leaks money in a WhatsApp-and-Tally business
Ask the production head of a mid-sized Indian manufacturer how purchasing works and you'll usually hear some version of this. A supervisor sends a WhatsApp voice note to the purchase team. The buyer calls two or three suppliers he trusts. Quotations arrive as photos of letterheads. Somebody types a PO in Tally or Word — sometimes after the order has already been placed by phone. And the first time accounts sees the transaction is when a supplier's invoice turns up with a delivery challan stapled to it.
None of this is careless. It's how purchasing grows when the business grows faster than its systems. But every handoff in that chain happens somewhere different — a chat, a phone call, a register at the gate, a folder in accounts — and money leaks in the gaps between them. It rarely leaks in one dramatic loss. It leaks in small, repeatable ways nobody is positioned to see.
- Duplicate or panic orders — two people order the same item because neither can see the other's request
- Rate drift — the invoice rate differs from the rate agreed on the call, and nobody has the quote to check against
- Short or damaged receipts paid in full — stores accepted 22, the invoice says 24, accounts pays for 24
- Late material discovered late — nobody knew the supplier hadn't dispatched until the line was waiting for it
- GST credit at risk — invoices that don't reconcile with GSTR-2B, or an HSN code that doesn't match the item
What procurement automation actually means (and what it doesn't)
Procurement automation doesn't mean a bot that buys things. For an SME it means something plainer: every purchase moves through one connected record trail — requisition, approval, request for quotation, quotation comparison, purchase order, dispatch, goods receipt, invoice — and each step creates the next one instead of being retyped from a chat.
The automation lives in the handoffs. When stock falls short of what production needs, a requisition drafts itself. When the requisition is approved, the buyer gets an RFQ ready to send. When the supplier dispatches, receiving knows what's coming and against which PO. When the invoice arrives, the system already knows what was ordered and what was accepted. People stop being the glue between steps and go back to the parts of the job that need judgement.
We usually write about the revenue side of an SME — the 5-layer revenue stack is the map for that. Procurement is the other half of the margin. A rupee lost to a short receipt or a drifted rate never shows up as a marketing problem, but it comes off the same bottom line.
- Automate: requisitions from stock and production rules, approval routing by amount, RFQ sending, supplier reminders, PO numbering, inventory updates from the goods receipt, and the 3-way match
- Keep human: approving spend, choosing a supplier when the cheapest isn't right, accepting or rejecting goods at the gate, and resolving invoice exceptions
Automate the handoffs, not the judgement. A system should never commit money a person hasn't approved.
Follow one order: PR-0241, from requisition to goods receipt
The easiest way to see it is to follow a single purchase. The example below is illustrative — sample data, not a client's order — but the numbers are internally consistent, so you can follow the arithmetic from end to end.
Production needs 30 drive assemblies for an upcoming run. Stores has six. The ERP raises requisition PR-0241 for the remaining 24, linked to the production requirement that created it. The department lead checks the need against budget and approves it, so the decision is recorded rather than remembered. Purchasing then sends RFQ-0186 to three qualified suppliers with the same specification, the same quantity and a seven-day delivery requirement.
Three quotations come back into the same record. Supplier A quotes ₹6,500 a unit with a six-day lead time, Supplier B ₹6,750 with nine days, and Supplier C ₹6,900 with four. All three meet the specification. B drops out — not on price, but because nine days misses the seven-day window. C is fastest, but those two extra days of buffer would cost ₹9,600 on this order. A is the lowest rate that meets the requirement, so A gets PO-0089: 24 units at ₹6,500, a subtotal of ₹1,56,000 before GST.
From there the order becomes a shipment plan — two pallets, a booked vehicle, a planned route — and dispatch and arrival milestones update the same PO, so the receiving team isn't waiting on a phone call. At the gate, receiving checks all 24 units against PO-0089, accepts them and posts GRN-0058. Stock moves from six to 30, and the trail reads PR-0241 → PO-0089 → GRN-0058: one purchase, every handoff connected. The walkthrough below runs the whole sequence.
- 01 Requisition — PR-0241 raised for 24 units, production to purchasing
- 02 Approval — budget checked, department lead releases it to the buyer
- 03 RFQ — RFQ-0186 sent to three qualified suppliers
- 04 Quotations — rate, lead time and specification compared side by side
- 05 Purchase order — PO-0089 issued to Supplier A and acknowledged
- 06 Dispatch plan — SHP-0089, two pallets allocated, transport booked
- 07 In transit — dispatch and arrival milestones update the PO
- 08 Goods receipt — GRN-0058 posted, stock updated to 30 units
The Indian layer: GST, e-way bills and the 3-way match
Most procurement software writing assumes a Western back office. An Indian SME has three extra realities, and a purchase system that ignores them just moves the chaos from the purchase team to accounts.
The first is the 3-way match. Before an invoice is paid, three documents should agree: the purchase order (what you agreed to buy, at what rate), the goods receipt note (what actually arrived and was accepted) and the supplier's invoice (what you're being asked to pay). In the sample order that's PO-0089 for 24 units at ₹6,500, GRN-0058 with 24 of 24 accepted, and an invoice that should say the same. If receiving had rejected two damaged units, the GRN would show 22 accepted, the match would flag an invoice for 24, and accounts would raise a debit note instead of paying for goods that went back on the truck.
The second is GST. If the item attracts 18% GST, PO-0089's ₹1,56,000 becomes an invoice of ₹1,84,080 — and that ₹28,080 of tax is money you want back as input tax credit. Credit depends on having actually received the goods and on the supplier's invoice showing up in your GSTR-2B. A system that ties every invoice to a GRN, and keeps the HSN code and GST rate on the item master rather than in the buyer's head, catches mismatches before the return is filed instead of after.
The third is movement and payment compliance. A consignment worth more than ₹50,000 generally needs an e-way bill before it moves (some states set a higher threshold for movement within the state), so the dispatch stage should record the e-way bill number and vehicle number against the PO — not in a WhatsApp photo. And since FY 2023–24, income-tax law has tied your deduction for purchases from registered micro and small enterprises to paying them within the MSMED Act limit: 45 days with a written agreement, 15 days without. Your CA will know how it applies to your suppliers. The system's job is to put the due date on the invoice record, where it gets seen.
In practice, the match itself comes down to four checks:
- Quantity — invoiced quantity is no more than the quantity accepted on the GRN
- Rate — invoice rate equals the PO rate, with a small rounding tolerance rather than a percentage loophole
- Tax — GST rate and HSN code on the invoice match the item master
- Exceptions — anything that fails goes to the buyer with all three documents side by side, not to a spreadsheet
Your suppliers will stay on WhatsApp — plan for it
Here's what most procurement software gets wrong in India: your suppliers aren't going to log into a vendor portal. The owner of a small machining unit runs the business from his phone. If your process depends on him filling in a web form, it will drift back to phone calls within a month.
So don't fight the channel — structure it. It's the same principle as running your CRM inside WhatsApp: people keep talking where they already talk, and the system captures the structure in the background. Business-initiated messages go out through the WhatsApp Business API as pre-approved templates, replies are captured against the right RFQ or PO, and anything the system can't read goes to the buyer.
One rule carries over from our WhatsApp sales agent playbook: never let automation promise something a person has to deliver. The bot can chase a dispatch date; it should never agree a rate or accept a revised delivery date on your behalf. Within that rule, four touchpoints cover most of the supplier conversation:
- RFQ out — one template per supplier with specification, quantity and required date; the quote reply lands in the comparison, not in a chat gallery
- PO acknowledgement — the PO goes out as a PDF, a one-word reply marks it acknowledged, and no reply in 24 hours nudges the buyer
- Dispatch confirmation — a reminder the day before the promised date asks for the vehicle number, e-way bill number and a copy of the invoice
- Arrival — the gate enters the PO number and stores gets a GRN task with the expected quantity already filled in
Suppliers can keep using WhatsApp. It just can't be where your purchase records live.
Tally, Zoho or a connected ERP: what to use when
You don't necessarily need new software to start. TallyPrime can raise purchase orders, record receipt notes and track rejections, and Zoho Inventory has purchase orders, purchase receives and bills. Many SMEs that use these tools only ever post the final purchase voucher — the PO and the receipt never make it in. Switching those features on and insisting on them gets you most of the paper trail.
Where they run out is the connections: requisitions that come from production planning, approvals that change by amount or department, stock spread across several godowns, supplier messages feeding the record, and a live view of which POs are late. That's the point where a connected ERP earns its cost — and your accountant can often keep Tally for the books, with purchase vouchers synced rather than retyped.
Our manufacturing ERP work covers the connected version — purchasing, inventory across godowns, GST e-invoicing and e-way bills in one system — and our services page shows how we scope it. As a rough guide:
- One location, a handful of regular suppliers, a few dozen POs a month — turn on the purchase features you already pay for and enforce no PO, no payment
- Several plants or godowns, requisitions driven by production, approval rules by value — a connected ERP, with Tally kept for accounts if your CA prefers it
- Supplier WhatsApp flows, custom approval rules or dashboards your ERP can't do — a thin custom layer on top, integrated rather than replaced
A 30-day rollout that doesn't stop purchasing
Purchasing can't pause while you fix it, so the rollout runs alongside the current process and replaces it one stage at a time. The rule is the one we use in the 45-minute revenue audit: every change gets an owner and a date.
Once the four weeks below are done, measure four things every week: requisition-to-PO cycle time, deliveries received by the PO date, invoices that match first time, and invoices that arrived without a PO. When that last number reaches zero, the process is real. If you'd like a second pair of eyes on yours, book a 45-minute review — we'll map your purchase flow from requisition to receipt and mark where it leaks.
- Week 1 — map the current flow for your top 20 purchased items, clean the item master (units, HSN codes, GST rates) and write the approval matrix by amount
- Week 2 — go live with requisitions, approvals and numbered POs, and tell suppliers that invoices need a PO number
- Week 3 — move RFQs and quotation comparison into the system and switch on the supplier WhatsApp templates
- Week 4 — post GRNs at the gate, turn on the 3-way match and review the first batch of exceptions together
End of post · 11 min read · 1,428 words
Primary keyword
procurement automation~590 searches / mo (India)
Also answers
- purchase order automation
- procure to pay process
- 3 way matching
- purchase requisition approval workflow
- procurement software india