CRM and 1C Integration: Connecting Orders, Invoices and Payments
CRM and 1C integration should give sales staff a verifiable link between a sale and the accounting records: which order was created, whether an invoice was issued, how much was paid and what was shipped. Define the document types, data ownership and change rules before configuring the exchange. Transferring the deal total alone is usually insufficient.
Start with one complete workflow: an approved CRM order reaches 1C, its reference returns to the sales representative, and CRM then receives payment and fulfilment information. The exact scope depends on the 1C configuration, CRM capabilities and the application used. Include full reference-data exchange and historical records only where required.
This guide helps sales leaders and technical project owners prepare requirements. It includes a data map, an illustrative partial-payment example and an acceptance table. The recommendations concern exchange design; check document names and available operations in your own system.
For a joint review, download the Russian acceptance template — CSV or the English template — CSV. It contains 20 scenarios covering data, orders, payments, fulfilment, failures and support handover. Record the actual result, redacted evidence, an owner and the date; the initial “Not tested” status does not indicate a pass.
What to include in the first CRM and 1C exchange
List the actions that require staff to switch systems. For example, a sales representative approves order lines in CRM, an accountant enters them again in 1C and then reports payment in a chat. A useful first outcome is to transfer the approved order and return a confirmation the representative can find without messaging a colleague.
Define the workflow boundaries. Who authorizes document creation? Which fields are mandatory? When may the order change? Should the integration post the document or only create it for staff review? These business-process decisions affect permissions, tests and responsibilities.
A first phase might cover one legal entity and one order type. Later phases can add warehouses, contracts, currencies or return processes. However, the initial release must address failures already possible within its scope: redelivery, cancellation, partial payment or a missing required field.
Agree an acceptable delay too. Sales staff should know when the data was last updated. A schedule may suffice for infrequent exchange; an operation that controls shipment needs stricter conditions and a visible delay notification. Choose the interval according to the workflow and system limits.
Data map: where records are created and changed
Assign a source and permitted changes to each object. A customer might have contact details maintained in CRM and accounting details maintained in 1C. A blanket rule that everything syncs both ways creates an overwrite risk: two teams may change the same fields with different intentions.
The illustrative map below is a starting point for discussion; adapt it to your accounting setup.
| Object | Possible owner | Data exchanged | Decision required |
|---|---|---|---|
| Contact | CRM | Mapping ID, name, permitted contact details | Whether 1C may change the phone number |
| Counterparty and contract | 1C | ID, legal details, link to the CRM customer | Customers with multiple contracts |
| Product reference data | 1C | ID, SKU, units, available variants | Which products sales staff may select |
| Order | CRM until approval; agreed rules afterwards | Lines, quantity, price, legal entity, revision | Who authorizes changes after submission |
| Invoice | 1C | Reference, date, amount, file or link | Multiple invoices for one order |
| Payment | Accounting system | Amount, document, order relationship | Partial payments and allocation |
| Fulfilment | Accounting system | Document, quantity, date | Multiple shipments and returns |
Keep ID mappings: the CRM customer and 1C counterparty, the CRM order and 1C document. Company names and phone numbers can help find candidates, but an incorrect match can attach a payment to the wrong sale. Send ambiguous mappings to an owner for review.
An existing database needs initial mapping. Ask to see unmatched records, ambiguous matches and proposed merges. Automatically merging the entire directory before launch makes errors harder to reverse. Agree matching rules separately from the transfer of new documents.
Interface capabilities to verify before development
The standard 1C REST interface uses OData 3.0. The platform supports reading and changing objects and provides some document actions, including posting. Verify that the required entities, permissions and operations are available in the published business application.
The documentation identifies an exception: the interface performs normal permission checks and invokes event handlers, but it does not perform the field-completion check. A technically successful write therefore does not confirm that your workflow's required data is valid. Include field validation and document eligibility in the project.
Before estimating the work, ask CRM and 1C technical representatives to demonstrate three operations in a test environment: read the required object, create an agreed document and retrieve its outcome. Then test a failure: insufficient permissions, an unsupported field or a missing mapping. Each operation needs a clear response traceable to the original order.
Test an off-the-shelf application against the same workflow. The official overview from Bitrix24 states that the specific “Synchronization of Deals and Orders in 1C:Enterprise 8” application does not transfer products from the deal to 1C. This is a limitation of that application; other solutions may behave differently. The label “order synchronization” alone does not confirm that all line items are transferred.
First compare the selected application's capabilities with your workflow. For a custom exchange, the technical mechanisms are covered in the CRM architecture guide. The following sections address accounting-exchange rules needed with different connection methods.
Connecting a deal, an order and an invoice
Clarify the object relationships first. One deal may contain multiple orders, and one order may have multiple invoices and shipments. If an integration assumes one deal corresponds to one document, ask how it handles your actual workflow. Any limitation must be explicitly agreed.
Define the submission point separately. Before approval, sales staff may change the lines and discount; once a document exists in 1C, those changes may need authorization. Distinguish a draft from a submitted order revision. CRM should show which revision was sent and its processing state.
Creating and posting a document are different outcomes. Depending on the configuration and settings, posting may affect accounting movements. The 1C specialist defines the permissions and checks it requires. If the integration creates a document for later review, CRM must accurately report that state.
Agree how staff access an invoice. A file copied to CRM can become outdated when details change. A document link depends on permissions and system availability. Choose an approach, define its update rule and test which invoice staff see after an order changes.
Partial payment, fulfilment and returns: separate states
Keep the sales stage, payment state and fulfilment state separate. An order may be fully paid but partly shipped; a payment may arrive before its final lines are approved. A single “complete” status hides these distinctions and makes decisions harder for staff.
Consider an illustrative order worth RUB 120,000. A payment of RUB 40,000 arrives, followed by RUB 80,000. After the first payment, CRM should show partial payment and the remaining balance under the agreed model. After the second, it should show full payment. Redelivering the first payment event must not increase the total paid amount to RUB 160,000.
| Event in the illustrative workflow | What sales staff should see | What to check |
|---|---|---|
| Order confirmed in 1C | Accounting document ID and state | Lines and amount match the submitted revision |
| Partial payment received | Paid amount and remaining balance | Payment belongs to the correct document |
| Payment completed | Full payment independently of fulfilment | Redelivery does not increase the total |
| Some lines shipped | A separate fulfilment state | Quantities are linked to line items |
| Order lines changed | A change awaiting approval | The new revision has not silently overwritten accounting data |
| Return processed | Return information and processing state | It is not automatically conflated with cancellation |
This table is a requirements model, not a universal accounting scheme. Allocating one payment across orders, applying an advance and changing the amount after a return depend on the configuration and accounting rules. These operations need separate test documents and approval from the responsible owner.
The Bitrix24 connector settings include status mappings and date filters. Check these conditions before loading historical records: an excluded date or status can leave a document outside the exchange. For another product, examine its own selection rules.
Why duplicate documents appear
A difficult case is a timeout after order creation. CRM sends a request, 1C completes the operation, but the response never arrives. The sender sees an unknown outcome. Simply creating the order again produces a duplicate even though the original request succeeded.
This workflow needs a stable operation identifier and a way to find a document already created. If the interface has no suitable built-in mechanism, design one in the integration layer with protection against concurrent creation. A lookup before writing can also produce duplicates if concurrency is uncontrolled.
The message delivery guide from RabbitMQ explains why connection recovery can cause redelivery and why consumers need idempotent processing. Idempotency means repeating an action preserves its original outcome. It must be implemented by the receiving system; adding a queue alone does not provide it for a 1C document.
Distinguish an event retry from a new order change. Repeating the same revision should return the previous outcome. A new revision with different lines must follow its own approval rules. The log should distinguish these situations so an operator can understand why an action was skipped or executed again.
Data conflicts and reconciliation
Priority rules remain necessary after launch. An accountant changes a contract in 1C while a sales representative changes the legal entity in CRM. A delayed exchange task can restore an old value. Define which changes are blocked, accepted automatically or referred for manual resolution.
| Situation | Recommended processing condition |
|---|---|
| An outdated order revision arrives | Record the rejection reason and current revision |
| Fields owned by the other system change | Request approval instead of silently writing |
| No ID mapping exists | Stop that operation and show it to an owner |
| 1C is temporarily unavailable | Retain the task and show the exchange delay |
| No response arrives after a write | Establish the outcome by key before creating again |
| Permissions or the object schema change | Record the failure and request a compatibility check |
The exchange log explains an individual operation. Reconciliation checks completeness. Compare related orders, amounts and states for an agreed period, highlighting missing documents and differences. A list of successful HTTP requests does not replace that check.
Record the last successful exchange time, the number of unprocessed operations and the owner of the error queue. Sales staff need a clear path: open the order, find its related operation and give its ID to support. Keep passwords, tokens and full personal details out of diagnostic messages.
Running a pilot before enabling the entire database
- Record the versions of CRM, the 1C platform and configuration, the application and required extensions.
- Prepare a separate test environment and approved data; disable live notifications and external actions.
- Agree the object map, submission point and document-change rules.
- Test one ordinary order and find it in both systems using the mapped IDs.
- Test partial payment, cancellation, line changes and event redelivery.
- Test an exchange interruption and recovery when a write has an unknown outcome.
- Reconcile documents and amounts and record the limitations found.
- Enable a limited production scope and monitor it before expanding.
Choose the pilot scope according to workflow variety. Dozens of identical orders may miss an error that occurs only with a second contract or partial shipment. Include conditions that genuinely occur in the business and record expected outcomes before testing.
Contractor acceptance criteria
For each case, record the input data, action, expected result, actual IDs and test evidence. The table below is a starting set of checks, not a report of completed tests.
| Check | Acceptance condition |
|---|---|
| New customer | An agreed record mapping exists without an ambiguous match |
| Ordinary order | Lines, legal entity, contract and amount meet the requirements |
| Repeated operation | No second document exists; the original outcome is available |
| Timeout after a write | The system finds the outcome instead of blindly recreating the order |
| Partial and full payment | Amount, order relationship and state are displayed correctly |
| Multiple invoices or shipments | Separate relationships and agreed totals are retained |
| Cancellation and return | Each action follows its own rule |
| Outdated change | A stale event does not overwrite the current state |
| 1C unavailable | The task is retained, the delay is visible and recovery is tested |
| Insufficient permissions | The failure is understandable and reaches an owner |
| Reconciliation | The control document set is fully matched |
| Support handover | Data mapping, instructions, access and owners are available |
Conduct acceptance jointly: the sales representative assesses the staff workflow, the 1C specialist checks the documents and the contractor checks exchange behavior. Signing off on a successful order demonstration alone leaves edge cases untested.
What determines CRM and 1C integration cost
The estimate depends on system configurations and customizations, existing data quality, document types, exchange directions and error-resolution rules. Transferring payment information alone has a different scope from full bidirectional exchange of customers, products, contracts and orders.
Ask for discovery, historical mapping, configuration or development, testing, launch and support to be listed separately. If a required operation has not been confirmed in testing, its estimate should state the assumption. The overall CRM project cost structure is covered in the CRM development cost guide.
To request an estimate, provide the 1C configuration and version, CRM name, a redacted order example, required-field map, changes allowed after submission and edge cases. The technical foundation is explained in the CRM architecture guide. Discuss configuring a suitable product through CRM implementation and configuration, or a custom exchange through CRM and integration development.
FAQ
Can two different 1C databases connect to one CRM?
Check whether the selected solution supports it. The project must distinguish the source database, legal entity and identifiers: the same local document reference in two databases does not identify one order. Acceptance should include overlapping references and permitted access to each database.
Must all old deals be transferred at launch?
Only if they participate in the selected workflow. Active obligations may require historical relationships; a closed archive may need separate migration or access without synchronization. Agree the exchange start date with outstanding orders and payments in mind.
What if the integration stops working after an update?
Save the failure time, versions and unsuccessful operation ID. Check access, field changes, selection settings and the system response. After fixing the cause, establish which operations already completed before resuming with duplicate-creation protection.
Can sales staff manually correct CRM data?
Yes, for agreed fields. Accounting data needs a defined owner and change procedure, or the next exchange may overwrite the correction. The interface should distinguish editable information from data received from 1C.
Sources
- 1C: standard REST interface.
- Bitrix24: order synchronization.
- Bitrix24: applications for integration with 1C.
- RabbitMQ: delivery reliability.
Documentation checked on October 9, 2026. The data map, pilot plan, acceptance table and payment example are project-planning recommendations, not an account of an NBM-IT implementation.