White Paper: Standardise and Make Pricing Universal Across Any Business And Ecommerce System

One the of the greatest challenges each business (or what we more generally call an organisation) faces today is being able to have each of its employed business systems effectly communicate and transfer data with each other. In the world of commerce this is amplified by the need of each organisation's customers and suppliers also needing to integrate, communicate and transfer data with each other efficiently online.

Nothing could be more important than how each organisation controls how it's goods and services are priced across its customer base,  as well as how it is charged to pay for the goods and services from its supplier base. As organisations grow, relationships are uniquely forged, and the need to set up more complex pricing structures may become apparent. What starts as a small amount of goods and services being sold at a single price across all customers, can often morph into selling products at varying rates on several factors, that may include: 

• The volume of goods and services being purchased
• How unique a trading relationship is between one or more customers/suppliers
• How many geograhic locations goods and services are being sold in
• Special one-off or ongoing deals and promotions to increase gross sales
• The volume of goods and services able to be manufactured or found from suppliers
• Industry and government taxes, surcharges, tariffs, and pricing restrictions
• Many other factors

With all the varying rules that may exist for pricing, it can require simple to sophisticated systems to manage all the pricing rules. This is typically handled by accounting systems, Enterprise Resource Planning (ERP) systems, or may be managed through custom made spreadsheets and other pricing systems.

Where this pricing become problematic is when the pricing rules and structures need to be brought into associated Ecommerce, online trading, and marketplace platforms (like SQUIZZ.com) that facilitate buying, selling, and/or price list sharing.

If all the pricing rules are stored within an accounting/ERP system or spreadsheet, then for Ecommerce platforms, they need to be able to apply the same rules when supporting selling through these online market places. It especially becomes apparent with a platform like SQUIZZ.com where it supports retail, wholesale, business-to-consumer (B2C), business-to-business (B2B), and business-to-government (B2G) relationships. Not only that, but being able to host and transfer complete price lists to customers, or from suppliers that is up-to-date, and transfers fast, is of greater necessity in an increasingly online world.

With this in mind, having accounting, ERP, and pricing systems store pricing in their own custom structures becomes problematic to support universal data sharing. It can make it very difficult for connecting systems to know how to correctly price products, and requires deep understanding of the underlying pricing structures in each of these systems to make an integration work.

Here at SQUIZZ.com we have spent many years developing our Connector software to be able to integrate pricing with several business systems, and after many integrations we found a way to make unique pricing structures become universal, even for complex customer relationships. By harnessing our open source Ecommerce Standards Documents library, it supports efficiently transferring and storing pricing in a universal standard, utilising a universal pricing structure that supports determining the correct price for an organisation's products, for any given customer, based on a certain quantity required at the current time, all within a fraction of a second.

This white paper shares our universal pricing engine, how it utilises our open source pricing standards, in the hope that more business systems and software adopt it, enabling much faster and automated of sharing of pricing. This can lead to reduced costs and efficiencies, across all key stakeholders: developers, organisations, marketplaces. This is what helps powers the "Connect Once, Trade With Anyone Connected" philosophy we strive for.

The universal pricing engine employed within the SQUIZZ.com platform, supports all organisations selling products on the platform for business-to-business (B2B, wholesale), business-to-consumer B2C (retail), and business-to-government (B2G) trade. 

This pricing engine is able to find and choose a price for each organisation's product, for a specified quantity and sell unit, for each unique customer. It allows each product to contain many different prices, and select the most appropriate price based on the customer who's viewing/ordering the product.

The pricing engine supports looking up 1000s of products, and pricing each product fast, ensuring the correct price is shown for the customer (person, or organisation) accessing the pricing, based on the trading relationship set up.

This pricing engine can be utilised to support many pricing structures that various types of business systems employ, including: 

• base selling prices
• contracts
• promotions,
• recommended retail prices (RRP, MSRP)
• customer specific pricing
• price-levels
• pricing groups
• volume discounts/quantity break prices
• forced pricing
• customer account discounts

The pricing engine is universal. This means the same universal pricing algorithm is employed for all organisations trading on the platform, regardless of the business system they employ in their own back end. It can do this by having an organisation's pricing rules and data standardised when imported into SQUIZZ.com, whilst still being able to uniquely price products for specific customers. 

The universal pricing algorithm is broken into 5 parts:

• Customer Accounts
• Price Levels
• Product Price-Level Unit prices
• Product Price Level Quantity Prices
• Product Customer Account Pricing

Outside of this, pricing also includes applying taxes as well as adding on surcharges (freight fees, payment fees, etc..), but this aspect is left out of this paper for now, as the focus is on core pricing.

Each organisation may import any number of customer accounts into SQUIZZ.com. Each customer account may represent an individual person, organisation, or a collection of people/organisations. The “customer account” forms the back bone of a trading relationship. It is used to control the pricing that targeted people or organisations have access to. 

One customer account can be assigned to any number of people, organisations, or selling regions. For example, an organisation may set up a general customer account called “WEB RETAIL” that allows pricing to be set at a retail level for any off-the-street people who wish to buy products online, such as when visiting a retail store or retail marketplace. Another customer account may be created to represent a specific organisation who buys consistently at higher volume, such as a distribution partner.

Each customer account typically represents a “debtor” within an accounting/enterprise resource planning system, that records all transactions (sales, credits, payments) made by a customer.

Each organisation may import any number of price levels into SQUIZZ.com. For each product it can have a price set for each price-level and sell unit. So if an organisation had 5 price levels defined, then for each product it could have 1 price set per price level, allowing 5 different prices to be set for a sell unit of a product. Price levels may be named to indicate the kinds of prices each level collectively stores. For example:

"Organisation A" Price Levels:

1. Recommended Retail Price Level
2. Retail Price Level
3. Wholesale Price Level
4. VIP Customers Price Level
5. Diamond Customers Price Level

If "Organisation A" was selling “Product X” as individual sell units (EACH), then it could have the following prices defined for the product:

1. Recommended Retail Price - Level: 
   $1,234.34 AUD EACH
2. Retail - Price Level: 
   $1,003.85 AUD EACH
3. Wholesale - Price Level: 
   $965.94 AUD EACH
4. VIP Customers - Price Level: 
   $653.23 AUD EACH
5. Diamond Customers - Price Level: 
   $323.00 AUD EACH

As we can see the price range for Product X is sold between $323.00 - $1,234.34 AUD for each sell unit.

Each customer account can optionally be assigned to at most one price level. This then controls the price-level price that is chosen for a customer when viewing a product. It's up to each organisation to choose to most relevant price-level to assign each their customer accounts to.

Note that an organisation can choose to ignore assigning a customer account to any price level.

Price Levels provide a way for a selling organisation to set multiple prices for each product, and control which of these prices each customer can receive.

Additionally one price level can be used to define the Recommended Retail Price (RRP) of a product for each selling region (for example Australia). This allows customers to compare the price they receive for a product, verses the recommended retail price that could be set by manufacturers.

Besides Price Levels being used to define multiple prices for a single sell unit of a product, quantity breaks (also known as volume discount prices) can be set up for each price level. This means that if a customer (person or organisation) orders a certain quantity of product, then they are allowed to receive a cheaper price of a product.

Following on from the example above the following quantity breaks could be set up for example “Product X”:

1. Recommended Retail Price - Level: 
   1. $1,234.34 AUD EACH
2. Retail - Price Level: 
   $1,003.85 AUD EACH
   1. Buy 5 for $999.34 AUD EACH
   2. Buy 10 for $955.34 AUD EACH
   3. Buy 15 for $930.34 AUD EACH
3. Wholesale - Price Level: 
   $965.94 AUD EACH
   1. Buy 3 for $880.00 AUD EACH
   2. Buy 7 for $870.00 AUD EACH
   3. Buy 8 for $850.00 AUD EACH
   4. Buy 12 for $810.00 AUD EACH
4. VIP Customers - Price Level: 
   $653.23 AUD EACH
   1. Buy 4 for $620.00 AUD EACH
   2. Buy 7 for $600.00 AUD EACH
5. Diamond Customers - Price Level: 
   $323.00 AUD EACH
   1. Buy 100 for $120.00 AUD EACH
   2. Buy 1000 for $60.00 AUD EACH

As we can see for each product and price level any number of quantity break prices may be defined. The first price level labelled “Recommended Retail Price” contains no quantity prices,  the 3rd price level labelled “Wholesale” has 4 quantity prices set up. As a customer orders more quantities of a product, they may become eligible to receive reduced per unit prices. 

Organisations typically set up this pricing structure to sell at volume, compelling customers to purchase more. Customers can see the quantity breaks/volume discounts, so are aware of the discounts they can expect to receive.

Quantity Break Direction

For each organisation, there is a setting that controls the “direction” that all quantity break prices may be applied as:

• Above 
  A quantity break price only applies if the quantity a customer is ordering is over the quantity the price applies to.
   
• Equal To or Above
  A quantity break price only applies if the quantity a customer is ordering is equal to or over the quantity the price applies to.
   
• Below
  A quantity break price only applies if the quantity a customer is ordering is below the quantity the price applies to.
   
• Equal To or Below
  A quantity break price only applies if the quantity a customer is ordering is equal to or below the quantity the price applies to.

In the example above, if the organisation setting the pricing has its Quantity Break Price Direction set to "Above", then customer accounts assigned to the “VIP Customers” price level would need buy more than 4 individual sell units to receive a cheaper price of $620.00 AUD. That means they may need to buy at least 5 quantities of product to receive the cheaper price.

If multiple quantity break prices are applicable to the quantity that a customer account's price level has, then the pricing engine will choose the cheaper of the price-level quantity prices that are eligible.

Each organisation may import any number of pricing records that are directly assigned to each of their customer accounts. This allows direct product pricing to be made available to solely a single customer account, and is typically done to provide special or exceptional pricing that customers are allowed to receive for a targeted range of products. These customer account prices could be based on contracts, promotions or special price rules that have been set up for select customers.

Product Customer Account Prices can be applicable to single sell unit of a product, or be set as a quantity break (volume discount) price. This means that the pricing engine could by default choose a customer account's associated price-level price, then if a certain quantity break is reached, choose a customer account specific price instead. This is another way to give customers volume discount pricing if they are order more.

Price Groups

Product customer account prices can also be assigned to a price group instead of a specific customer account. A “price group” consists of a group of customer accounts. Each price group can have product customer account prices assigned to it, allowing a collection of customer accounts to receive the same price for a selected product.

Price Groups are very powerful to use, since they can reduce down the amount of pricing records that need to be imported into SQUIZZ.com, but still apply the unique pricing to a target group of customers.

Forced Prices

By default the pricing engine will try to find the cheapest product price available for a customer account. It will look at all the applicable price-level unit prices, price-level quantity break prices, and customer account prices. For customer account prices there is the ability to flag a price as being a “Forced Price”. This means that the pricing engine will choose a forced price, even if there is a cheaper price-level price, or customer account price available.

Forced pricing is used to lock in prices, such as if a contract had previously been agreed to for a a period of time. This may provide more certainty to customers, or be a requirement of having a trading relationship.

If multiple forced prices are applicable to a customer account, then the pricing engine will choose the cheapest of the forced prices.

Within each of the SQUIZZ.com platform's API endpoints list below, they show how to structure and import the product price-level unit pricing, product price-level quantity pricing and product customer accoung pricing data exports.

3 endpoints use the Ecommerce Standard Document's “Price” document type to structure the pricing and price group records. The price levels import uses the “Price level" document type.

In the above sections it explained how the SQUIZZ.com platform's pricing engine works to harness the product pricing data that is imported into the platform, via the open Ecommerce Standards Documents library.

Since the Ecommerce Standards Documents is open, any business system can harness the standards to transfer pricing data to/or from the system in a standardised, agnostic way. This can help automate trade, allowing price lists to be shared, and interpreted in the same way, leading to less costs, faster integrations, and better business intelligence.

Each business system that choose to implement the open pricing standards will invariably come to the problem, “how to convert our own price rules and structures into a universal open pricing standard” when sending out pricing data to SQUIZZ.com, or other supported Ecommerce platforms.

The Challenge

Many business systems that calculate pricing, do so only focusing on generating out a single price for a specified, product, customer, quantity and sell unit. The greater the amount of pricing rules, the greater amount of checks and calculations need to be performed to find a single price. This approach is fine if products are being added to an order/invoice one at a time, but it quickly fails if 100s or 1000s have to be loaded in a list within a very short period of time. This is the case for SQUIZZ.com and most other Ecommerce platforms that show product listings.

So what's the answer? Pre-calculation. 

Calculate the prices of products for customers for a given time, factoring in all the price rules, mark ups, discounts, to determine the relevant prices. If this is done well, and indexed in a database correctly, then when a customer wants to know the price of a collection of products for certain quantities and sell units, very little work needs to be done to find the correct prices. 

The question then becomes how to effectively calculate the prices over large lists of products and customers. There's a few different solutions to this.

Solution A: Maximum Entropy Approach (The Bad Idea)

If an organisation has 1000 products, 1000 customer accounts, and 10 price levels, and each price level has 10 quantity breaks, then simply generate pricing across all these factors. This means 1000 x 1000 x 10 x 10 = 100,000,000 individual price records. The problem is that calculating, transporting and storing 100,000,000 price records isn't very efficient, and in many cases business systems or Ecommerce platforms won't/can't handle that many records, SQUIZZ.com included.

Solution B: Group Prices Logically In Multiple Ways

In many business systems, they provide multiple ways to handle prices. An organisation typically wants to set up the least amount of prices to support their business activities, and employ several group/price rule mechanisms to do so, from the simple, to the very complex.

The Single Product Price Solution

Looking at the most basic of business systems, they may define one price per product, and all customers receive the same price. When that occurs it's fairly straight forward. Create one logical “price-level”, say call it “Base Price”, then assign each price to the 1 one price level.

For example if there are 1000 products, each has a single base price and a single sell unit, then 1000 price records need to be generated, all assigned to the 1 price-level.

The Multiple Price-Levels Solution

More advanced business systems will define multiple price-levels for each product. They may have a fixed number of price levels, or allow as many price-levels to be created as needed. In either case it's logical to use the price-levels data structures that the Ecommerce Standards Documents and the SQUIZZ.com pricing engine support. Each customer can only be assigned to 1 price level.

For example if there are 10 price levels, and 1000 products. It will cause 10,000 prices needing to be generated. Most programming languages could generate that in under 1 second.

The more advanced version of this is if each price level then defines quantity breaks/volume discounts, allowing discounted pricing to occur. So in our example if each price level had 10 quantity breaks, it would take  the pricing record count up to 100.000 records. Which is still not that large. The more difficult part for a business would be how to set and maintain those 100,000 price-level prices.

The Customer Account Pricing Solution

A business system may have pricing that is set up specific to customer accounts. This is typically more on an exception to the rule, since if a business grows and gets more customers it would then require more work to maintain and manage the individualised customer product prices.

For example if there were 1000 products, with a price set for 1000 customers each, then 1,000,000 price records would have to be calculated and passed. This is starting to become a lot of price records, but still manageable from a data calculation, data transfer and support situation on SQUIZZ.com

The Price Groups Solution

If we look at the previous solution, where there are 1000 products with a price each set for 1000 customers, in the majority of business cases there would be the same price for a product across several customers. When this occurs, we can derive a price group. We can get the number of customers who have the same product price, put them in a price group and assigned the price group to the one product price. 

If there were 1000 products, every 10 customers had the same prices across the 1000 products, then we could create 100 price groups, and for the 1000 products only 100,000 price records would need to be created.

Putting The Solutions Together

To standardise pricing from within any business system requires finding where products, customers and prices can be logically grouped together, and then choosing from the relevant strategies above that fit the price level,  customer account and price group structures to create the optimal standardised pricing data lists.

Common ways to find groupings are:

• Customers that belong to the same contracts.
• Customers that belong to the same price rule, or receive the same discounts/markups 
• Customers that are assigned to the same price levels, price regions, base prices

Other optimisations include:

• Ignoring pricing rules and contract that are currently not in effect. Only look at pricing that is current.
• Ignore customer accounts and products that are not active, or allowed to trade.

The worst case is that an organisation has a unique product price set for every customer for large number of sell units and quantity breaks, across a large set of products and customers. This would be very exceptional, since the effort to effectively manage the pricing would be extremely challenging to the business doing the selling, and for customers to understand who are doing the buying. In the case the amount of entropy in pricing would be too great for SQUIZZ.com. 

In the vast number of cases the platform's universal pricing engine, and open standards can be harnessed to support B2B and B2C trade for most goods and services, when the pricing logic is standardised by running it through pricing algorithms. There are exceptions to this, that may involve complex pricing calculations made on the fly (such as custom designed/manufactured goods), so we continue to explore how business implement differing pricing models, looking to expand our pricing engine and open Ecommerce Standards Documents library as needs arise.