Wholesale prices in Bitrix: where order recalculation breaks
Wholesale prices in Bitrix most often break not when rules are configured, but during price recalculation in the cart.
A customer reaches the volume, formally passes the threshold, but the order keeps the retail price — the order volume discount either did not apply at all or affected only some items.
The manager discovers the discrepancy after checkout, manually recalculates the discount and confirms it by email: the order goes into correspondence rather than the system, and it can no longer be reproduced from documents.
The reason is usually that the rule is tied to an event rather than the state of the cart.
The discount triggers when an item is added, but is not recalculated when the quantity is changed directly in the cart, when the price is re-requested from the accounting system, or when a cached catalog card is served.
If the threshold is calculated per line rather than by the total order amount, a large customer gets wholesale terms on one item and retail on the rest — and this looks like a store error rather than a pricing policy.
The cost of such a breakdown is measured not in the discount but in manual work: each volume confirmation is a separate email, a separate reconciliation, and a risk of erring in the customer's favor or your own.
Plus lost control: marketing cannot see which thresholds actually work and which managers bypass manually.
We explain how this is closed: the threshold must be calculated across the entire cart, the price must be recalculated on every change of composition and quantity, and the agreed discount must be recorded in the order as a separate line rather than in the body of an email.
What order volume price management provides
Volume thresholds are set declaratively: for each product group, levels are described — from what quantity or item amount the price changes, how the discount is calculated, and how the result is rounded.
The rules are applied during cart recalculation, so the price in the catalog, in the cart, and on the invoice is the same number.
Before implementation, a large order was calculated manually: the manager selected the discount level from a table, recalculated the lines, and totaled the result on the invoice.
This led to two classes of errors — a missed volume threshold and incorrect rounding, along with recalculation after every change to the order composition. 1C-Bitrix closes this by keeping the rules in settings rather than in an employee's head.
Automatic discount calculation removes both classes of errors: the threshold is applied based on the actual order composition, and any change to an item immediately recalculates the total.
The share of manual recalculations drops to single-digit percentages, and the processing time for a large order is reduced severalfold — the manager agrees on terms, not arithmetic.
The manager's workload shifts to exceptions: special terms, deferred payments, individual agreements that are deliberately excluded from the general rules.
The priority of rules and rounding order are fixed once, so the result is reproducible with any employee and in any channel — a self-service order on the website or checkout through a manager.
Calculation options: from percentage discount to price matrix
Wholesale price calculation in 1C-Bitrix is assembled in four ways, and they are not interchangeable: a percentage in a separate price type, a volume discount at checkout, a price matrix, and individual agreements with a counterparty.
Each option has a limit beyond which it starts to get in the way — usually the moment a second wholesale level or a new customer group appears.
Comparison of options
| Option | When it fits | Limitations |
|---|---|---|
| Percentage in a price type | one wholesale level, stable terms | no gradation by volume, each new level is another price type |
| Volume discount rule in the cart | 2-3 thresholds, scale rarely changes | calculated at checkout, no price in the catalog, value changes on recalculation |
| Price matrix: volume × customer group | several segments, price known in advance | requires synchronization with the accounting system and an update policy |
| Agreement with a counterparty | one-off large purchases | maintained manually, scales poorly to a flow |
Price rounding and customer groups break the calculation most often.
The rounding rule must be the same across the entire chain: if the catalog rounds up, the cart calculates the discount from the unrounded amount, and the invoice comes with a third value, the manager recalculates the order manually and makes a mistake.
That is why we fix the calculation model in one place and describe the priority: what applies first — the price type, the discount rule, or the matrix. Then expanding the scale comes down to adding a row to a table rather than rewriting logic on a live catalog.
How we implement it: from catalog audit to policies
Before enabling a volume discount, we analyze how the catalog is actually structured: which price types are set up, how a trade offer differs from a product, and where prices are duplicated manually.
Without this, rules start to conflict — the discount stacks with the cumulative one, the threshold is calculated from the pre-rounding amount, and the manager edits the order by hand.
Work sequence
- Catalog and price type audit. We export the trade offer structure, the list of price types and their binding, and look for duplicates and products without a base price.
- Discount calculation scheme. We fix the thresholds — by quantity or by amount, the step between them, the behavior of a mixed cart, and the rule for rounding the total.
- Rule setup. We create price types and groups, cart rules and cumulative discounts, and set priority — so that two promotions do not apply to the same item.
- Integration with accounting. We configure the exchange of nomenclature and prices so that website thresholds do not diverge from accounting ones when the price list changes.
- Test orders. We run threshold boundaries, a mixed cart, a guest and an authorized customer, cancellation and return — and verify the price at each step.
- Documentation handover. We provide the calculation scheme, rule map, manager instructions, and the procedure for editing thresholds without a developer.
What remains in the system and in the documentation
Wholesale price setup does not end when the discount starts calculating on the storefront — your team keeps a set of artifacts that let the system be developed and handed over further without reconstructing the logic from code. Specifically, we hand over:
- Rule matrix — a table "customer type × order volume × base price → applied discount": thresholds, rounding, and priority when conditions overlap.
- Price type map — which types are set up in the catalog, which is considered the base one, which are hidden from the storefront, and where each is used.
- Calculation map — the path of the price from export from the accounting system to being recorded in the order, including recalculation when cart volume changes.
- Price list update policy — export frequency, the person responsible for it, and verification of control items after each upload.
- Manager instructions — connecting a customer to the wholesale price type, issuing an individual term, and actions for manually editing an item in an order.
- Price change log — who, when, and under which rule changed the terms; it is used to investigate a discrepancy between the invoice and the storefront.
- Support memo — typical price requests and the procedure: from checking the customer binding to rebuilding the cart.
This set is enough to change shipping terms without rebuilding the logic from scratch.
Case study: wholesale price list for a distributor network
A network of building materials distributors with four partner levels came with a problem: wholesale prices lived in spreadsheets that managers maintained manually. Below are the figures before and after moving the calculation to 1C-Bitrix.
Before implementation
Out of 40,000 catalog items, the wholesale price for 60% of orders was selected by hand: the manager opened the price list, found the column for the partner level and batch volume, and copied the value into the invoice. The average order was processed in 3–4 hours; during shipping peaks it slipped to the next day.
Discrepancies in invoices surfaced in 7–9% of shipments: the cart calculated the price under one set of conditions, while the exchange module with 1C applied another.
After implementation
We assembled price types for each partner level and a volume discount rule: the price is recalculated by quantity and line amount, with thresholds and fixed rounding. The discount does not stack with the personal one — the system chooses the more favorable one for the partner.
The share of manual recalculations fell to isolated cases — only individual contractual terms remained. Order processing time was reduced to 15–20 minutes.
The invoice is generated from the same rules as the cart, so invoice discrepancies have almost disappeared: disputed shipments are now investigated via the price change log rather than by manual recalculation.
How does a volume discount differ from a cumulative one?
A threshold discount is calculated from the current cart: once the volume is crossed, the item price is recalculated. A cumulative discount works differently — it looks at purchase history over a period and does not respond to what is currently in the cart. A contractual price is not about volume at all: it is assigned to a customer type.
| Option | How it triggers | Limitations |
|---|---|---|
| Threshold discount per order | Recalculates the item price when the quantity or amount in the cart exceeds the threshold | Remove the item and the price reverts; thresholds are set separately by product group |
| Cumulative discount over a period | Calculated from completed orders over a period and raises the customer level | Turns on after payment or shipment; on return, the level is recalculated |
| Contractual price by customer type | Fixed price for a customer group regardless of volume | Requires a customer type reference and exchange with the accounting system |
In 1C-Bitrix, all three mechanisms live in cart rules and can overlap on the same item. Then rule priority takes effect, and if it is not set deliberately, the customer will get what was calculated first rather than what you promised. That is why rules are separated by customer type and by product group.
Calculation conditions are fixed separately: what the threshold is calculated from — the amount with or without tax, whether delivery is included, and at what point the cumulative level is recalculated. These are the parameters that produce different results for discounts that look identical.
Technical questions on price calculation
Changing wholesale price calculation rules affects two independent layers: the rule by which the platform calculates the price in the cart, and the price already recorded in the items of a placed order.
The first is changed by settings, the second by data, and these are different operations with different risks. That is why there is always one answer to the question "will old orders be recalculated": no, until recalculation is run separately.
The exchange with the accounting system updates the price list by the combination "price type + SKU + validity period", so it is better to separate rule setup and price list updates in time — otherwise it is unclear what exactly changed the number. Below are the questions most often raised before launch.
Will the price change in already placed orders?
No. At the moment of checkout, the price is copied into the order item along with the discount — after that it is a historical fact, not a result of recalculation. Recalculating old orders is a separate operation with a log: which orders are affected, what it was, what it became. It should be run only where the discrepancy has already led to a dispute with the customer.
How is the price list updated from the accounting system, and what should be done with manual prices?
The exchange overwrites values for items that are linked to nomenclature and price type.
If a product's price is set manually or individually, the exchange will not touch it — such items need to be moved to a separate price type, otherwise the manual value will be lost without warning on the next upload.
Can individual prices be set for a retail network, and how can the setup be checked before launch?
Yes, through a separate price type and binding to a customer group: volume calculation rules continue to work on top of the base price.
Before launch, we run a control set of orders — boundary amounts, different customer groups, items with manual prices — to make sure the right rule triggers and old orders remain untouched.
Let's discuss the task and come back with a setup plan
Wholesale pricing breaks not on arithmetic but at the junctions: recalculation when the quantity in the cart changes, exchange with 1C, reapplying rules to an already placed order.
That is why the estimate starts not with the price list but with your data composition and the rules for discount behavior in disputed situations.
To discuss the task concretely and come back with a price setup plan, prepare:
- data composition: which price types are set up in the catalog and in 1C, which groups and sections the wholesale pricing applies to, and whether there are exception products;
- calculation scheme: thresholds by amount, item quantity, or volume — and what to do when an order fits several conditions at once;
- rounding and accumulation procedure: whether we round the total or each line, and whether discounts stack with active promotions;
- application points: product card, cart, checkout, customer email, document export to 1C;
- recalculation rules: how the price behaves when quantity is reduced, an item is canceled, or a partial return occurs;
- access restrictions: which managers can manually change the wholesale price in an order and how this is recorded;
- current catalog and exchange customizations, so the new logic does not conflict with what has already been written.
After the conversation, we will come back with an estimate, a calculation scheme, and a price setup plan — with stages, checkpoints on a test copy, and the procedure for deploying to the production website.
Describe the task in any convenient form: we will list what is missing for an accurate estimate and suggest how to close those gaps.