One Price for Everybody
An item has one selling price. There is no price list, no customer group, no tier and no discount rule anywhere in the product. Every differentiated price your sales team gives is a decision a person makes on a document, every time.
The position, immediately
One price per item, held on the item. Differentiation is manual, per document, per occasion. If your commercial model is a single list with occasional negotiation, this works and you will never notice. If it is tiered — distributor, reseller, direct, volume band — the tiers exist only in your team's memory, and you should plan for that before go-live rather than discover it in month two.
Pricing structure is the thing buyers of business software most reliably assume is present, because every business has one and no business thinks of it as a feature.
Open the item record here and there is a selling price. One. Open the customer record and there is a credit limit, a balance, a currency and a status. There is no field that says what kind of customer this is.
What exists, exactly
On an item: a buying price, a markup percentage, a selling price, and whether the price includes tax. That is the pricing model in full.
On a customer: a currency, a credit limit, a balance, a country and a status. Plus custom fields, which will store whatever you like and change nothing.
On a document: whatever your salesperson types. A line price can be edited, and a discount at the till is recorded as an amount against the sale with a description — after the fact, as a record of what happened rather than a rule that produced it.
The system records the price you gave. It has no opinion about the price you should have given, because it has never been told there is more than one.
The four things a price list would have done
| What a price list does | What happens here instead |
|---|---|
| Applies the right price automatically | The salesperson remembers, or looks it up somewhere else |
| Makes the wrong price visible | Nothing compares the price given to a price expected |
| Survives the person who negotiated it | A rate agreed by somebody who has left is a rate nobody can find |
| Lets you change a whole tier at once | Every future document, individually, by hand |
| Reports margin by segment | Margin is per item and per sale, with no segment to group by |
The third row is the expensive one and it is the one nobody plans for. Commercial terms agreed verbally survive exactly as long as the relationship between the two people who agreed them. A price list is, among other things, an institutional memory, and this product does not have one.
Why a German commercial model runs into this early
Because tiered distribution is the normal shape here rather than an advanced one. A manufacturer or importer sells to distributors, to resellers, and sometimes direct, and each of those is a different price for the same article — not as a concession but as the structure of the market.
Volume banding sits on top of that, and annual agreements sit on top of the banding. None of those three layers has anywhere to live in this product, and the consequence is not that prices are wrong — your team will get them right — but that the correctness depends entirely on people and is invisible to any control.
There is a second-order effect worth naming. Because there is no expected price, there is no such thing as an unexpected one. Nothing can flag a line sold below the tier rate, because there is no tier rate to compare against. The only pricing checks in the product are absolute — an item selling below cost, on an unusually thin margin, or at zero — and none of them knows anything about who the customer is.
Four questions about pricing, for any vendor
Show me two customers getting different prices for the same item, automatically.
A good answer sounds like
A price list or a customer group, applied on the document.
What it actually means
Ours cannot. The demonstration to ask for is the automatic application, not the ability to type a different number.
What happens when I change a tier price?
A good answer sounds like
Every future document on that tier picks it up.
What it actually means
This is what makes a price list worth having. Without it a price change is a communication exercise.
Can you show me sales below the agreed price?
A good answer sounds like
A report.
What it actually means
Requires an expected price to exist. Where it does not, discounting is invisible unless somebody is looking at each sale.
Where do volume breaks live?
A good answer sounds like
A banded price list.
What it actually means
Volume pricing is the most commonly assumed and most commonly absent feature in this bracket.
Pricing structure is a build, and it has a natural order
These are not one feature. They are three, they stack, and the first one is worth far more than the other two combined — which is worth saying because most requirements documents ask for all three at once.
A price list, and a customer pointing at one
The foundation. One list per segment, one price per item per list, applied on the document. Everything else depends on it existing.
Volume bands within a list
Second, and materially smaller once the list exists. A quantity break is a row rather than a new concept.
A below-list exception report
Third, and the one that changes behaviour. Once an expected price exists, a sale below it becomes visible — which is the actual point of the whole structure.
No dates on a public page. Tell us how many tiers you run and how often the prices move, and we will come back with a written scope, timeline and cost.
Scope a price listWhat AWRA OpsHub does today
- One selling price per item, with a buying price, a markup percentage and a tax-inclusive flag.
- Per-line price editing on quotations, invoices and till sales, so a negotiated price can always be given.
- Discounts recorded against a till sale with a description and an amount, attributable to the sale.
- A currency and a credit limit per customer, with exposure computed across the balance and every open invoice.
- Anomaly detection on pricing — items selling below cost, on unusually thin margins, or at zero.
- Custom fields on the customer record, which will store a tier label and change no behaviour.
What it does not do
- Any price list, customer group, tier or segment. There is no such entity in the product.
- Volume or quantity break pricing.
- Contract or agreed pricing per customer, with an expiry.
- Any discount rule. Discounts are recorded after the fact, not produced by a rule, and are not tied to a customer.
- An expected price, and therefore any report of sales below one.
- Approval on a discount. A till discount is attributable and not gated.
Not ours, by choice
- For a single-list business — one price, occasional negotiation — none of this is a limitation and the product does what you need.
- The pricing anomaly detection that exists is absolute rather than relative. It knows what an item cost you; it does not know what this customer should have paid.
- Nothing here is German. It is what a single price does to a tiered market, and tiered distribution is simply the default shape here.
Write the tiers down before they walk out of the door
Even without a price list in the system, a maintained document naming every tier and every agreed rate is worth an afternoon. It is the institutional memory the software is not providing.
Talk about pricingFrequently asked questions
Can custom fields hold a customer tier?
They will hold the label, and nothing will act on it — no price will change, no report will group by it and no exception will be raised. It is worth doing anyway as documentation, because a tier written on the customer record is a tier your next salesperson can find.
How do people manage tiered pricing today?
A maintained price sheet outside the system, and discipline. The two habits that make it survivable are keeping the sheet in one place everybody can reach, and reviewing a sample of invoices monthly against it — because nothing in the product will tell you when somebody has drifted.
Does the point of sale respect anything customer-specific?
Not on price. The till sells at the item's selling price, and a discount is entered as an amount and recorded against the sale. Customer-specific behaviour at the counter is limited to credit control, which is real and works differently — a customer over their limit is genuinely held.
