A price class is a grouping, not a price. The class sits on the customer record, and the price lists in the ERP are written against the class rather than against each account. Change the class on one customer and their whole price book changes with it. That is what makes contract pricing survivable when you have four hundred accounts instead of four.
Acumatica calls this a customer price class and lets a sales price be defined for a class, a specific customer, or everybody. Cin7 Core uses ten numbered price tiers plus per-customer custom prices. Most commerce platforms have something that looks similar, a customer group or a catalogue, but the resemblance is where the trouble starts: the storefront concept usually decides which set of products a buyer can see, while the ERP concept decides what the price is. Those are not the same job.
The practical test is to ask what happens when you move a customer from one class to another in the ERP. If the storefront picks up the new prices on the next sync without anyone touching the commerce platform, the classes are genuinely connected. If someone has to move the customer into a different group by hand, you do not have a price class integration, you have two systems that happen to agree today.
Why it decides a platform
Price classes are how a seller keeps contract pricing manageable at scale. If the storefront cannot model them, every account has to be priced individually, which nobody maintains for long.
Also called: customer price class, price group.
Last updated 2026-08-20.