KeyCRM integration with BAS and 1C: syncing orders, stock and waybills

In short

• KeyCRM and BAS or 1C usually live side by side: sales, shipping and customer chats in KeyCRM, bookkeeping and inventory in accounting. Someone in between copies orders by hand.
• An integration removes that copying: orders go from KeyCRM into accounting, products, prices and stock go from accounting into KeyCRM. Payments and waybills move both ways.
• The key decision comes before any code: which system owns which data. Without it the systems start overwriting each other.
• These exchanges most often break on product matching, duplicate customers, payments and silent failures.
• Accounting stays untouched: VAT, tax invoices, M.E.Doc and payroll remain in BAS. That is faster and keeps the accountant calm.

Why connect KeyCRM with BAS or 1C

KeyCRM is built for selling: orders from the website, Prom, Rozetka and Instagram in one list, waybills from the order card, receipts, customer chats. BAS or 1C keeps the statutory accounting: VAT, tax invoices, reporting, payroll. Both are needed. The problem is not the systems, it is the person working between them.

What it looks like without an integration:

• a manager enters the same order twice, in KeyCRM and in BAS;
• stock in KeyCRM is updated once a day or once a week, so you sell items that are already gone;
• to check whether a payment arrived, the manager calls the accountant, who searches the bank statement;
• the same customer is spelled differently in the two systems, and sales reports do not match accounting.

An integration replaces neither system. It makes every action happen once, with the other system finding out on its own.

Which system owns what

This is the first thing we agree with a client, before any technical detail. Each type of data has one leading system; the other only receives a copy. A typical setup for an online store or a distributor:

• Products and prices: led by BAS or 1C. Accounting keeps the catalogue; KeyCRM updates on its own.
• Stock: led by accounting. After each movement or on a schedule, stock goes to KeyCRM and from there to the website and marketplaces.
• Orders: born in KeyCRM, because that is where customers arrive. In accounting they appear as a customer order or a sales invoice, depending on how the warehouse works.
• Customers: both ways, but with a lookup before creating: by phone, email or company code.
• Payments: cash on delivery and card payments are recorded in KeyCRM, bank receipts in accounting, with a reconciliation between them.
• Waybills and delivery: created in KeyCRM; the number and status go into the accounting document, returns too.

Skip this step and the systems overwrite each other: a manager changes a price in KeyCRM, the nightly exchange brings back the old one from accounting, and nobody understands why.

How the data actually moves

KeyCRM has an open API and webhooks: it tells you itself when an order is created or a status changes. On the BAS and 1C side there are several options, depending on the configuration and version:

• HTTP services inside the configuration: the most flexible option when development in the database is possible;
• OData: the platform's standard interface, convenient for reading catalogues and documents;
• file exchange: when the database cannot be touched and an export is already set up.

In the middle we usually run n8n on the client's server. It does more than convert formats: it checks that everything is in place, logs every document, retries on temporary errors and alerts a person when something did not go through.

How often to sync is also decided per process. Orders and payments are best sent at once. Stock right after each movement if the configuration allows, or every few minutes on a schedule. The full catalogue once a day is enough.

Where these integrations break

1. Product matching. The SKU is one thing in accounting, another on the website and a third in KeyCRM. Bundles, size variants and units are worse: "pack" in accounting and "piece" on the website. Before the first order goes through, we build a mapping table and check it on real orders.
2. Duplicate customers. "Romashka LLC", "LLC Romashka" and "Romashka" become three counterparties. So a new customer is created only after a lookup by phone, email or company code.
3. Payments. Automation that allocates payments to orders on its own looks logical. In our project for a cosmetics distributor, checking real data showed that a payment "larger than the debt" almost always meant it had already been entered by hand. Automatic allocation would have quietly doubled payments. So the accountant posts the money and the system only suggests.
4. Statuses. KeyCRM can have a dozen order statuses, while in BAS a document is either posted or not. Status mapping needs its own agreement, otherwise "cancelled" in KeyCRM stays a posted invoice in accounting.
5. Silent failures. The most dangerous failure is the one that raises no error. For a European medtech distributor the system creates about 10 orders a day from email, and some emails vanished without a single error. Since then every document in our exchanges is processed on its own, and any stop reaches Telegram with the reason.

How we launch an exchange

1. Exchange design. What goes where, which system leads, what to do on a mismatch. One page both the owner and the accountant understand.
2. A copy of the database. First tests only on a copy of BAS or 1C. The live database stays untouched until everything is checked.
3. Parallel run. The exchange runs next to the manual process and we compare the result order by order. We do the same with reports: when a cosmetics distributor moved from spreadsheets to a dashboard on top of KeyCRM, the new figures matched the sheet for every one of the 184 orders in the debt report, and only then did the dashboard become the main one.
4. Daily mismatch check. After launch, Telegram gets only what did not match each day: orders without an accounting document, different totals, stock that drifted.
5. Failure alerts. If the exchange stops, a person knows at once, not when a customer asks where their order is.

If you want to move off 1C

Some businesses are gradually moving away from 1C. The calmest path is not a jump but a hybrid: accounting stays in BAS or other software your accountant knows, while sales, inventory and customers move to KeyCRM. The exchange between them is set up as described above, and the move does not stop sales for a single day.

Common questions

Is a 1C integration different from a BAS one? Barely: BAS and 1C run on the same platform, so the exchange is built the same way. Configurations and versions differ, so we always look at the specific database.

Do we need to change anything in accounting? No. VAT, tax invoices, M.E.Doc and payroll stay as they are. The only change is that orders, stock and payments are no longer copied by hand.

We already have an exchange, but it keeps breaking. A common story. We work out what is sent when, where data gets lost and why customers are duplicated, fix it, and add alerts and a daily mismatch check.

More on how we do it: BAS and 1C integration, KeyCRM implementation, case: KeyCRM reports for a cosmetics distributor. The intro call and demo are free.