Setting Up Individual Prices for B2B Clients in 1C-Bitrix

Individual prices in Bitrix: where the B2B price list breaks

Individual prices in Bitrix break not during discount calculation, but earlier — at the data model level.

The catalog in 1C-Bitrix returns a value from the price type linked to the product, while the contractual terms of a specific client usually live outside the system: in a manager's spreadsheet, a separate file, or in correspondence.

As long as prices for B2B clients are not linked to the buyer profile, the site physically does not know that this counterparty is entitled to different terms.

Then the failure unfolds in a chain. The cart calculates the order using the base price type, the personal discount is not picked up, and the order goes out with the wrong amount.

The manager notices the discrepancy after checkout — and manual order recalculation begins: editing line items, reissuing the invoice, re-syncing with the accounting system.

The cost of such a scheme grows with every order. Price list errors multiply into invoices and shipments, accounting gets discrepancies, and the client gets a reason to doubt the numbers.

With a stream of B2B orders, recalculation stops being an exception and becomes the norm, which means the catalog cache also stops working: prices are calculated on the fly for each user.

We analyze how this is resolved: where to keep contractual prices, how to link them to the counterparty, and what to check so the cart calculates correctly on the first try.

What changes after implementing individual prices

Contractual terms stop living in correspondence and manager spreadsheets — they are transferred into the catalog as a separate price type linked to the counterparty.

A client under their own account sees their own values, and the cart calculates from the contract, not from the retail price list.

In 1C-Bitrix this is assembled using standard price types and user groups, so the logic stays inside the system rather than in an add-on that is scary to update.

Order placement speed grows due to automatic price calculation: an order with 40 line items is assembled in 5-7 minutes instead of 40, and a repeat order is pulled from history with the terms already applied. The manager no longer reconciles every line — they check exceptions, of which only a few remain.

Pricing errors disappear as a class because the rule is applied at a single point — during cart calculation on the server side. Contract percentage, volume discount, individual line items under special terms — all of this is one place, not ten copies in invoices.

A contract revision or price list update takes effect immediately, without mass retroactive editing of documents.

Separately, the most costly failure disappears: an invoice goes to the client with the old price when the contract has already been signed under new terms.

When the value is calculated from current terms on every order, and changes are logged, such a scenario simply cannot be reproduced — the history shows which rule produced the amount.

Ways to set a price: comparison of approaches

There are four mechanisms for setting a price in the catalog: price type, price agreement, discount rule, and personal terms.

They are not interchangeable — the choice determines how the price list behaves when exporting the product range from 1C, when moving a client to another group, and when repeat purchasing from order history.

In practice, the working scheme is a combination: an agreement sets the base level, discount rules and group markups calculate deviations by volume and category, and personal terms cover exceptions.

The one condition for stability is that the chain "counterparty → agreement → price type → line item" must be recorded in the order; otherwise, after the catalog update, the client sees one price but receives another in the invoice.

Stages of implementing personal pricing

Individual prices in 1C-Bitrix live at the intersection of the catalog, discount rules, user groups, and access rights. An error in priority — and the client sees someone else's price or an amount without the agreed discount, and the manager learns about it from a phone call.

That is why pricing implementation proceeds in stages, where each step is verifiable before moving to the next.

1. Audit of pricing rules. We collect everything that affects price: price types, discounts, markups, user groups, manual edits in orders, contractual terms from spreadsheets. We record conflicts — cases where two rules claim the same line item.

2. Priority scheme. We agree on a matrix: what wins when terms overlap, where the contract's fixed price is, which price is shown when no rule applies. Separately — what a guest and a retail buyer see.

3. Linking clients. We define the relationship between the user and the company and contract, so that one client's price list is not accessible to another. We check closed sections and catalog exports.

4. Configuration. We implement the scheme using the platform's standard mechanisms, and if they are insufficient — with an extension. We configure the recalculation order and caching so the catalog does not lose speed.

5. Test orders. We run scenarios: guest, retail, client with one contract, client with two contracts, status change, order before payment. We reconcile the price in the cart, invoice, and document.

6. Handover to operation. We provide the procedure for adding a new client, instructions for the manager, and a price change log — edits stop coming back to the developer.

Acceptance is based on a scenario checklist: until all branches produce the expected price, the stage is not closed.

Documentation, schemes, and pricing procedures

Price configuration without documentation lasts until the first departure of the person responsible: only those who set up the rules remember them.

That is why the handover includes not only a working mechanism but also a set of artifacts by which a new employee or contractor can reproduce the logic without oral explanations.

• Price priority scheme — a table that records the order of precedence: price from the client agreement, price from the linked price list, group discount, catalog promotion, base price. With examples: which rules override each other and why the result on the card is exactly that.
• Terms matrix — which client type is linked to which price list, through which agreement details, what to do with a client without a contract, and how to behave when the group changes.
• Pricing procedure — who creates the price, who approves it, at what point the edit reaches production, and how a rollback to the previous price list state is formalized.
• Instructions for managers — a step-by-step scenario: link a client to a price list, check the price in the cart and order, see a discrepancy, and send it for review. A separate block — common errors and what they break.
• Catalog documentation — which properties and price types are used, how they are linked to trade offers and warehouses, and by which event the price in an order is recalculated.
• Exchange map with the accounting system — a list of details that are synchronized and fields that must be filled on the accounting side, otherwise the price will not arrive.
• Change procedure — the rule owner, the point where edits are made, the test environment, and the verification checklist before publication.

The documentation is tied to the actual configuration, not written abstractly: each item references a specific rule or field that can be opened and checked. We close the handover with a review session with managers and support — it shows which places still require clarification.

Case study: how we removed manual price lists for a distributor

A distributor with a distributed partner network kept contractual terms in spreadsheets: each client had their own discount by product groups, deferred payment, and individual line items for a project.

The price list was exported from the accounting system, finalized manually, and sent to the partner by email — by the time of the order, it already diverged from current prices.

Every order came back to the manager for recalculation: verify the contract, apply the discount, confirm.

Order placement took up to 40 minutes, about a third of orders went through manual recalculation, and price discrepancies were already being looked for in correspondence with the client.

What we changed

On 1C-Bitrix, we built a B2B catalog where the price for a partner is calculated by the system according to their contract.

The client profile is linked to the price type and discount rules, section visibility is limited by the contract, and the product range and prices come from 1C via a scheduled export — without intermediate spreadsheets at the managers' side.

What changed: order placement was reduced to 5-7 minutes, the share of orders with manual recalculation fell to 2%, and support requests about prices decreased fourfold.

The discount policy became uniform for the entire network, and managers stopped being intermediaries between the partner and the catalog.

How price agreements differ from discount rules

These are two different mechanisms, and confusing them is a common cause of "floating" prices for a wholesaler.

A price agreement fixes the contractual price at the level of a price type linked to a company or buyer group: the client sees it in the catalog, and the same price goes into the cart.

A discount rule does not store a price — it reduces the existing one at the moment of cart calculation, so its result depends on which price was applied earlier.

Overlapping terms are the main source of price rule conflict. If cumulative discounts or a rule limiting the price from below remain active for a group with individual prices, the cart will recalculate the contractual price under the general terms.

The priority of terms is not set "by itself": first the price from the agreement is applied, then only those rules are applied that are explicitly allowed for this price type.

So that the fork does not turn into manual edits, for a group with agreements, cumulative discounts are usually disabled, rules are limited by buyer groups, and behavior is tested on a test buyer with a mixed set of products.

In this case, the cart calculation log shows which price and which rule were applied — the incident is analyzed step by step, not by trying settings one by one.

Common doubts about setting prices in the catalog

Doubts at the configuration stage usually concern not the individual pricing mechanism itself, but its consequences: what happens to already placed orders, how the exchange with the accounting system will react, and whether a condition can be set for only some clients. Below are answers to the questions most often raised in acceptance discussions.

Can a condition be set for only some clients?

Yes, the price is linked not to a person but to a client group and an agreement. The client falls into the required group — when entering the catalog, they are served their price list, while others see the base one.

One client can belong to several groups; in that case, priority is set explicitly so there is no ambiguous choice.

Partial terms are configured in the same way: a discount for a separate category, a fixed price for an agreed list of line items, a minimum order quantity. The rest of the catalog works under general rules.