The Price You Set Once
An item has one selling price and it is a field. Change it and the old value is gone — no revision, no effective date, no history, and no way to say what you were charging in March. The documents remember. The item does not.
In a stable market, a price is a fact you set once and revisit annually. Where prices move quickly it becomes something else entirely: a decision you make repeatedly, under pressure, across a whole catalogue, and one you need to be able to explain afterwards.
Our item record was designed for the first kind of market.
What a price is here
A field. An item carries a buying price, a markup percentage, a selling price and whether that price includes tax. Each is a single value.
Change the selling price and the previous one is overwritten. There is no revision record, no effective-from date, no scheduled future price and no history table anywhere in the product. The question "what were we charging for this in March?" has no answer on the item.
The documents remember what they were sold at. The catalogue remembers only the last decision.
What does survive
This is the important qualification and it is more than a consolation.
Documents snapshot their own financial context. A quotation raised in March holds the price it was raised at, along with a record of the financial conditions at the time; an invoice does the same. So an old document reads correctly forever, and nothing you do to the catalogue rewrites what a customer was actually charged.
Which means the history is not lost — it is distributed. It exists across thousands of documents rather than in one place you can query. Reconstructing a price series for one item over a year is possible and it is an archaeology exercise.
The four things you cannot do
| What you want | Why it is not available |
|---|---|
| See when a price last changed | No revision record exists |
| Schedule a price to take effect on a date | A price has no effective-from field |
| Reprice a category by a percentage | No bulk repricing tool; each item is edited individually |
| Show a price history to a customer who asks | It has to be assembled from their past documents |
| Know who changed a price | The item carries a last-modified stamp; nothing records what changed |
The third row is the one that costs the most hours. In a fast-moving environment repricing is not an annual event; it is a recurring operational task across a large part of the catalogue. Doing it item by item is not merely slow — it is slow enough that it gets postponed, and a postponed reprice is a margin you are giving away.
The safety net that does exist
There is an anomaly radar in the product, running per organisation, and everything it watches is a pricing condition: items selling below cost, items on unusually thin margins, and items priced at zero.
Those three are exactly the errors a manual repricing exercise produces. A decimal point in the wrong place gives you a zero-priced item. A cost that moved while a price did not gives you a below-cost sale. A partial reprice — half the category updated, half not — gives you thin margins on the half that was missed.
So the product cannot help you reprice and it will tell you when you have repriced badly. Use it. In an environment where costs move faster than anybody can keep up with, that radar is the difference between a bad week and a bad quarter.
-
Reprice from the cost side, not the price side
Keep buying prices current and use the markup percentage as your instrument. A price derived from a maintained cost drifts less than a price maintained directly, and it also improves every margin figure in the product.
-
Do it in passes, by category, on a fixed rhythm
A whole-catalogue reprice is never finished; a category reprice is. Partial coverage is what produces the thin-margin anomalies, so finish what you start.
-
Read the anomaly radar the day after every pass
Not weekly. The day after. It is the only automated check on the work you just did, and its findings are most interpretable while you still remember what you changed.
-
Keep your own price register if you need history
A dated spreadsheet, one row per change. Unromantic, and it is the only way to answer a question about March that does not involve reading invoices.
Four questions about price management
What was this item's price six months ago?
A good answer sounds like
A history, on the item.
What it actually means
Ours cannot answer it from the item. Ask before you assume — every system shows a current price and few store the previous ones.
Can I schedule a price change for the first of next month?
A good answer sounds like
An effective-from date.
What it actually means
Without it, every price change happens the moment somebody saves, which means repricing has to be done out of hours or done visibly.
Reprice a category by twelve per cent. Show me.
A good answer sounds like
A bulk tool.
What it actually means
Ours has none. The time cost of item-by-item repricing is the single largest hidden cost in a fast-moving price environment.
What catches a mistyped price?
A good answer sounds like
A named check.
What it actually means
Ours has three, and they are genuinely useful. Ask what happens after a bad reprice, not just how repricing works.
What AWRA OpsHub does today
- A buying price, a markup percentage, a selling price and a tax-inclusive flag on every item.
- A weighted average cost maintained from purchases, shared by the till, the ledger and margin analytics.
- Financial snapshots on quotations and invoices, so a document raised at an old price reads correctly forever.
- Anomaly detection on pricing — below cost, thin margin, and zero price — cached per organisation.
- Per-line price editing on every sales document, so a negotiated price is always possible.
What it does not do
- Any price history or revision record on an item. Changing a price overwrites the previous value.
- Effective-from dates or scheduled future prices.
- Bulk repricing by category, supplier or percentage.
- A record of who changed a price and what it was before.
- Price lists or customer tiers, which is a separate absence — see One Price for Everybody.
Not ours, by choice
- The document snapshots are the reason this is a reporting inconvenience rather than a correctness problem. What a customer was charged is never in doubt.
- The anomaly radar is a genuine safety net and it is pointed at exactly the errors manual repricing produces. It is also under-used, because nobody knows it is there.
- Nothing here is Argentine. It is what a scalar price field does when prices move; this is simply where they move fastest.
What is not built for your market 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 your market. 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 the seam to a clearance provider, a supplier invoice that can be read, a limit that is not an amount, 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.
Which end of the document you stand at, and what the limit is written in
Three builds cover most of what this region exposes, and the first is a seam rather than a system. Document exchange with the authority runs through a role somebody is accredited for, so what we build is the two-way join to the provider you pick — our document handed over in the shape they expect, and the reference, status and any acknowledgement written straight back onto our record, which is what turns "which of ours are not yet cleared" into a report rather than a reconstruction. Second, reading a supplier's electronic invoice into lines that carry tax, so the purchase side holds a rate and not only an amount. Third, a limit expressed as a multiple of an index unit rather than as a sum of money, with something that actually reads the unit when it is revalued. All three are data-model changes rather than settings, and we would quote them as such.
Local payment rails, and obligations that fall on the buyer
Statement feeds and local payment rails wired into the Payments Register, alongside the buyer-side obligations this region is unusual for — an acknowledgement generated from a receiving event and transmitted, and a report of purchases received but not yet acknowledged. Receiving against the order already runs; the outbound half is the buildable part on top of it.
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 local payroll engine with income tax tables and social security contributions computed on live employee records, producing returns in the layout your authority expects rather than rebuilt each month.
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 integratedReprice from cost, and read the radar afterwards
Two habits that cost nothing and remove most of the risk in a fast repricing cycle. We will go through your markup structure and set the rhythm with you.
Set the rhythmFrequently asked questions
If I change a price, do old invoices change?
No. Documents snapshot their own financial context, so an invoice raised at the old price keeps it permanently. That is the right behaviour and it is why the missing history is an inconvenience rather than a correctness problem.
Can I import updated prices in bulk?
Item data can be loaded in bulk, and the practical caution is that a bulk load is a blunt instrument with no preview of what will change and no history to compare against afterwards. If you use it, run the anomaly radar immediately and check a sample by hand.
What is the single most useful habit here?
Keeping buying prices current and driving selling prices from markup. It makes repricing a smaller task, it makes your weighted average cost meaningful, and it makes the below-cost anomaly check actually able to do its job — which it cannot if your recorded costs are a year old.
