The Estimate That Is Not Yours
The value on a purchase request is the quantity times the item's last recorded buying price. It is not a figure the requester supplied, it changes when somebody edits the item master, and nothing ever compares it to the price you actually paid.
Somebody raises a request for two hundred units. The screen shows a value. That value is the single most consequential number in the whole procurement chain, because it is what an approver reads before deciding.
It is worth knowing where it comes from, and it does not come from the person who raised the request.
Where the number is from
It is the requested quantity multiplied by the item's buying price on the item master — the last price recorded against that item in your catalogue. Every place a request's value is displayed computes it the same way.
The requisition line does have a price column of its own. Nothing uses it for this figure.
Three consequences follow, and none of them is obvious from the screen.
- The estimate is not the requester's. They asked for a quantity; the value was supplied by the catalogue. If they know the price has moved, there is nowhere for them to say so that the figure will notice.
- The estimate moves after the fact. Edit the item's buying price and every open request for that item is revalued, retrospectively, including ones already approved. The approver approved a number that no longer exists.
- Nothing closes the loop. No report compares what a request was estimated at against what the resulting order cost. The two figures live on two records with no comparison between them.
An approval is a decision about a number. If the number can change afterwards, the record of the decision is incomplete.
The detail that is done properly
It would be unfair to describe this area as careless, because one part of it is more thoughtful than most.
When the system works out how much of a request actually needs procuring, it subtracts what you already hold and floors the result at zero. So a request for two hundred units of something you have eighty of asks the buyer to source a hundred and twenty, not two hundred — and an item you have plenty of contributes nothing rather than a negative.
That is a small piece of arithmetic that quietly prevents a common and expensive error, and whoever wrote it was thinking about the warehouse rather than about the form.
Why a Bahraini buyer should care about the moving estimate
Because a large share of what is bought here is imported, priced in a currency that is not the one the catalogue was last updated in, and subject to freight and clearing costs that move on a different clock from the goods.
An item master's buying price is a historical fact — the last price recorded. In a stable local supply chain it is a decent proxy for the next price. For an imported item last bought nine months ago, it is a number with no particular relationship to what the next order will cost, and the approval that was granted against it was granted against nothing in particular.
The direction of the error also matters. Prices more often rise than fall, so a stale estimate more often understates, which means approvals are more often granted at a level that would not have been granted at the true figure.
How to work with it
-
Keep buying prices current on the items you buy most
This is the whole fix and it is unglamorous. The estimate is only as good as the item master, so the item master is where the effort goes. Twenty items will cover most of your spend; the rest can drift.
-
Treat approval as approval of a quantity, not of a value
Which is closer to what the record actually supports. If you need value-based authorisation, the place it genuinely bites is the order, where the figure is a real quoted price rather than a catalogue estimate.
-
Do the estimate-versus-actual comparison quarterly, by hand
Take a sample of requests, find the orders they became, and compare. You are looking for a systematic gap rather than individual variances — a consistent understatement means your item master is stale, and that is fixable.
-
Never edit a buying price to make an approval work
It sounds absurd written down and it is exactly what will happen once somebody realises the estimate is catalogue-driven. Make that an explicit rule before it becomes an implicit habit.
What AWRA OpsHub does today
- Requisition lines with an item and a quantity, and a request value computed as quantity times the item master's buying price.
- A to-procure quantity net of stock on hand, floored at zero, so you are not asked to buy what you already have.
- Requisition approval genuinely enforced — no purchase order can be raised against a request that is not approved.
- A destination warehouse and location on the request, carried through the chain.
- A full path from request to quotation to order, with the request retained and linked.
What it does not do
- A requester-supplied estimate. The line has a price column and the displayed value does not use it.
- Any snapshot of the estimate at approval. Editing an item's buying price revalues open and already-approved requests.
- Any comparison of the estimated value against what the resulting order actually cost.
- A value-tiered approval ladder on the requisition itself.
- A currency on the request. The estimate is in the organisation's base currency by construction.
Not ours, by choice
- The net-of-stock calculation is genuinely good and we would rather you knew it was there than not.
- For a business buying local goods at stable prices, the catalogue estimate is a perfectly reasonable proxy and none of this will trouble you.
- Nothing here is Bahraini. It is what a catalogue-derived estimate does when prices move; an import-heavy supply chain simply makes them move more.
What is not built for Bahrain today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Bahrain. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If an NBR e-invoicing pipeline once the format is published, an Arabic interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The zero rating, and the evidence that holds it up
Electronic invoicing against whatever the National Bureau for Revenue publishes, built when there is a format to build against. The nearer-term work is the one that costs Bahraini exporters real money: a zero-rated cross-border supply that carries its own proof — customs entry, transport document and delivery evidence attached to the invoice rather than filed somewhere else — so the rating survives a review instead of being reconstructed during one.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds, card acquirer settlements and instant-payment files wired into the Payments Register.
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.
Payroll and statutory returns
A Bahraini payroll engine with Social Insurance Organisation contributions on live employee records, wage files in the layout the Labour Market Regulatory Authority expects, and the Bahrainisation position visible before a deadline rather than after one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions about request values, in any system
Where does the value on this request come from?
A good answer sounds like
The requester, or a catalogue price — stated either way.
What it actually means
Ours is the catalogue. Both designs are defensible; not knowing which you have is not.
Change the item price. What happens to an approved request?
A good answer sounds like
Nothing — the approved value is snapshotted.
What it actually means
Ours revalues. A decision recorded against a number that can move is a weaker record than it appears.
Show me estimated against actual for last quarter.
A good answer sounds like
A report.
What it actually means
This is the number that tells you whether your item master is worth trusting, and almost nobody has it.
Does the request net off stock I already hold?
A good answer sounds like
Yes, floored at zero.
What it actually means
Ours does. It is a small thing that prevents a large and common error, and it is worth asking about elsewhere.
Our position
Treat the request value as an indication and the order value as the decision point. Keep buying prices current on your top twenty items and accept drift on the rest. Do the estimate-versus-actual sample once a quarter, and make it an explicit rule that nobody edits a buying price in order to change an approval — because the moment somebody realises the estimate is catalogue-driven, that becomes possible.
Find out how stale your item master is
Take twenty items, compare the buying price on each to your last actual [invoice](/glossary/invoice), and you will know within an hour whether your request values mean anything. We will do it with you.
Check the catalogueFrequently asked questions
Can the requester type an expected price?
There is a price column on the requisition line, and the value shown on the request is not computed from it — it comes from the item master. So anything typed there does not change what the approver sees.
When does a real price enter the chain?
At the quotation. That is a supplier-stated figure with a currency and a validity, and it is what the purchase order is built from. Everything before it is an estimate from your own catalogue.
Should we update buying prices from every invoice?
On your high-volume items, yes, and it also improves your weighted-average cost and every margin figure built on it. On a long tail of occasional purchases the effort is not worth it — accept that those requests carry a rough number and approve them on quantity and judgement.
