Why ERP–CRM Integration Is Harder Than It Looks
The core challenge is that Bitrix24 and an ERP/accounting system model the same business reality with completely different entities — and without explicit mapping, the two systems will fight rather than complement each other.
In Bitrix24 you work with leads, deals, contacts, and companies. In a typical accounting or ERP platform the equivalent objects are counterparties, orders, shipments, contracts, and invoices. A deal stage in Bitrix24 does not automatically correspond to an order status in the ERP — someone has to define that mapping deliberately. Skip the alignment step, and you end up with duplicate records, stale prices, and payment statuses that never reach the sales rep.
Based on our project experience, the most common pain points before integration are:
- Managers re-entering order data they already captured in CRM
- Finance seeing a different client name or legal detail than sales
- Payment confirmation arriving in accounting but never updating the deal stage
- Stock availability checked manually because the CRM has no live inventory feed
Fixing all of these requires a structured technical specification — not just turning on a sync toggle.
Choosing the Right Sync Direction for Each Entity
Not every data object should flow both ways — defining the "master system" per entity type is the single most important architecture decision in any Bitrix24 ERP integration.
A bidirectional sync sounds appealing but introduces write conflicts that are hard to resolve automatically. In practice, most projects assign ownership per object type:
| Entity | Typical master system | Sync direction |
|---|---|---|
| Counterparty / Company card | ERP (legal & financial data) | ERP → Bitrix24 (on create/change) |
| Contact persons | Bitrix24 | Bidirectional |
| Product catalogue / nomenclature | ERP | ERP → Bitrix24 only |
| Orders / Deals | Triggered from both sides | ERP → Bitrix24 on status change; Bitrix24 → ERP on deal stage trigger |
| Invoices & payment status | ERP | ERP → Bitrix24 only |
| Contracts / Agreements | Bitrix24 initiates, ERP finalises | Bitrix24 → ERP on stage change; signed PDF returns to Bitrix24 |
| Shipment confirmations | ERP | ERP → Bitrix24 only |
A practical rule from our implementation work: the ERP is master for anything with legal or financial weight (invoice numbers, tax IDs, bank details, shipping amounts). Bitrix24 is master for everything that happens before the contract is signed — leads, communication history, deal stages.
One architectural guard worth applying: new company cards created in Bitrix24 should not be pushed to the ERP immediately. The transfer should be triggered only when a contract is created or an invoice is raised — preventing unqualified leads from polluting the accounting database.
Entity Mapping: What Gets Synchronised
A field-level mapping table — agreed before any code is written — is the deliverable that prevents 80% of post-launch data quality issues.
Below is a representative mapping between ERP documents and Bitrix24 smart processes, drawn from real project specifications:
| ERP document | Bitrix24 entity | Key fields transferred |
|---|---|---|
| Customer order | Deal (Sales pipeline) | Order number, line items, total, counterparty ID |
| Contract / Agreement | Smart process "Contracts" | Contract number, date, validity period, signed PDF |
| Invoice (outgoing) | Smart process "Invoices" | Invoice number, date, amount + currency, payment date |
| Incoming payment | Invoice card update | Payment date, amount received |
| Shipment / UPD | Deal field "Shipped amount" | Shipped total, shipment status |
| Payment order | Smart process "Payment orders" | Number, date, recipient, amount, purpose |
| Supplier invoice | Smart process "Supplier invoices" | Number, date, counterparty, line items, amount |
For company cards, the sync typically carries: legal name, tax registration number, VAT number, legal entity type, and full banking details (bank name, BIC, correspondent account, settlement account). These fields are populated in the ERP and flow into Bitrix24 automatically.
Duplicate prevention uses deterministic keys — companies are matched by tax ID, contacts by phone number. This prevents the same counterparty from being created twice when records arrive from both sides.
Sync Triggers and Timing
Choosing the right trigger — event-driven webhook vs. scheduled polling — directly determines how "live" the integration feels to the sales team.
Two trigger patterns are used in production:
1. Webhook (event-driven) The ERP fires an HTTP request to Bitrix24 the moment a relevant document is created or changed. Used for high-priority events: order creation, payment confirmation, shipment completion. Latency is typically seconds.
2. Scheduled polling (batch) A background handler runs at a fixed interval — typically every 5 minutes — queries both systems for changes since the last run, and applies updates. Used for lower-priority or high-volume data like product catalogue updates and counterparty changes.
In most projects, both patterns coexist: webhooks for financial events, polling for reference data.
Key trigger rules observed across projects:
- An order created manually in the ERP immediately creates a deal in Bitrix24 at a defined pipeline stage
- Moving a deal card manually in Bitrix24 does not change the order status in the ERP — ERP status is authoritative
- When the ERP status changes, the Bitrix24 deal stage updates unconditionally, regardless of where the card sits
- An invoice is only exchanged with the ERP once the Bitrix24 stage moves from "draft" to "issued" — preventing phantom orders in accounting
- After an invoice is fully or partially paid, editing it in Bitrix24 is blocked; all changes must happen in the ERP and sync back
The Integration Data Flow (Architecture Overview)
The diagram below shows how Bitrix24 and a typical ERP/accounting system exchange data. CRM-side events (deal stage changes, new contacts) trigger flows into the ERP, while financial events (payments, shipments) flow back into Bitrix24 and update deal stages automatically.
flowchart LR
subgraph CRM [Bitrix24]
LEAD[Lead / Contact]
DEAL[Deal]
INV[Invoice Smart-Process]
CONTRACT[Contract Smart-Process]
end
subgraph ERP [ERP / Accounting]
CTRAGENT[Counterparty]
ORDER[Customer Order]
CNTR[Contract Document]
PAYMENT[Payment / Bank Receipt]
SHIP[Shipment / UPD]
CATALOG[Product Catalogue]
end
CTRAGENT -- "Initial load + updates" --> LEAD
DEAL -- "Stage trigger: contract signed" --> CNTR
CNTR -- "Signed PDF returns" --> CONTRACT
DEAL -- "Stage trigger: invoice issued" --> ORDER
ORDER -- "Order number returned" --> INV
PAYMENT -- "Payment date + status" --> INV
SHIP -- "Shipped amount" --> DEAL
CATALOG -- "One-way, on change" --> DEAL
Conflict Handling and Data Governance Rules
The safest approach is to assign strict write ownership per field — never allow both systems to overwrite the same field freely, or the last-write-wins race condition will corrupt your data.
Governance rules applied in production integrations:
- Invoice numbering is generated exclusively in the ERP. The ERP assigns the number and returns it to Bitrix24; Bitrix24 never generates its own invoice numbers.
- Legal and financial fields (tax IDs, bank details) are read-only in Bitrix24. They are populated from the ERP and displayed in the CRM card for context, but cannot be edited there.
- New product positions can be created from Bitrix24 (e.g. a sales manager adds a non-catalogue item to a quote), but editing existing product records is only permitted on the ERP side.
- Internal orders that don't require ERP recording are flagged with a "Do not sync" field in the smart process — the handler skips them entirely.
- Dirty-record prevention: when a scheduled handler runs, it checks for the ERP-assigned Bitrix24 ID field before creating new records. If the field is already populated, an update is sent rather than a duplicate create.
For company deduplication, the integration checks the tax ID on every sync cycle. If a counterparty in the ERP has no match in Bitrix24, a new company card is created. If a match exists, the card is updated. Contacts are matched by phone number using the same logic.
Implementation Phases and Timeline
A typical Bitrix24 ERP integration project runs through four defined phases: business logic alignment, technical specification, development, and testing — with the spec phase being the most frequently underestimated.
Based on our project archive, here is how a standard engagement is structured:
-
Business logic workshop — the analyst runs a session where the ERP operator demonstrates their current workflow in both systems. The output is a "to-be" process model: who does what in which system, and what needs to happen automatically.
-
Technical specification — field mapping tables, sync direction per entity, trigger conditions, deduplication rules, and ERP version requirements are documented. For a mid-complexity integration (3–5 entity types), this phase typically takes around 4 hours of analyst time and produces the spec document the developer works from.
-
Development — a custom handler is written on the ERP side; REST API / webhook logic is configured on the Bitrix24 side. Note: ERP-side development is typically the client's responsibility (or their ERP partner's). The Bitrix24 integrator covers the CRM side and the integration layer.
-
Testing & go-live — end-to-end scenario tests with real data, conflict simulation, duplicate checks, and a two-hour group training session for staff.
Platform version requirements matter: for older ERP installations, an upgrade may be a prerequisite before integration is possible. Establish the exact version requirements during the spec phase, not after development starts.
For a broader view of how integration fits into a full Bitrix24 rollout, see Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects and Bitrix24 Implementation Hours by Module: A Data Reference for Budgeting.
Industry-Specific Considerations
The entity types and sync directions vary significantly by industry — a wholesale distributor needs order and shipment sync, while a services firm prioritises contracts and payment orders.
Here are patterns we see regularly:
Distribution / wholesale trade - Product catalogue sync (ERP → Bitrix24) is critical — prices and stock availability must be current - Shipped-amount field in the deal card updates as partial shipments are recorded in the ERP - "Ready to close" deal stage triggered automatically when the ERP marks the order fully shipped
Professional services / B2B - Contract lifecycle is the core flow: Bitrix24 initiates, ERP finalises and returns the signed document - Payment order smart process tracks disbursements (e.g. agent commissions, supplier payments) - Invoices are structured per project ID, linking to a project registry smart process
Logistics and freight - Shipment history tab in company cards pulls transportation records from the ERP on demand (manual trigger from the CRM card) - Companies and contacts sync bidirectionally, including banking details for billing
Manufacturing - Assembly kit logic: ERP assembles components dynamically; Bitrix24 receives only the "available stock" figure, not the BOM detail - Production order status syncs to the deal stage so the sales team sees fulfilment progress in real time
For more on how Bitrix24 handles complex operational workflows, see Bitrix24 for Manufacturing Companies: Orders, Production, and Delivery Timelines and Bitrix24 for Logistics & Freight Forwarders: Shipments, Quotes, and Customer Portal.
Preparing Your Bitrix24 Portal for Integration
Before a single line of handler code is written, the Bitrix24 portal must be configured with the correct custom fields, smart processes, and pipeline stages — otherwise the integration has nothing to write into.
Pre-integration portal checklist:
- [ ] Custom fields created for ERP IDs (e.g. "ERP Order ID", "ERP Invoice Number") on deal, contact, and company cards
- [ ] Smart processes created for entities that have no native Bitrix24 equivalent: Invoices, Contracts, Shipment documents, Payment orders, Supplier invoices
- [ ] Pipeline stages mapped to ERP order statuses — documented in a table agreed with both the sales and finance teams
- [ ] Duplicate detection rules configured (match companies by tax ID, contacts by phone)
- [ ] Access rights reviewed — integration service accounts need write access only to the entities they sync; staff accounts should not be able to edit ERP-mastered fields manually
- [ ] "Do not sync" flag field added to smart processes that have internal-only records
This preparation work is typically done by the Bitrix24 implementation partner and takes 4–8 hours depending on portal complexity. If you haven't yet completed your portal requirements gathering, the Bitrix24 Onboarding Questionnaire: 50+ Questions to Ask Before You Start is a useful starting point.
If you're running Bitrix24 on-premise and need to consider network access for the integration layer, Self-Hosted Bitrix24: Hardware Sizing Guide for 50 to 1,000 Users covers the infrastructure considerations.