Setting Up Seller Analytics on the 1C-Bitrix Marketplace

Why 1C-Bitrix seller analytics produces discrepancies with the marketplace

Discrepancies begin where data exchange ends. The marketplace counts a sale at the moment the order is placed, while order accounting in 1C counts it at the moment the sales document is posted.

Between these events, an order may be cancelled, partially redeemed, or returned, and each side records its own version. Seller analytics in 1C-Bitrix, built on such an exchange, shows one revenue figure, while the marketplace's seller dashboard shows another.

The second reason is stock levels and write-offs. Reservation for an order, shipment from the marketplace warehouse, and return of goods back into circulation change the available quantity at different times.

If synchronization runs on a schedule rather than on events, a delta accumulates between runs: the item is sold but is still listed in 1C, or vice versa.

This leads to "phantom" stock levels, because of which a product drops out of active listings, and the seller only finds out about it from fallen impressions.

The third reason is mismatched reference data. A single SKU on the marketplace may be linked to several product cards or to a product with a different unit of measurement.

Then data reconciliation breaks down at the nomenclature level, and any summary reports diverge, even if the sales themselves are accounted for correctly.

The cost of the error is not accounting, but assortment management. When report discrepancies are not resolved, purchasing is driven by inflated stock levels, and removal of products from the matrix is driven by understated revenue.

We break down how to set up the exchange and reconciliation so that the numbers match at the level of events, not manual adjustments.

What correct 1C-Bitrix seller analytics delivers

When data about products, orders, and stock is collected in a single loop rather than in three spreadsheets and a chat thread, the seller sees the real sales picture for the first time.

Seller analytics on 1C-Bitrix is built on the link between the catalog, inventory accounting, and orders: the stock level for each product is updated from the accounting system rather than edited by hand, so the discrepancy between "on the site" and "in the warehouse" stops being the norm.

This changes not the reporting but the daily decisions — what to order from the supplier, what to remove from the assortment, where the price sustains demand and where it holds it back.

The first measurable effect is the speed of reconciliation. When stock and price exports run on a schedule and are logged, reconciling the warehouse with the storefront takes minutes instead of hours of manual matching.

Errors are caught at the input: a product with no stock does not go on sale instead of turning into a cancellation a day later.

The second is stock accuracy and the cancellation rate. If accounting cannot keep up with sales, the customer places an order for a product that is already gone and gets a refusal.

Two-way synchronization and reservation during checkout eliminate this class of refusals: the share of cancellations and returns drops, and the seller's rating stops sagging because of unfulfilled orders.

The third is turnover and assortment management. You can see which items sell in a matter of days and which sit for months and freeze up the warehouse.

Based on this data, purchasing is built around actual demand: fast-moving items do not go into shortage, dead stock is removed, and working capital stops lying around as dead weight.

All of this works only with honest data at the input — that is why we start by checking the sources and set up accounting so that the numbers in the report match what actually happens in the warehouse and in orders.

Data Collection Methods: Exchange, Exports, Direct Access

Order, stock, and price data reach 1C-Bitrix through three paths, and the choice between them determines how fresh a picture the seller sees.

Scheduled exchange pulls changes in batches, report export gives a snapshot at the moment of generation, and direct API access delivers data on request. Below is what each option pays for its speed.

What Matters More — Freshness or Completeness

Scheduled exchange wins where completeness matters: it transfers the entire array of changes and does not depend on external service limits.

But data delay grows along with the interval, and if the connection breaks, you need to be able to catch up on what was missed rather than wait for the next cycle.

Direct API access covers freshness but pays with resilience: under request limits and short-term failures, without a queue and retries, some responses simply never arrive.

In practice, these methods are combined — the schedule maintains the catalog, while the API handles real-time stock and statuses.

How We Choose the Mode for the Task

We look at the seller's profile: number of SKUs, frequency of price changes, order peaks. For a broad catalog with rare edits, scheduled exchange is enough; for dynamic categories, we add direct access with buffering. We keep exports for reconciliation so that discrepancies do not accumulate unnoticed.

We analyze your setup and select a collection mode for the load — with an assessment of delay and sample completeness.

How we build order and inventory accounting

Order and inventory accounting breaks not at the stage of "writing the integration," but earlier — when data from the marketplace seller account, the warehouse, and the accounting database all live in the system at the same time, and no one knows which one is the source of truth.

That is why we start with an audit of the sources: we look at where orders come from, how inventory is written off, where the item master data diverges, and what statuses even exist in each system.

Then we build a sequence of steps where each subsequent one relies on the result of the previous one.

1. Source audit — we record the list of systems, the data refresh frequency, the person responsible for each record, and the points where values diverge.
2. Integration schema — we determine what is transferred and where, at what frequency, on which event, and what is considered the master source in case of a conflict.
3. Matching rules — we link marketplace products to the accounting database's item master, including analogues, kits, and items without an exact name match.
4. Integration implementation — we set up the transfer of orders, statuses, and inventory, error handling, and retries during communication failures.
5. Discrepancy testing — we run real periods, reconcile amounts, quantities, and statuses, and trace every mismatch down to its cause.
6. Support regulations — we describe how to read the integration logs, what to do when an upload hangs, and who is responsible for correcting the master data.
7. Handover and training — we show the client's team the checkpoints and the procedure for typical failures.

This order matters because matching rules written before the audit almost always turn out to be wrong: the accounting database contains duplicates, and the marketplace has items that are not there. Discrepancy testing catches this before launch, not in the middle of a sales peak.

Support regulations close the question of what to do when the marketplace changes the upload format or a new warehouse appears.

What the client receives after implementation

After implementation, seller analytics stops being a set of manual exports — it lives inside the 1C-Bitrix loop and updates on a schedule.

We hand over not "access to a panel," but a working system with clear control points: what is pulled from where, by what rules it is matched, and what to do when there is a discrepancy.

• Configured exchanges between marketplaces, 1C, and the accounting system: synchronization schedule, queue processing, retries on failure, and an operations log that shows when and what was loaded.
• Matching rules for products, warehouses, counterparties, and order statuses — with explicit priorities when a single item can be matched in several ways, and a separate list of exceptions.
• Ready-made reports on sales, stock, returns, and unit economics: a summary across accounts, dynamics by period, breakdown by products and warehouses, export to spreadsheets for further work.
• A dashboard for the manager — key metrics on a single screen, without manual assembly: revenue, margin, turnover, return rate.
• Documentation on the data schema: which fields come from where, which transformations are applied, where historical snapshots are stored.
• Operating procedures: who does what when the numbers diverge, how to add a new marketplace or account, how to update matching rules without stopping exchanges.
• Instructions for employees — short role-based scenarios: operator, analyst, manager. So that a report can be built without contacting a developer.
• Knowledge transfer: a walkthrough of the loop with your team, answers to questions on contentious points, and contacts for escalation.

Such a package removes the main risk — dependence on a single person who "knows how to assemble the numbers." Reports are reproducible, rules are documented, and changes are made according to procedure, not from memory.

Case study: reconciling orders and stock on a marketplace

A marketplace seller worked through 1C-Bitrix: orders landed in the personal account, stock lived in the accounting system, and managers did reconciliation manually using exports.

With 400–600 orders per day, this took 3–4 hours daily, and discrepancies still surfaced only after shipment.

What it was like before implementation

• Reconciliation of orders and stock — manual, once a day, handled by two employees.
• Share of discrepancies between the marketplace account and the accounting system — about 12% of items.
• Cancellations due to "out of stock" — 8% of orders, and each cancellation hurt the seller's rating.
• Stock was updated with a delay of up to several hours: goods were sold when they were no longer in the warehouse.

What was changed

The marketplace account and the accounting system were connected through an exchange: orders and statuses are pulled in real time, and stock is sent back after every warehouse operation.

The seller's analytics on 1C-Bitrix collects data in a single repository, and a reconciliation rule catches discrepancies — it compares items by SKU and quantity and flags mismatches before shipment, not after.

What the result was

• Reconciliation time: from 3–4 hours a day to 10–15 minutes spent reviewing exceptions.
• Share of discrepancies: from 12% to 1.5% of items — the rest is handled by the automatic rule.
• Cancellations due to missing goods: from 8% to 1.2% of orders.
• Stock on the marketplace storefront is updated within a minute after movement in the warehouse.

A separate report on cancellations broken down by reason was also set up — it became clear where the supply chain was failing, rather than just "the item was not available." A month later, the seller stopped keeping manual reconciliation as a daily operation: managers focus on orders instead of comparing tables.

How seller analytics differs from a store's internal analytics

A store's internal accounting and a seller's reporting on a marketplace are built on different data sources, and this is the first thing that determines discrepancies in the numbers.

Internal analytics relies on the platform's own events: orders, carts, card impressions, warehouse movement.

Seller reporting comes from outside — marketplace exports, where data is already aggregated according to its own rules: its own logic for cancellations, returns, commissions, and the distribution of orders between sellers of the same item.

The second difference is data delays. Internal events are recorded at the moment of the action and reach the data warehouse almost immediately, while marketplace exports arrive with a lag: some metrics are closed by the end of the day, financial ones — at the end of the period.

If you compare these streams head-on, the numbers won't match not because of an error, but because of different recording times. That is why in seller reporting, orders and revenue are matched by the period closing date, not by the order placement date.

The third is matching rules. The same item in internal accounting and in the marketplace export may have different identifiers, and the marketplace attributes returns and cancellations to a different period than internal accounting does.

To make the data reconcile, a mapping reference is built: the seller's SKU, the card identifier on the platform, the shipment warehouse. Without it, seller reporting and internal accounting live separately, and reconciliation turns into manual untangling.

In practice, this means that seller analytics is not a copy of internal analytics, but a separate contour with its own sources, delays, and rules.

We bring both streams into a single model: we record where each number came from, as of what date it is closed, and by what rule it was matched. Then discrepancies are visible immediately and explainable, rather than surfacing during report reconciliation.

Common technical concerns before starting

Before starting, the same engineering questions almost always come up: will analytics break the current exchange with 1C, will the site handle the load when exporting large reports, and how quickly does data reach the report. Below are answers to the point, without generalities.

Load: will the site handle report exports?

Heavy reports are computed in a separate environment and do not compete for resources with the storefront. Data is aggregated in batches on a schedule, not in a single query across the entire history.

In practice, this means the response time of the catalog and checkout does not change even when recalculating large periods.

Data delays: how fresh are the numbers in the report?

It depends on the frequency of the exchange with 1C. With incremental export, new orders and stock reach analytics within one synchronization cycle. If near-real-time data is needed, we set up streaming event delivery — then the delay is reduced to minutes rather than hours.

Access security: who will see the seller's numbers?

Access is differentiated by roles: the seller sees only their own metrics, the administrator sees consolidated ones. Permissions are checked on the server side on every data request, not by hiding interface elements. All access to analytics is logged — you can see who exported a report and when.

Maintenance: what happens after launch?

After implementation, a procedure remains: monitoring the exchange, checking data integrity, and updating the module when changes occur in 1C or on the storefront.

We record which metrics are considered reference and compare reports against them — a discrepancy is visible immediately, not a month later.

If any of these points is handled differently in your case, describe the current scheme, and we will come back with an estimate and a work plan.

Let's discuss your seller analytics task

So that the estimate is realistic rather than an "average market" figure, we first understand your data schema and only then calculate the work.

Seller analytics on 1C-Bitrix is almost always non-standard: some metrics come from the marketplace, some from the accounting system, and the scope of work depends on how these sources are reconciled. That's why we start with clarifying questions, not with a price list.

What we clarify during the first conversation:

• which marketplaces and seller accounts are already connected, and which are planned;
• where orders, stock, and prices come from — 1C integration, exports, or manual edits;
• which reports are needed in the end: order funnel, turnover, returns, unit economics per product;
• how data is currently consolidated and where discrepancies exist between the seller account and accounting;
• who will use the reports and at what update frequency;
• which access rights and roles need to be separated between departments;
• whether there are constraints on website load and export timing.

Based on the answers, we map out the data flow schema and propose a format of work: enhancing the exchange module, a separate collection service, or exporting into the reporting system you already use.

Along with the estimate, we send a phased plan — what we do first, what can be postponed, and where access to marketplace seller accounts and the accounting database will be required.

Describe your task in free form: which marketplaces, which metrics are critical, and what is already set up. We'll come back with clarifying questions, an estimate, and a plan — with timelines for each phase and a clear distribution of work between our team and your side.