Automatic price updates break on supplier price lists
Automatic price updates do not rest on loading a file, but on parsing what the supplier actually sent.
A supplier's price list arrives as a CSV with a semicolon delimiter, as an XLS with merged header cells, as XML on a schedule, or simply as a link to an export that changes every week.
An SKU in one file has leading zeros, in another it has a warehouse suffix, the unit of measure is either "pcs" or "pack", and the price column suddenly shifts one to the right because the supplier added a column.
A script written for the previous version of the file silently imports garbage: the price lands in the quantity field, and the old price stays on the storefront.
Then a chain kicks in that is exactly what costs money.
A price desync between the website and the price list is invisible until the first order: a customer places an item at a price that no longer exists, a manager confirms it manually, and at the purchasing stage it turns out that the procurement cost is higher than the sale price.
In dropshipping this is critical — margin is eaten away on every such deal, and stalled orders have to be sorted out one by one.
Import errors do not surface immediately, either: a broken SKU simply fails to match a product, the row is quietly skipped, and the item lives for weeks with an outdated price.
Manual price list uploads do not solve the problem, they mask it: while a manager checks files by eye, some suppliers are updated and some are not, and the storefront simultaneously shows prices from three different dates.
Hand-rolled scripts without validation and a failure log make it worse — when the format changes, they either stop silently or overwrite correct data.
Let's break down how this is closed: nomenclature matching, price validation before writing, and discrepancy control on every import.
What price and stock exchange setup provides
Price and stock exchange is built on regular import of supplier price lists into the 1C-Bitrix catalog with recalculation of trade rules and markups on the system side.
Each update cycle runs on a schedule, not on a button press: the agent fetches the file or the service response, matches items by SKU and barcode, updates the purchase price, stock, and availability status, then recalculates the retail price according to the defined rules.
Items that are missing from the new price list are marked as unavailable rather than deleted — order history and warehouse linkage are preserved.
Update speed stops depending on catalog size: incremental parsing processes only the changed rows, so a price list with tens of thousands of items completes in minutes rather than hours.
This directly affects the share of successful orders — the customer places a purchase at the price that was current at the time of checkout, not at the time of the last manual edit.
What changes in numbers
- Manual operations for editing prices and stock are reduced to exception handling: the engineer looks only at items that the system could not match.
- Catalog freshness is maintained at the level of the exchange cycle — the discrepancy between the supplier price list and the storefront is measured in minutes.
- Order cancellations due to "price changed" disappear: the customer sees the same price that the system confirms upon reservation.
- Supplier stock is synchronized with the storefront, so an item is taken off sale immediately after it runs out in the warehouse.
Where the effect is most noticeable
On catalogs with frequent changes in purchase prices — electronics, building materials, auto parts. Here manual updating physically cannot keep up with the supplier, and price exchange becomes not an optimization but a condition of operation.
Additionally, an exchange log is configured: you can see when the last cycle ran, how many items were updated, and which rows require attention.
Integration options: from file exchange to direct connection
The method of obtaining prices determines how quickly a supplier's price list reaches the product card and what happens when the supplier changes the export format.
In practice, a choice is made among four schemes, and it is almost always a trade-off between update speed and resilience to failures.
| Option | When it fits | Limitations |
|---|---|---|
| CSV/Excel on a schedule | The supplier provides a price list as a file once a day, the nomenclature is stable | Delay until the next export; breaks when columns or encoding change; no real-time stock |
| Supplier API | Up-to-date prices and stock are needed, the supplier provides documented access | Dependence on request limits and the availability of a third-party service; if a failure occurs on their side, updates stop |
| Intermediate database | Multiple suppliers, different formats, a unified price history is needed | Requires a separate environment and a synchronization schedule; harder to maintain |
| Manual upload | One-off supplies, small volume, prices change rarely | Human factor: a missed price list, a typo, a duplicated item |
File exchange remains the cheapest to launch: a script retrieves a CSV on a schedule, matches rows to products by SKU or supplier code, and updates prices. The weak spots are predictable — delimiter, encoding, extra columns, duplicate SKUs.
That is why imports are built with a log: how many rows were accepted, how many were not matched, which items were skipped.
A direct API connection removes the delay but shifts the risk to third-party infrastructure.
What matters here is retries on errors, a cache of the last successful values, and the rule: if there is no response, the price is not reset to zero but remains unchanged until the next successful request.
An intermediate database is needed when there are multiple suppliers — it brings formats to a single form and stores a history of changes.
The choice of method is dictated not by technology but by the supplier's mode of operation and the cost of an error in the price. Let's break down how this is handled for a specific price list.
How we implement automatic price updates
Implementing automatic price updates starts with an audit: we look at how suppliers provide their price lists — an export via a link, a file by email, a table in a portal — how often prices change and by what rules markups are calculated.
At this stage we record discrepancies between the catalog and actual stock levels: these are most often what leads to sales at outdated prices and manual edits in orders.
Next, we design the exchange scheme and matching rules. Each supplier is assigned its own source and polling schedule, products are linked by SKU and barcode, and disputed items are sent to a separate list for manual review.
Pricing rules — markup, rounding, minimum margin, supplier priority for duplicates — are described explicitly so that the logic doesn't live only in one employee's head.
- Audit of price lists and current pricing rules: sources, frequency, formats, bottlenecks.
- Design of the exchange scheme: product matching, supplier priorities, loading schedule.
- Configuration of recalculation rules: markups, rounding, minimum margin threshold, handling of missing items.
- Test synchronization on a copy of the catalog: we compare the result against the price list line by line and catch false matches.
- Scheduled launch with a change log and notifications about loading errors.
- Handover: procedures, a guide for the manager, training on handling disputed items.
After launch, we run synchronization under supervision for the first few weeks: we check the log, see how many items go to manual review, and fine-tune the matching rules.
Once the share of automatically processed lines reaches a stable level, we hand the system over to your team — with clear procedures and control points.
What the client receives upon completion
The deliverable is not a "configured website" but a package that allows the system to be operated and handed over without us. All artifacts are versioned in the project repository: changes are visible in the history, and rolling back any rule takes a single command.
- Product matching rules. A mapping table of "supplier SKU → catalog card" with priorities: exact match by code, then by the "brand + SKU" combination, manual exceptions, and a list of conflicts that the agent does not touch. Separately — behavior rules for discrepancies: zero out the stock, hide the item, or keep the last price.
- Update agent configuration. Settings for background jobs: run interval, batch size, timeouts, retries when the source is unavailable, limits on the share of changed prices per run. This also includes protection against "garbage" price lists: if a supplier provides a file with obvious anomalies, the update is not applied, and the manager receives a notification.
- Update policy. A document with the schedule for each supplier, run windows, the procedure for failures, and checkpoints: how many items were updated, how many went into conflict, how many were discarded.
- Instructions for managers. How to view the price history for a product, how to remove an item from auto-update, how to resolve a matching conflict, and how to revert to the previous value.
- Logging and reporting. Run logs with filtering by supplier and date, export of changes for a period, summary of unprocessed items.
- Integration diagram. How the exchange works: where price lists are pulled from, where the intermediate table is stored, and at what point the data enters the catalog.
- Access and handover. Accounts, keys to sources, permissions for jobs — set up so that the client's team can work independently.
Describe how many suppliers you have and in what form they provide prices — we will get back to you with an estimate and a work plan.
Case study: how a dropshipping store switched to automatic price updates
A dropshipping store with an assortment of several thousand items ran on 1C-Bitrix and received price lists from three dozen suppliers. Once a week, a manager exported the files, consolidated them manually, and uploaded them to the catalog.
By the time of upload, some prices were already outdated, and discrepancies surfaced only at the order confirmation stage — the customer saw one amount, the supplier invoiced another.
What it was before
Price lists arrived in different formats: XLS, CSV with different delimiters, exports from suppliers' personal accounts. Items were matched by SKU, but for some suppliers the SKUs did not match the catalog cards — they had to be added manually.
Updates took 6-8 hours of working time per week, and even then 12-15% of orders were canceled due to an outdated price or out-of-stock items.
What was changed
An auto-update pipeline was set up: cron agents fetch price lists on a schedule, a parser brings them to a unified structure, and a matching module links items by SKU and name with a match threshold.
Price discrepancies above a set percentage are not applied automatically — they go into a queue for manager confirmation. Stock levels are updated together with the price, and items with zero stock are hidden from the catalog until the next delivery.
1C-Bitrix in this scheme is responsible for the catalog and the cart, while the exchange logic is moved to a separate service — the update does not block the storefront and does not bring down the site when a large price list is uploaded.
What it became
Prices are updated daily, and for key suppliers — several times a day. Manual work was reduced to handling the discrepancy queue: 30-40 minutes per week instead of a full day.
The share of cancellations due to price and availability dropped from 12-15% to 2-3%, and conversion to a confirmed order grew — the customer sees the current amount right away.
Rollback was also addressed separately: each update is written to a log with the previous values, so an erroneous upload can be canceled selectively without restoring the entire catalog.
How is automatic price updating different from manual import?
Manual import is a one-time action: an employee exports the supplier's price list, brings it to the catalog format, matches items by SKU or name, and uploads it.
The problem is that the price list lives its own life — the supplier changes prices, discontinues items, and adds new ones. Between two exports, the catalog shows outdated data, and a customer's order gets rejected already at the confirmation stage.
Automatic price updating works not on an employee's schedule, but on a defined routine: the price list is fetched at a set frequency, matching follows pre-configured rules, and changes are applied to the catalog without human involvement. The update frequency no longer depends on who is on shift today and how many other tasks they have.
The labor costs differ not by a factor, but in nature. Manual import is a repetitive operation that consumes hours on every export and still doesn't scale: the more suppliers and items, the higher the load.
Automation moves the effort to a single point — configuring matching rules and handling exceptions — and after that the process runs on its own.
The risk of errors during manual upload is distributed across the entire chain: the wrong column, a shifted row, a forgotten markup, an item with no stock but with a price. Each such error either sells a product at a loss or shows the customer a price that doesn't exist.
The automatic loop validates data before applying it — it filters out items with no stock, checks the price change range, and logs discrepancies.
This directly affects margin. While the catalog lags behind the price list, some orders go through at the old price, and the seller covers the difference.
Regular updating keeps the markup within a defined corridor: the rule recalculates the price from the purchase price taking into account rounding rules and minimum margin, while anomalous spikes go to manual review rather than into a sale.
Technical doubts and integration questions
Integration with third-party catalogs almost always runs into the same questions — let's sort them out before work begins, so we don't have to figure out the details along the way.
In what form does the supplier provide data, and what if the format "goes sideways"?
We work with whatever the supplier has: a CSV/XLSX export, API exchange, a file on FTP, or a link to a price list. At the input we apply normalization — bringing SKUs, units of measurement, and delimiters to a unified form, otherwise product matching falls apart.
If the supplier changes the file structure without warning, the parser doesn't fail silently: the discrepancy is logged, and prices for the affected items are not updated until it's resolved.
How often are prices and stock updated?
The frequency is set by a schedule, not "whenever it happens": once an hour, once a day, or according to the supplier's schedule.
For fast-moving items it can be set more often, for the long tail — less often, so as not to overload the catalog with unnecessary recalculations.
The exchange runs in batches rather than a single request for the entire catalog — that way it survives a connection drop and resumes from where it stopped.
What about security and access?
We store access credentials to the supplier's API and file storage in a secure form, not in open code, and grant only the minimum necessary rights — read-only access to the catalog.
All exchanges are logged: you can see when an export arrived, what changed, and who initiated the run. This also resolves the question of "what if the supplier revokes access" — switching to a backup source doesn't break the catalog.
How are errors handled, and can a failed update be rolled back?
Each update is a separate operation with a rollback point: if the prices come in corrupted, we restore the previous state of the catalog rather than fixing it manually.
Errors are divided into temporary ones (network, API unavailability) — these are retried automatically, and semantic ones (item missing, SKU changed) — these are collected into a report for review. That way a supplier failure doesn't turn into a store failure.
If your case isn't on the list — describe the task, and we'll come back with an estimate and a plan for your catalog and sources.
Let's discuss your task of updating prices
To provide an estimate and a work plan, we need to understand your setup: where supplier price lists come from, how often they change, whether there are rounding and markup rules, and what to do with out-of-stock items. The more specific the inputs, the more accurate the timelines and the fewer revisions at the start.
Describe the task in a format convenient for you — we'll get back to you with an estimate and a work plan:
- list of suppliers and price list formats: export via a link, file by email, exchange via API or an intermediate table;
- pricing rules: markup by category, rounding, minimum margin, manual prices that must not be overwritten;
- behavior when an item is out of stock: hide the position, keep it with a note, or remove it from the listings;
- requirements for update frequency and the acceptable delay between a price change at the supplier and on the website;
- access and restrictions: who is responsible for price lists, whether there is a test environment, how changes are approved;
- current challenges: price discrepancies, stuck orders, manual edits that eat up managers' time.
Then we proceed step by step: we analyze your setup, prepare an estimate and a work plan with stages and checkpoints, agree on the launch order, and only after that do we start.
Contacts for communication and a convenient discussion format are up to you — we'll take care of the rest.