The question “how do we connect a CRM with 1C/BAS” comes up in every other B2B project. The answer is always one of three architectures — and getting the choice wrong costs more than the integration itself.
Approach 1: a direct link (point-to-point)
The CRM calls the accounting system’s API directly, or vice versa. Ready-made connectors from some CRMs to BAS are this approach too.
When it works: one or two simple exchanges (for example, counterparties only), a small volume, standard BAS configurations without deep customization.
Where it breaks: the moment logic appears. “Create a counterparty only if the deal is over X,” “don’t update the price if the rep applied a discount manually” — a direct link turns into a tangle of conditions inside the configuration that you’re afraid to touch.
Cost: minimal at the start, unpredictable in maintenance.
Approach 2: a middleware service
A separate service between the systems: it receives a webhook (an instant notification between systems) or polls the API, transforms the data by rules, writes to the target system, and keeps a log of every exchange.
When it works: two-way synchronization, financial data, a non-standard data model, a need for auditing (“why is the wrong payment status in the CRM?” — the answer is in the logs within a minute).
The key architectural rule we lock in on every project:
BAS is the source of truth for finances and the product catalog. The CRM is the source of truth for clients and communications. No field is edited from both sides.
A typical working scenario: a rep clicks “issue invoice” on a deal → the middleware service creates the invoice in BAS and returns a PDF to the card → the accountant records the payment in BAS → the status flies back → the deal automatically moves to the “Paid” stage and the rep gets a task to ship.
Cost: higher at the start, predictable thereafter. A CRM update or a BAS configuration change won’t break the exchange — fixes are localized in one place.
Approach 3: a manual bridge run by a procedure
Yes, this is a valid approach too. Export from the CRM once a day, import into BAS by instruction.
When it’s justified: up to 10–20 operations a day, one person on each side, a project budget that doesn’t yet justify automation.
The main requirement: a written procedure (who, when, and exactly what gets transferred) and the understanding that this is a temporary solution. A manual bridge without a procedure isn’t a working approach — it’s a source of discrepancies that surface at the end of the quarter.
How to choose
| Criterion | Direct link | Middleware service | Manual bridge |
|---|---|---|---|
| Exchanges per day | up to ~100 | any number | up to ~20 |
| Direction | mostly one-way | two-way | one-way |
| Transformation logic | minimal | any | in someone’s head |
| Exchange auditing | limited | full | a log in Excel |
| Start | fast | 4–8 weeks | instant |
If you’re torn between the first and the second, calculate the cost of one hour of a stalled exchange and the number of exceptional cases per month. Those two figures usually settle the discussion.