Bitrix24 Integration with 1C:Enterprise
When a company grows to 15–20 managers, the gap between CRM and the accounting system becomes a structural problem. Data on clients, orders, and payments lives in two systems that do not communicate with each other. A manager sees a deal in Bitrix24 but does not know whether payment has gone through in 1C. An accountant sees a payment but cannot link it to a specific deal without calling the manager. Bitrix24 integration with 1C:Enterprise is not a one-time configuration — it is the construction of a two-way data exchange channel between two systems.
What exactly is synchronized
The scope of integration depends on the company's business processes. In practice, three levels are distinguished:
Basic — one-way data transfer from 1C to Bitrix24 (or vice versa):
- Counterparties from 1C → companies and contacts in CRM
- Nomenclature from 1C → Bitrix24 catalog
- Orders from Bitrix24 → "Customer Order" documents in 1C
Extended — two-way synchronization with feedback:
- Payments from 1C → deal stage change in Bitrix24
- Counterparty debt from 1C → field in the company card in CRM
- Shipments from 1C → order status update in Bitrix24
Full — document workflow synchronization:
- Invoices from Bitrix24 → invoices in 1C
- Completion acts
- Delivery notes, tax invoices
- Warehouse stock levels in real time
Technical connection options
The integration architecture is determined primarily by whether cloud or on-premise Bitrix24 is used, and which 1C configuration is in place.
REST API + webhooks — a universal option. Bitrix24 provides a REST API for all CRM objects. On the 1C side, an HTTP service is deployed (1C web service or an external handler on an intermediate server). Works with both cloud and on-premise Bitrix24.
Standard 1C-Bitrix24 module — built into on-premise Bitrix24. Exchanges data via the CommerceML protocol or via COM connection (Windows servers only). Primary purpose — nomenclature and order synchronization. Financial documents are not transferred via the standard module — customization is required.
Intermediate bus (ESB) — for complex scenarios with multiple legal entities, multiple 1C databases, or non-standard configurations. Solutions such as 1C:Data Conversion 3.0 or a custom middleware in PHP/Python act as the bus.
| Option | Cloud B24 | On-premise B24 | Setup complexity |
|---|---|---|---|
| REST API + webhooks | Yes | Yes | Medium |
| Standard module | No | Yes | Low (basic scope) |
| COM connection | No | Windows only | Low, but limited |
| ESB / middleware | Yes | Yes | High |
Counterparty synchronization: the main pitfall
In practice, counterparty synchronization causes the most problems. In 1C, a counterparty is a legal entity with a TIN. In CRM, a contact is an individual representing a company. The data structure is fundamentally different.
Typical issues during database merge:
- The same client is registered in 1C as "Romashka LLC" and in Bitrix24 as "LLC Romashka" — without TIN as the search key, duplicates arise.
- In Bitrix24, one contact can be linked to multiple companies; 1C does not have such a structure.
- Individuals in CRM do not have TINs but may make purchases.
Solution: the synchronization key is the TIN (for legal entities) or SNILS/phone (for individuals). During the initial load, a deduplication procedure is run: find a match by TIN; if found — update; if not — create a new record with an assigned XML_ID for subsequent identification.
Nomenclature and stock synchronization
Nomenclature is transferred from 1C to Bitrix24 (or bidirectionally, if new items are created in CRM). For each product, the following are critical:
- Article (product code) — the identification key. Article in 1C = XML ID of the product in Bitrix24.
- Unit of measurement — mapping OKEI units → CRM units.
- Prices — if 1C has multiple price types (retail, wholesale, dealer), determine which price goes to which Bitrix24 price list.
- Stock levels — which warehouses to display, how frequently to update.
The update frequency for stock levels depends on turnover: for active trading — every 15–30 minutes via a scheduled task; for steady B2B — once per hour is sufficient.
Payments and financial data
Transferring payment information from 1C to Bitrix24 is a key part of the integration for managers. A manager must see in the deal card:
- Whether payment has been received (yes/no)
- Amount paid
- Payment date
- Outstanding balance
In 1C, a scheduled task checks posted "Bank Receipt" and "Cash Receipt Order" documents. Finding a payment linked to a Bitrix24 deal (by invoice or order number), the handler calls crm.deal.update and updates the corresponding fields.
Case study: wholesale and retail company with 3 legal entities
A company with three legal entities, 25 managers, and two 1C databases (retail on 1C:Retail, wholesale on 1C:UT 11). Objective — a single Bitrix24 for all managers with visibility of financial data from both 1C databases.
Architectural solution: an intermediate PHP service aggregates data from both 1C databases and transfers it to Bitrix24. The data source is encoded in a custom deal field ("Seller Legal Entity"), which allows the 1C handler to determine which database to write incoming data to.
A separate complexity: mutual settlements between legal entities. When moving a deal between funnels of different legal entities, the debt had to be zeroed under one and created under another. Implemented via a custom event in the Bitrix24 business process.
Full implementation timeframe: 3–4 months (including 2 weeks for data audit and counterparty deduplication, 6 weeks for development and testing, 2 weeks for phased rollout).
Integration support and monitoring
After launch, the integration requires monitoring. Typical failures:
- API password change or Bitrix24 token rotation
- 1C platform update changing the OData structure
- IP blocking of the intermediate server
- Data validation errors when a CRM form changes (a field added — mapping breaks)
Minimum monitoring: an exchange error log with an email alert for critical failures. Extended — a dashboard with metrics: number of successful/failed synchronizations per period, median document transfer time.