Common pricing problems

The symptoms below cover most pricing support cases. Work down each list in order; the causes are roughly ranked by how often they turn out to be the answer.

The buyer sees no price at all

1. No entry exists on any list that applies to them. Filter Order Management › Prices › Price entries by the SKU. If the only entries are on lists bound to other accounts, this buyer has no price.
2. The buyer is not logged in and prices are restricted, either by Logged-in buyers only on every list that could apply, or tenant-wide.
3. Currency mismatch. The buyer's market is CHF and every list is EUR. Lists in another currency are invisible; they are not converted.
4. Market mismatch. Every candidate list is assigned to markets the buyer is not in.
5. The list is inactive, or outside its validity window. Both are visible in the price list grid.
6. The entry is deliberately On request. Working as intended.
7. The article is not visible in the first place, which is a catalogue problem rather than a pricing one. See Why a product is not showing up.

A customer sees the list price instead of their agreed price

This is the most-reported pricing case, and it is almost always one of five things.

1. The list has no account set. Check the Applies to column. An empty scope means the list applies to everyone, which usually also means somebody else is currently getting this customer's prices.
2. The agreement expired. Check Valid until on the list. A window that closed yesterday produces exactly this symptom, silently.
3. The article is not in the customer's list. Correct behaviour: uncovered articles fall through to the list price. Check the agreement.
4. The buyer is logged in as the wrong contact, or as a contact attached to a different organization. Check the account on their contact record; see Contacts and roles.
5. A campaign list at a higher priority is winning. A campaign at priority 50 beats a contract list at 10, even when the campaign price is higher.

Two customers on the same agreement get different prices

• Two overlapping lists exist for the same account, both active, with the same priority. The tiebreak rule then decides, and it decides consistently, so the two buyers must differ in something else, usually contact scope.
• One of them has a contact-bound list. A contact list beats an account list. Check whether somebody created a personal list for one buyer and forgot about it.
• They are on different markets and therefore different currency lists.

The price is 100× too high, or 100× too low

Almost always an import problem, and almost always affects a whole file rather than one article.

• Decimal separator. 19,90 parsed as a thousands separator becomes 1990.
• Price per 1,000 imported as price per piece, or the reverse. Check the unit on the entry.
• A currency symbol or thousands separator in the source column.

Sort a list's entries by unit price in both directions; the extremes expose this immediately. Then see Import prices in bulk.

An article is priced at 0.00

Someone exported ERP rows for articles with no maintained price, and 0.00 came along. A zero price is orderable and buyers do order at it.

Find them by sorting entries by unit price ascending. Delete them or convert them to On request, then fix the export filter so they do not come back next month.

A price change is not showing up

1. You changed the wrong list. Editing the standard list does nothing for a customer who resolves onto their own list.
2. Your ERP overwrote it. If the ERP is the system of record, a manual Cockpit edit survives until the next sync. Fix it upstream; see Where your prices come from.
3. The import ran into a different list, or into the right list under a SKU that does not match the catalogue's.
4. Caching. Storefronts cache prices. A price change announces itself so caches can be invalidated, but if your storefront or a middleware caches on its own terms, ask whoever built it what the window is before assuming the price is wrong.
5. The change was applied as a preview. A bulk adjust with Preview only on writes nothing.

A scale ladder is not applying

• No rung at quantity 1. Small orders then resolve to nothing.
• The winning list has only a single rung. A contract list that prices an article once, at quantity 1, gives that customer no scale prices for it; the standard list's ladder does not merge in.
• Duplicate rungs at the same from-quantity in one list. One of them is dead.
• The rung sits between packaging quantities and is effectively unreachable.

See Scale and volume prices.

The tax is wrong on the invoice, but the shop looked right

1. The list does not state net or gross. The amounts then mean whatever the tenant setting says, and that setting may have been changed for another reason. The list detail shows a warning banner when the basis is unstated.
2. The market could not be determined, so the rate came back unknown. Unknown is not zero, and nothing downstream may treat it as zero.
3. The article's tax class is wrong: a reduced-rate article on the standard class, or the reverse.

See Currencies and tax.

When to stop and ask for help

Escalate when the resolution trace and the Cockpit disagree: you have walked the order, exactly one list should win, and the buyer still sees something else. Bring the four facts, the list you expected to win, and the price the buyer saw. Without those three things the investigation starts from zero.

Next

• Price list hygiene — the maintenance that prevents most of the above.