1C / BAS Integration with Your Website and CRM: Data Exchange Without Spreadsheets

In the morning, a manager exports stock levels from 1C to a spreadsheet. In the afternoon, a content manager uploads them to the website. In the evening, someone manually copies website orders back into the accounting system. Somewhere in between, a customer buys an item that is already out of stock. 1C / BAS integration with your website and CRM removes that chain: data moves between systems on its own, and people get back to selling.

(1C and its successor BAS are the accounting and ERP platforms most businesses in Ukraine and neighbouring countries run on — but the principles below apply to any ERP.)

Let's run an example. Take a store where two employees each spend 1.5 hours a day on exports, imports and reconciling orders. That's about 66 hours a month. At $5 per hour, that's over $300 every month just to move data around. Add cancelled orders because of wrong stock levels and pricing mistakes, and manual exchange becomes one of the most expensive "free" routines in the company.

I started my IT career as a 1C operator, then worked in purchasing and sales, so I know this pain from both sides.

Why spreadsheet-based exchange doesn't work

• Delay. Website data always lags hours or days behind your accounting.
• Human error. A shifted column, the wrong file, someone forgot to export on Friday.
• No shared catalog. The same item is "Bolt M8x40 galv." in 1C and "Galvanized bolt M8 40mm" on the website.
• No way to trace what went wrong. The file was overwritten, and there's no history.

What to sync and in which direction

The core rule of any integration: every type of data needs one source of truth — the system where that data is created and edited. Every other system only receives a copy. If the same price can be changed in both 1C and the website, a conflict is only a matter of time.

A typical setup for a trading company looks like this:

Data	Source of truth	Direction	How often
Products (catalog, attributes)	1C / BAS	1C → website, CRM	daily or on change
Stock levels	1C / BAS	1C → website, CRM	every 5–15 minutes or real time
Prices	1C / BAS	1C → website, CRM	on change
Orders	Website / CRM	website → CRM → 1C	right after checkout
Customers	CRM	CRM ↔ 1C	on create and update
Payments	1C / BAS (bank)	1C → CRM	several times a day
Order statuses	1C / BAS (warehouse, shipping)	1C → CRM → website	on change

Fill in this table before you talk to any developer. If people inside your company argue about where the "master" data lives for any row, you've just found a future integration problem.

Common 1C integration mistakes

Duplicate products and customers

The most frequent problem. Records are matched by name or SKU, someone adds a space, and the CRM now has a second copy of the same product or a second "John Smith". Six months later you have thousands of duplicates and your reports are wrong.

No unique IDs

Every record needs a permanent ID that both systems know — for example, the 1C GUID stored on the product record on the website and in the CRM. Then renaming a product breaks nothing. Without that, any integration runs on luck.

Sync conflicts

A sales rep updates a customer's phone number in the CRM, an accountant updates it in 1C, and the exchange overwrites one with the other. The fix is a source-of-truth rule for every field and clear logic about which change wins.

No logs

The exchange "sometimes doesn't work", but nobody knows when or why. Every run should record what was sent, what was received, which records were rejected and why.

Real-time or scheduled exchange

Approach	Best for	Downsides
Real time (on change)	Orders, payments, stock of fast-selling items	Harder to build; needs a queue for when 1C is unavailable
Scheduled (every N minutes/hours)	Catalog, prices, attributes, reference data	Data lags by the sync interval
Mixed	Most real-world projects	You need to spell out clearly what syncs and how often

In practice I almost always build a mixed setup: orders immediately, stock frequently, catalog on a schedule. It's cheaper and more reliable than "everything in real time".

Failure monitoring: don't hear about it from customers

The worst case: the exchange quietly stops on Friday, and on Monday you're sorting out orders for items you don't have. That's why every integration I build includes monitoring:

• A log of every exchange run with the number of records processed
• A Telegram alert when an exchange fails with an error
• An alert when an exchange hasn't run for longer than expected
• A separate list of records that failed validation (missing ID, empty price)
• A way to restart the exchange without a developer
• Database backups before bulk changes

A Telegram alert is a simple thing, but it turns "we found out three days later" into "we found out five minutes later".

What this looks like in my projects

Agricultural company. Vtiger CRM running in Docker with a 1C exchange, plus Asterisk/FreePBX call monitoring that posts calls to a Telegram group, and database backups. Details in the case study CRM, 1C and telephony for an agro company.

SaaS for suppliers and sellers. In my own product, HitSalle, suppliers upload catalogs in XML/YML/Excel, sellers copy products and export them to marketplaces and their own stores via feeds, and stock and prices sync automatically — every 1, 2 or 12 hours depending on the plan. Case study: marketplace SaaS.

WooCommerce online store. New and updated orders are automatically created and updated in Bitrix24, and the team gets Telegram notifications. Case study: WooCommerce + Bitrix24.

When integration won't pay off

• Low volume. A dozen orders a week and a hundred products that change once a quarter can easily be handled by hand.
• Your 1C data is a mess. If the catalog is full of duplicates and empty SKUs, integration will just spread that chaos to every system. Clean up the reference data first.
• Nobody owns it. Even a good integration needs someone who reacts to alerts and handles rejected records.
• You're about to switch systems. If you're moving from 1C to BAS or another platform in six months, migrate first, integrate second.

How much it costs

• A single task (for example, a scheduled stock export to the website) — from $250.
• Two-way 1C / BAS ↔ CRM ↔ website exchange with logs and Telegram alerts — usually a project from $1,500, paid in stages.
• Exchange support after launch — from $100/month.

The exact price depends on your 1C / BAS configuration, the number of data flows and how clean your reference data is.

Next step

Fill in the source-of-truth table from this article — that alone answers half the questions. And if you'd like a fresh pair of eyes on your data exchange, book a free 30-minute process review. I'll tell you what can be automated, in what order, and whether it's worth doing at all. More on the integrations and data exchange page, and if your CRM isn't chosen yet or needs work — Bitrix24 and CRM implementation.