The Bitrix24 and 1C pairing is where sales usually break down. A sales rep sees one stock level in the CRM, the warehouse shows another in reality, the price in the quote does not match what accounting will invoice, and a bank payment lands in 1C while the deal card still reads "awaiting payment." Two-way exchange closes this gap: products and prices flow from 1C to Bitrix24, orders and counterparties flow back, and payment statuses are pulled automatically. Below, with no marketing fluff: what actually gets synchronized, which configurations are supported, where things go wrong in Kazakhstan, what it costs, and how long it takes.
What "two-way exchange" means in practice
Exchange is not a single button but several independent data flows. It is important to keep them separate, because they are configured and break down individually. From 1C to Bitrix24 you typically push the catalog and reference data; from Bitrix24 to 1C you push whatever originates in sales.
- From 1C to Bitrix24: product catalog (items, SKUs, units of measure), categories/groups, stock levels by warehouse, prices and price types (retail, wholesale, dealer), and product images.
- From Bitrix24 to 1C: new orders from the CRM and the online store, counterparties (clients with BIN/IIN), legal details, and sometimes invoices and quotes.
- Two-way: order status (1C ships, the CRM closes the stage), payment confirmation (the bank/Kaspi clears it, the deal moves to "Paid"), and product reservations.
The key question at project kickoff is who "owns" each reference book. If products and prices are maintained in 1C, then Bitrix24 only reads them and never edits them, otherwise the next exchange will overwrite your changes. This rule saves dozens of hours spent investigating "where did my changes go."
Which 1C configurations are supported
Bitrix24 can exchange data through the standard CommerceML protocol and the "1C + Bitrix" module, which is built into the standard configurations. In practice, this means different amounts of out-of-the-box functionality.
Trade Management (UT) — the best option
UT 11.x is the most Bitrix24-friendly configuration. The catalog, stock levels by warehouse, price types, customer orders, and counterparties are all part of the standard exchange. If you are a trading company on UT, the basic two-way exchange goes live the fastest and with minimal customization.
Small Business Management (UNF)
UNF has a built-in integration with Bitrix24 (synchronization of products, orders, and counterparties), which is convenient for small businesses that want an all-in-one setup. The caveat: the built-in UNF exchange covers basic scenarios, but non-standard pipeline stages or special reservation logic almost always require customization.
Enterprise Accounting (for Kazakhstan)
Accounting is a bookkeeping system, not a trade system; it has no full-featured warehouse management or customer orders in the familiar CRM sense. From it, it makes sense to pull the product list, counterparties, and, above all, payments (bank statements, posted documents). A full two-way order exchange with bare Accounting usually requires exchange through an intermediate UT/UNF or a custom API integration.
How the exchange works technically
Under the hood there are two scenarios, and it is important to understand which one applies to you.
- On-premise Bitrix24: the classic CommerceML exchange runs directly between the 1C server and the website/portal on a schedule (for example, every 15 to 30 minutes). Full control, but you need a server and an administrator.
- Cloud Bitrix24: there is no direct CommerceML channel to the 1C server, so the exchange runs through a connector (a module on the 1C side plus an app in Bitrix24) or through an integration bus / REST API. Most often a module is installed in 1C that connects to the cloud on its own.
The exchange frequency is configurable. Stock levels and prices are usually run every 15 to 60 minutes (real time is rarely needed and adds load), while payments and orders run either on a schedule or event-driven (a payment is posted, Bitrix24 is pinged immediately). The initial catalog upload is a full package; after that, only changes are sent (delta), otherwise with 10,000+ SKUs the exchange would take hours.
Common pitfalls (especially in Kazakhstan)
This is where 80% of any project's time is spent. These obstacles recur in almost every implementation.
- Product matching. If 1C lacks a stable unique key (SKU, code, GUID), repeat exchanges create duplicate items. The fix is to bind to an external code/GUID rather than to the name.
- Multiple price types. Retail, wholesale, dealer, with and without VAT — you must explicitly decide which price types the CRM sees and which are applied to a deal based on the client segment.
- VAT and currency. Prices in tenge, correct 16% VAT accounting, and rounding — a discrepancy of a few cents/tiyn breaks order-total reconciliation between 1C and Bitrix24.
- Counterparty BIN/IIN. The legal details of Kazakhstan legal entities and sole proprietors must map correctly to Bitrix24 fields, otherwise accounting will not pull up the client and you will have to enter it manually.
- Payments from Kaspi and banks. Kaspi acquiring, transfers, and statements arrive in 1C — you need to correctly link a payment to a specific order/deal by number or amount, otherwise the payment will be left hanging.
- Stock across multiple warehouses. If you have several warehouses, decide whether to show the total stock or per-warehouse, and how to account for reservations against other orders.
- Catalog performance. 20,000 to 50,000 SKUs with images — the first upload can take down the website/portal unless you configure the delta and schedule it during off-hours.
The rule of exchange: one source of truth per entity. If two owners share it, the data will fight rather than synchronize.
Implementation timelines
Timelines depend heavily on the configuration, the cleanliness of the data in 1C, and the number of scenarios. Benchmarks from real projects in Kazakhstan:
- Basic exchange on standard UT/UNF (products, stock, prices one-way plus orders back): 1 to 2 weeks.
- Full two-way exchange with payments, multiple price types, and warehouses: 3 to 5 weeks.
- Non-standard or heavily customized 1C, exchange with Accounting via API, custom reservation logic: from 5 to 8 weeks and an individual estimate.
Separately, budget time for cleaning up the data in 1C (duplicate items, malformed SKUs, blank BINs) — this is not "the integrator's job," but without it the exchange will keep generating junk. Preparing the reference books often takes more time than the configuration itself.
How to check that the exchange works
After setup, check the exchange on live data rather than on the integrator's report. An hour and five to ten real items are enough:
- Pick five products with different stock levels and prices and compare them in 1C and in the product record in Bitrix24 — after the next exchange the values should match.
- Check every price type a manager sees: retail, wholesale, dealer. An empty price in an invoice usually means the price type is not mapped in the exchange settings.
- Create a test order in Bitrix24 and find it in 1C: the counterparty, BIN, products, quantities and the amount with VAT should match.
- Post a payment or shipment for this order in 1C and check that the status comes back to the deal.
- Run the exchange again and make sure no duplicate products or counterparties have appeared.
- Look at the exchange error log — both in 1C and in the connector settings. An empty log after a week of work is a good sign; recurring errors mean you should go back to mapping the reference data.
If you do not have an exchange yet or it runs with errors, the cost and timing of setting it up for your configuration are on our Bitrix24 and 1C integration page. Why CRM and 1C totals can still differ is covered in our article on revenue reconciliation.
Pre-launch checklist
- Pin down the 1C configuration and edition (UT 11.x, UNF, Accounting for Kazakhstan) and the platform version.
- Define the source of truth for each entity: products, prices, stock, clients, orders.
- Decide which price types and warehouses the CRM sees.
- Check the unique keys of your product items (SKU/code/GUID) and clean up duplicates.
- Describe how a payment from a bank/Kaspi should be linked to an order.
- Choose the exchange frequency and a window for the heavy initial upload.
