Automatic price updates break on supplier price lists
Automatic price updates break not at the export stage, but at the input — when a supplier's price list arrives in a format that worked yesterday but today has diverged from reality.
One supplier sends an XLS with merged cells and the SKU in the third column, another sends a CSV with a semicolon delimiter and an encoding, a third drops a link to a file that updates once a day at an off-peak time.
A parser tailored to a single template silently skips rows or pulls a price from the neighboring column — and a product appears on the storefront at a purchase cost that no longer exists.
Then product matching begins. Supplier SKUs don't match the cards in the catalog: somewhere there's an extra prefix, somewhere the case is different, somewhere a product is in the price list but missing from the nomenclature, and vice versa.
If you match by name, duplicates and typos produce false pairs — two different items collapse into one, and the price of one lands on the card of the other.
Price discrepancies between purchase cost and storefront accumulate unnoticed in such cases: the manager sees a number they trust, while the margin is already negative.
A separate category of failures is manual edits. A markup was adjusted by hand for a promotion, an individual price was set for a regular customer, a product was temporarily hidden from stock — and the next price list upload run overwrites all of it.
Without a change log and priority rules, it's impossible to tell which price was set deliberately and which came from the file.
We break down how this is closed: how product matching rules are built, where manual edits are stored, and how to set up price list uploads so that price discrepancies are caught before publication, not after a customer complaint.
What price automation on the storefront delivers
Price automation is not a "refresh button" but a measurable change in how the storefront operates.
The speed of updates stops depending on whether a manager has freed up: the supplier's price list arrives on schedule, items are recalculated in batches, and by the start of the shift the storefront already reflects the morning prices.
In practice, this turns updating from a daily operation of "when someone gets around to it" into a background process that runs independently of how busy people are.
The automation share is the second measurable indicator. We calculate it honestly: how many items were updated without manual intervention, and how many went into the queue for review.
A healthy storefront keeps most of the catalog on autopilot, and manual work remains exactly as much as the business logic requires: new products, items without matching, disputed markups. Everything else is a regular recalculation by the rules.
The class of errors involving outdated prices is closed structurally. When the price on the storefront comes from the same source as in the accounting system, the discrepancy of "old on the site, new in the order" simply does not arise.
This is not about employees' attentiveness, but about the fact that manual transfer of values between systems is excluded from the process — and along with it go typos, lost rows, and forgotten items.
Storefront accuracy becomes a manageable quantity rather than a hope. The update log shows when the price list arrived, how many items changed, what fell into exceptions and for what reason.
If a supplier delayed the file or sent a corrupted format, it is visible immediately, not a week later through a customer complaint. Such control turns pricing from a risk zone into a predictable area.
The bottom line in points worth checking during implementation: updates run on schedule without manual triggering; the share of automatic items is measured and growing; the price discrepancy between the storefront and accounting tends toward zero; every change leaves a trace in the log; supplier failures are caught before the buyer sees them.
If even one point is not met — the automation is incomplete, and this is visible from the metrics, not from feelings.
Methods for synchronizing supplier price lists
The synchronization method is chosen not based on developer convenience, but based on how the supplier delivers data and how often it changes.
In practice, there are three working schemes, and almost always they are combined: some suppliers are locked behind files, some are ready for direct exchange, and some — only for export to an intermediate database.
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled files (CSV, XLSX, XML, YML) | The supplier provides an export by email, FTP, or via a link; the price list changes once a day or less often | Delay until the next run; if the format breaks, parsing fails; duplicates and empty prices arrive "as is" |
| Exchange via an intermediate database | Multiple suppliers, custom matching rules, a history of prices and stock is needed | Requires a separate environment and a cleanup policy; a discrepancy between the database and the catalog if the exchange stops |
| Direct connection to the supplier's API | Up-to-date stock and prices are needed at the moment of ordering; the supplier provides a stable interface | Limits on the number of requests; unavailability on the supplier's side; if the interface changes, the exchange needs to be modified |
Scheduled loading remains the baseline mode: the agent runs on a schedule, fetches the file, parses it, and updates only the changed items. The key here is item matching: by the supplier's SKU, by barcode, or by the "SKU + manufacturer" combination.
If the combination is ambiguous, the item goes into a queue for manual review rather than overwriting the price at random.
Exchange via a database is convenient when there are many suppliers and each has its own logic. Data first lands in intermediate tables, undergoes checks for gaps and anomalies, and only then updates the catalog.
Such an environment provides history: you can see when the price changed, where it came from, and why an item was not updated.
A direct connection to the API provides minimal delay but requires handling failures: timeout, request limit, temporary unavailability.
The exchange is built so that a supplier failure does not stop the catalog — the last correct prices remain in effect, and discrepancies go into a report. We'll break down how this is configured for a specific set of suppliers.
How we implement automatic price updates
We start implementing price updates with an audit: we look at what formats supplier price lists come in, how often they change, and whether they include SKUs and barcodes for unambiguous matching to catalog items.
At this stage, discrepancies surface that caused failures during manual uploads: different units of measurement, duplicate entries, and missing prices for some warehouses.
Next, we design the matching scheme — which key links a supplier's item to the product page, what to do with new and disappeared items, how to handle multiple suppliers for a single product, and which rule to use when selecting the final price.
- Audit of price lists and current pricing rules: formats, frequency, markups, rounding, minimum margin.
- Designing the matching scheme: linking keys, handling duplicates, rules for new and discontinued items.
- Setting up the upload: parsing supplier files, validating rows, writing prices and stock to the catalog on a schedule.
- Setting up recalculation rules: markup by category, rounding, minimum price threshold, supplier priority.
- Testing on a staging copy: running real price lists, comparing the result against expectations, handling errors and rollback.
- Moving to the production environment: scheduled runs, monitoring the first update, logging changes.
- Handing over the procedures: instructions for adding a supplier, troubleshooting upload errors, and manually adjusting prices.
Each stage ends with a verifiable result, so the launch doesn't turn into "we turned it on and hope for the best." After the procedures are handed over, price updates run without manual effort, and changes are recorded in a log — you can see when and why a price changed.
Markup rules, rounding, and supplier priorities
Pricing rules are described declaratively — as a set of conditions that the update engine applies to each catalog item when a new price list is received.
The markup is set not by a single figure for the entire catalog, but by a matrix: by category, by brand, by purchase price range, by specific supplier.
For each combination, either a percentage, a fixed surcharge, or a formula based on the purchase price is stored — and when a price arrives, the system itself determines which rule was triggered.
Rounding is a separate layer on top of the markup, and here the sequence matters: the price rule is applied first, then rounding, otherwise the result "drifts" on every recalculation.
The step and direction are configurable — to tens, to hundreds, psychological endings like 90 or 99. For categories with a small price step, rounding up protects against selling below the purchase price; for large ones, it smooths out jumps so the price doesn't look random.
When the same product is available from several suppliers, source priority comes into play. We build a queue: primary supplier, backup, then the rest — and the price is taken from the first one who provided a current price list and passed the availability check.
If the primary one stays silent longer than the specified period, the system automatically switches to the next one instead of holding on to an outdated price. Overlaps by SKU and barcode are consolidated into a single card so that the product isn't duplicated in the catalog.
Exceptions are what make the rules meaningful in the first place. Items with a manual price, products on promotion, bundles, and services are flagged and completely excluded from automatic recalculation: the engine sees them but doesn't touch them.
Categories with a negotiated price and items where the markup is set individually for a client are handled the same way.
Separately, we keep a log: for each card you can see which rule was applied, which supplier the price came from, and when — this eliminates "why is the price like that" questions during review.
The logic of the rules lives in the 1C-Bitrix configuration, not in the template code, so marketing can change the markup or supplier priority without involving a developer — and the next catalog recalculation already runs under the new conditions.
What the client receives after exchange setup
After the exchange is delivered, the client is left not with a "configured script" but with a package that can be handed over to another engineer or contractor without verbal explanations. Below is what exactly is documented in the documents and configurations.
- Loading configurations — exchange profiles for each supplier: source (file, link, API), schedule, behavior on failure and restart. Adding a new supplier comes down to copying the profile and editing the source.
- Mapping schema — a correspondence table: supplier SKU, item code in 1C, units of measurement, pack multiple. Rules for items without an exact match are described separately — by name and characteristics.
- Markup and rounding rules — where the price is calculated: in 1C or on the website side, how category coefficients are applied, the minimum margin and the threshold below which the price does not drop automatically.
- Exchange logs — a history of runs with the number of processed rows, a list of rejected items and the reason for rejection. The log shows that a discrepancy is a rule decision, not a failure.
- Instructions for employees — short procedures: how to run the exchange manually, how to read the log, what to do when items are rejected en masse, and how to temporarily pause updates for a specific supplier.
- Rollback regulations — how to restore previous prices for the entire upload or for a specific category if a supplier sent an incorrect price list.
- Control points — a list of checks after each update and the person responsible for responding to notifications.
The package remains yours: the exchange does not depend on who maintains it next. Describe how many suppliers you have and in what form they provide price lists — we will come back with an estimate and a plan.
How price updates in Bitrix and Bitrix24 differ
These are two different loops, and confusing them is the main reason why prices on the storefront diverge from the warehouse.
"Bitrix: Site Management" is the storefront: the site catalog, trade offers, discount and markup rules live in information blocks and are recalculated on the site side.
"Bitrix24" is the accounting loop: deals, invoices, warehouse stock, and supplier price lists, from which prices flow to the storefront.
Updating prices in the first case changes only what the customer sees; in the second, it records the purchase cost and stock, and the storefront receives an already recalculated result.
The key difference is where the pricing rules are stored. On the site, it is a markup on a price type tied to a section or brand: change the rule — and the entire product group is recalculated.
In the accounting system, the rule lives in the agreement with the supplier and the currency exchange rate, so the price arrives already factoring in the purchasing logic.
If rules are set in two places at once, during synchronization they begin to conflict, and the storefront shows whichever value's exchange ran last.
The link between the storefront and the warehouse relies on exchange: the accounting system sends prices and stock, the site catalog receives them and distributes them across trade offers.
Frequency and order matter here — stock arrives first, then the price, otherwise the product is sold at the old cost for a couple of minutes. With dropshipping, a third participant is added: the supplier's price list.
Its prices go into the accounting system, and from there to the storefront, and the gap between purchase and sale becomes manageable.
The practical takeaway: updating prices on the site and synchronizing in the accounting system solve different tasks and are configured separately.
First we establish the source of truth for each price, then we build the exchange — that way the site catalog and the warehouse do not diverge, and automatic supplier price updates work predictably.
Case study: price updates for an electronics supplier
The client is an electronics distributor with a catalog of 18,000 SKUs and 40+ active suppliers. Price lists arrived in a jumble: XLS exports, CSV over FTP, and some items only through the supplier's personal account.
The manager consolidated everything manually: matched SKUs, caught typos in names, and transferred prices into product cards. The full cycle took 2-3 days, and all that time part of the catalog was selling at outdated prices.
What was changed
We set up the exchange on the 1C-Bitrix side: for each supplier — its own upload profile with matching rules by SKU and barcode, normalization of units of measurement, and markup by category.
Discrepancies that the system could not resolve automatically were not "swallowed" but dropped into a separate queue for confirmation — indicating exactly what did not match.
We added price history for each item and a rollback rule: if a new price deviates from the previous one by more than a specified threshold, the exchange is paused until confirmation. This cut off errors in supplier price lists that previously went on sale.
Result
| Metric | Before | After |
|---|---|---|
| Share of manual edits | ~35% of items | 4-6% |
| Catalog update time | 2-3 days | 40-60 minutes |
| Items with price discrepancies | hundreds per week | a handful |
Client feedback: "We used to be afraid to touch price lists on Friday — we knew that by Monday half the catalog would have discrepancies. Now the exchange runs at night, and in the morning the manager sees only those items where a human decision is really needed. Time has been freed up for working with the assortment rather than reconciling tables."
We also set up an exchange log separately: for each supplier you can see when the upload ran, how many items were updated, and what went into the confirmation queue.
If a supplier changes the export format, it is visible on the very first run, not a week later from customer complaints.
Common technical concerns about price updates
The concerns are usually the same: what to do with items that didn't match, how to roll back a failed upload, and how to update prices if the supplier has no software interface at all. Below are short answers to each.
What should be done with products that didn't match the price list?
We don't delete or zero out anything. Such items go into a discrepancy report: supplier SKU, name, price from the file.
From there, two paths are possible — refine the matching rule (by code, barcode, or a "brand + SKU" combination) or link manually through the interface. Until the conflict is resolved, the product keeps its previous price and remains available for ordering.
How do you roll back a failed upload?
Before every update, a snapshot of prices and stock is saved. If after the upload we see a spike in errors or prices going negative, the rollback restores the previous state entirely — across all items or for a specific category. In addition, a log is kept: you can see which file arrived, when, and how many rows changed.
The supplier has no API — is updating even possible?
Yes. We work with whatever is available: a price list by email, an export via a link, a file on FTP, a table in the cloud. The loader parses the format, brings the columns to a unified form, and puts the data into an update queue.
If the supplier is ready to provide data by machine, we set up direct exchange — it's faster and without manual steps.
How safe is this for a live website?
The update runs in batches with a load limit, so the catalog remains available to shoppers. Prices change atomically: a visitor won't see an intermediate state.
Errors on individual items don't stop the entire upload — problematic rows go into the report, while the rest are applied.
What about markups and different supplier currencies?
Markup rules are set by category, brand, or a specific supplier and applied on the fly. Currencies are converted to the working one at the rate on the upload date, and rounding is configured separately — so that prices like 1,234.5678 don't appear.
If your case isn't on the list — describe how the supplier transmits data and what you've already tried, and we'll get back to you with an estimate and a plan.
Let's discuss your price update task
To come back with an estimate and a work plan rather than generalities, we need baseline data about your pricing setup. Tell us where supplier price lists come from and in what form: a download via link, a file by email, a table in the cloud, or an exchange via API.
This determines whether we build file parsing, pull data on a schedule, or set up a direct exchange taking into account the limits on the supplier's side.
Next, it's important to understand how prices work now. Do you update them manually in the admin panel, pull them with a script on a schedule, or are some items not synchronized at all?
Are there markups, rounding rules, different prices for customer groups, and a product linked to several suppliers at once. This defines the recalculation logic and which conflicts will have to be resolved automatically.
- what price sources exist and how often they change;
- in what format the data arrives and whether there is API access;
- how the update is set up now and where it breaks;
- what markup, rounding, and supplier priority rules are in effect;
- what exactly you want to automate: intake, recalculation, publishing, or all at once;
- what constraints there are on catalog load and downtime.
Describe the task in free form — that's enough for us to come back with an estimate and a work plan.
If it's more convenient, attach a sample price list and a screenshot of the current process: with them we'll spot the bottlenecks faster and propose a scheme that won't require rewriting the catalog.
