Procurement Automation
Requisition to purchase order, with the approval thresholds actually enforced.
What is procurement automation?
Procurement automation runs the buying process from requisition to purchase order, applying your approval thresholds as a hard rule, matching invoices against orders and deliveries before payment, and keeping the whole trail for audit.
Buying policy is usually well written and unevenly applied. Two signatures above five hundred thousand, three quotes above a million, and then a genuinely urgent order goes through on a phone call because the plant is stopped.
That exception is reasonable once. Repeated forty times a year it becomes the actual process, and the written policy describes something that no longer happens.
Automating the flow makes the threshold a rule rather than a request. An urgent purchase still gets made, but it gets made through a recorded emergency route instead of around the system entirely.
Why we build an emergency route
Duara automates procurement from Nairobi for organisations buying often enough that the paperwork has become the constraint, and for those whose auditors have started asking harder questions.
We build an emergency route deliberately. A system with no legitimate way to move fast will be bypassed the first time production stops, and a bypassed control is worth less than a recorded exception, because at least the exception can be counted.
Who this is for
- Approval thresholds get bypassed under pressure
- Purchase orders are raised after the goods arrive
- Invoices are paid without matching to delivery
- Auditors have queried your buying trail
Industries we serve
- Manufacturing
- Construction and contracting
- Hospitality groups
- Healthcare facilities
- Education institutions
- NGO and donor funded operations
Problems this solves
These are control failures that begin as sensible exceptions and become the normal route.
- Thresholds bypassed under urgency. A genuinely urgent order goes through on a phone call, and repeated often enough that becomes the real process.
- Orders raised after delivery. The purchase order is created to justify goods that already arrived, which removes its entire purpose.
- Invoices paid without matching. Payment is made against an invoice alone, so short deliveries and price differences are paid for.
- A trail auditors cannot follow. Approvals live in email and WhatsApp, so demonstrating the policy was followed takes days of reconstruction.
What we deliver
Requisitions raised in one place, approval thresholds enforced automatically, purchase orders issued before delivery, three way matching before payment, and a recorded emergency route for genuine urgency.
Requisitions raised through a single route
Approval thresholds enforced as rules
Purchase orders issued before goods arrive
Three way matching before any payment
A recorded emergency route for real urgency
A complete audit trail without reconstruction
Features
- A legitimate emergency route. Fast purchases go through a recorded exception rather than around the system, because a bypassed control counts for nothing.
- Thresholds as rules, not requests. Approval limits are applied by the system rather than depending on somebody remembering them.
- Three way matching before payment. Invoice against order against delivery, so short deliveries and price differences are caught before money moves.
- Exceptions counted and reported. How often the emergency route is used is reported, since a rising count is a process problem worth seeing.
- Audit trail as a by-product. The record accumulates as the work happens rather than being assembled when somebody asks.
Benefits
- Policy and practice converge. The written thresholds start describing what actually happens, which is what auditors are really testing.
- You stop paying for goods you did not get. Three way matching catches short deliveries and price variances before payment rather than after.
- Urgency stops breaking the system. A recorded fast route means genuine emergencies do not force people outside the process.
- Audits get shorter. The trail exists already, so demonstrating compliance is a query rather than a reconstruction.
Technologies we use
- Requisition workflow. A single intake with approval routing by value, category and requester.
- Threshold enforcement. Applying your delegation limits automatically rather than relying on recollection.
- Purchase order issue. Generating and sending orders to suppliers before goods are dispatched.
- Three way matching. Comparing invoice, purchase order and goods received note before payment is released.
- Exception recording. Capturing emergency purchases with their justification and reporting the frequency.
The design question is not how to prevent exceptions but how to make the legitimate exception easier than the workaround. Controls that ignore operational reality get routed around.
How the process works, step by step
Procurement automation usually takes six to nine weeks, and the emergency route is designed early rather than added after complaints.
-
Step 1
Free buying review
We look at how often thresholds are currently bypassed, which is usually more often than the policy assumes.
-
Step 2
Thresholds confirmed
Approval limits are agreed and written down, including who may authorise an emergency.
-
Step 3
Emergency route designed
The fast path is built early, because a system with no legitimate urgency route gets bypassed the first week.
-
Step 4
Requisitions and orders live
The main flow goes live, with orders issued before delivery rather than after it.
-
Step 5
Matching and reporting
Three way matching and exception reporting follow once order data is complete.
Quality assurance and how we work
The commitments attached to automating a control process.
- We build a legitimate way to move fast. A system with no urgency route gets bypassed the first time production stops, and a bypassed control is worth less than a recorded exception.
- Emergency use is counted and reported. A rising exception count is a process problem, and we report it rather than letting it become invisible.
- Matching happens before payment. Invoice, order and delivery are compared before money moves, because recovering an overpayment is much harder than preventing it.
- We do not weaken thresholds to reduce friction. Where a client asks us to raise a limit so fewer approvals are needed, that is a risk decision for them to take explicitly, not a configuration tweak.
- The trail is contemporaneous. Records accumulate as work happens, since a trail assembled afterwards carries far less weight with an auditor.
Frequently asked questions about procurement automation
Will this stop urgent purchases?
No. It gives urgency a recorded route instead of an unrecorded one, because a system with no fast path gets bypassed the first time production stops.
Why build an emergency route at all?
Because a bypassed control is worth less than a recorded exception. At least the exception can be counted and reviewed.
What if the emergency route gets overused?
The count is reported. A rising figure is a process problem worth seeing rather than something to hide.
Can it enforce our approval limits?
Yes, as rules applied by the system rather than depending on somebody remembering the policy.
Can we raise a limit to reduce friction?
That is a risk decision for you to take explicitly rather than a configuration tweak, and we will frame it that way.
What is three way matching?
Comparing the invoice against the purchase order and the goods received note before payment, so short deliveries are caught before money moves.
Why match before paying?
Because recovering an overpayment from a supplier is much harder than preventing it, particularly on smaller amounts.
Does it issue purchase orders to suppliers?
Yes, before goods are dispatched, which is what makes the order meaningful rather than a document created afterwards.
What about orders raised after delivery?
We measure how often that happens now, and it is usually more frequent than the policy assumes.
How long before requisitions are running through it?
Six to nine weeks, with the emergency route designed early rather than added after complaints.
Will our auditors be satisfied?
The trail is contemporaneous rather than reconstructed, which is normally what they want. We suggest showing them the design early.
Does it handle framework contracts?
Yes, with contracted rates applied so orders are checked against agreed pricing rather than compared as if no contract existed.
Can branches raise requisitions separately?
Yes, and consolidating them across sites frequently reveals the same item being bought at different prices.
What about maverick spend?
It becomes visible, which is usually the first time anybody can quantify buying that happened outside the process.
Does it choose suppliers?
No. It enforces the process and presents information. Supplier selection stays a commercial judgement for your buyers.
Can it handle donor procurement rules?
Yes, and NGO clients frequently need donor specific thresholds enforced alongside their own.
Will it slow down buying?
Usually the opposite, because approval chasing disappears. Where it does add a step, that step is a control you already agreed.
Does it connect to our accounting system?
Yes, so approved orders and matched invoices flow through rather than being rekeyed.
Who can see our purchase records?
Only your own staff under your permissions. Buying data is not copied out to us and trains no public AI model.
What does procurement automation cost?
Requisition volume and site count determine it, quoted after the buying review.
Glossary of terms
Procurement control terms in plain language.
- Requisition
- The internal request to buy, raised before any commitment to a supplier.
- Purchase order
- The formal commitment to a supplier, which should exist before goods are dispatched.
- Three way match
- Comparing invoice, purchase order and goods received note before releasing payment.
- Approval threshold
- The value above which additional authorisation is required.
- Emergency route
- A recorded fast path for genuine urgency, designed so people do not go around the system.
- Maverick spend
- Buying that happens outside the agreed process, usually invisible until it is measured.
Related services in Automation
Talk to us about procurement automation
Ask your finance team how many purchase orders were raised after the goods arrived last quarter. That number is the starting point.
Start your project