Bitrix currency setup: where the exchange rate breaks
Multi-currency in an online store rests not on a checkbox in the catalog settings, but on consistency between three entities: the base price currency, the display currency, and the settlement currency in the invoice.
Between them sits the exchange rate — with its own date, direction, and rounding rule. If the chain diverges, the storefront shows one amount, the invoice contains another, and the discrepancy surfaces later in correspondence with the customer.
The most common failure is double recalculation. Price exchange with 1C arrives in the base currency, the integration module applies the rate and writes the result as a price, and the core recalculates it again on output — using the catalog rate. The item quietly becomes more or less expensive, and differently for different price types.
The second class is exchange rate lag. The currency rate in the catalog is updated on a schedule, price exchange with 1C runs in its own window, and the page also lives in cache.
A product is sold at a rate that no longer exists: no one controls the gap between update, application, and cache reset, so the discrepancy fluctuates from an hour to a day.
The third is Bitrix currency setup with multiple price types: each has its own rounding rule and its own automatic recalculation logic. Then the discrepancy between storefront price and invoice amount becomes systemic — discounts are calculated from one base, taxes from another.
We break down how this is closed: from recalculation order to integration with the accounting system.
What correct recalculation of prices and stock provides
Until the rate is recalculated, the storefront and warehouse live by different numbers: the customer sees one amount, the manager relies on stock at the old price, and a third goes into the order.
On multi-warehouse projects, the discrepancy accumulates — some items go negative at cost, and order margin becomes known only after manual reconciliation.
Configured price recalculation by rate works on a schedule: prices are tied to a type and base currency, the rate source is selected, rounding rules and the recalculation threshold are set.
The customer receives a price in the customer currency, while the warehouse and cost are calculated in the base currency — the final margin for each order is predictable.
Warehouse and storefront synchronization closes the second half of the task: stock is deducted at checkout, not by nightly export, so there are no sales "into negative" and no cancellations due to out-of-stock items.
The reserve for an order is held until payment and released on cancellation — the storefront shows real availability.
On 1C-Bitrix, this is solved with a combination of price types, agents, and cart handlers, without manual edits in product cards.
Measurable effect: catalog recalculation takes minutes instead of hours, the share of orders with manual price adjustment falls, and the discrepancy between storefront and warehouse is reduced to isolated items.
Methods of updating exchange rates: manual, scheduled, event-based
The currency rate in the catalog is not one field, but a bundle: the rate value, the base currency, the linkage of prices and pricing rules to it.
Therefore the update mode is chosen not by admin panel convenience, but by two questions: how often prices change and how critical the delay is between a new rate and recalculation.
The exchange rate source is determined separately — official rate, bank or payment provider rate, or a file exported by the accounting system.
If the source is external, we immediately account for behavior when it is unavailable, value history, and the rollback procedure for an erroneously loaded rate.
Comparison of modes
| Variant | When suitable | Limitations |
|---|---|---|
| Manual rate update | 2–5 currencies, rate fixed by contract or rarely changes | Depends on a person: missed update, no history, with frequent edits — discrepancies between rate and price |
| Automatic scheduled rate import | Main currencies with public rates, catalog of hundreds of items | Lag until next run; if source fails, prices remain at old rate, need task execution monitoring and error notification |
| Event-based recalculation | Price must be accurate at the moment of order placement or item save | Load and repeated recalculations, harder to debug; volume limits and recursion protection required |
In practice, modes are combined: manual entry is left for rare currencies, automatic scheduled rate import for main ones, and event-based recalculation is enabled only where price matters at transaction time.
Such a combination prevents a single source failure from rewriting prices across the entire catalog, while rate-price discrepancies are caught in a targeted way.
Procedure for implementing multi-currency on a website
Multi-currency is not a toggle in settings, but a set of rules by which price reaches the catalog, cart, and invoice.
Therefore we structure the work so that each change can be rolled back: first we capture the current price scheme, then design recalculation rules, and only after that touch the production site. Below is the implementation route for multi-currency.
-
Inventory of the current scheme: which price types are involved, which currency is base, where prices and discounts are stored, and who else reads them — exports, marketplaces, accounting system integration.
-
Design of recalculation rules: source and frequency of rate retrieval, recalculation direction, price rounding rules — to which decimal place, in whose favor, and on which ranges, behavior when the rate is missing.
-
Setting up currencies and price types: create currencies, link them to price types, set output formats, markups, and tax-inclusive display, so that storefront and documents show the same thing.
-
Scheduled rate updates: set up automatic updates, a change log, and notification when the rate leaves the expected corridor — otherwise a data error surfaces in already placed orders.
-
Testing in staging: deploy a copy of the catalog and orders, verify recalculated prices on a sample of items, run through cart, checkout, invoices, and reports, separately — rounding at boundary values.
-
Migration to production and handover: enable during a low-load window, record the rollback point, hand over the rate update schedule and description of price rounding rules.
Settings, schedules, and documentation for exchange rates
Settings do not live on their own: the rate changes, the accounting system updates reference data, and prices on the site need to be recalculated so that already placed orders do not shift.
Therefore we hand over the project together with a set of artifacts — from them any engineer not involved in implementation can reconstruct and repeat the logic without correspondence and guesswork.
- Currency cards — which currencies participate in settlements, which is designated base, rounding precision, price display formats in catalog, cart, and emails.
- Rate update schedule — source (manual entry, external service, exchange with accounting system), loading frequency, behavior when the source is unavailable, and rollback procedure to the last correct rate.
- Recalculation rules — in which currency order price is fixed, at which step the rate is fixed, how partial payments, refunds, and debts are recalculated.
- Exchange scheme — which reference data and documents are synchronized between website and accounting system, in which direction, at what frequency, and by what attribute discrepancy is determined.
- Exchange documentation — currency mapping, list of integration parameters, description of handlers and points where to add a new currency.
- Administrator roles — who changes rates, who edits rounding, who has access to manual order recalculation and the full rate change log.
- Verification instructions — acceptance checklist: what to verify after a rate change, connecting a new currency, and updating the exchange module.
The package remains with the client in the repository and internal knowledge base — with it, rate maintenance becomes a routine task for the duty administrator, not a separate request to the developer.
Case study: eliminated price discrepancies between accounting system and storefront
A store with two storefronts and three catalog currencies: prices lived in the accounting system, while on the website they were recalculated during export.
The rate was entered manually once a day, and if it changed on Friday evening, the storefront traded at the outdated value until Monday. Managers reconciled the discrepancy in the order — this manual step was the most expensive point in the flow.
What it looked like before
Standard exchange brought the price in the base currency, while recalculation into the others hung on a separate script that ran on schedule and knew nothing about edits in the currency reference.
Rounding was not fixed anywhere: on the storefront and in the invoice the same item gave different values, and in the cart — a third. Weekly reconciliation consistently found discrepancies across several dozen items, and each was handled manually.
What was restructured
Introduced one base price type and derivatives of it — with an explicit rounding rule at each step. The currency reference was populated from the accounting system, rates are pulled by a scheduled job, not by an operator.
1C-Bitrix in this loop is responsible for calculation, so linkage had to be moved to the price change event and cache had to be reset in a targeted way, not entirely — otherwise the storefront would serve the old value until the scheduled update.
Added nightly reconciliation of the storefront with the accounting system: discrepancies are collected into a report and sent to the responsible person, and price change history is stored separately — any item can be reverted to the previous value without re-export.
Metrics before and after
- Share of orders with manual price correction: 18% → 0.6% (remainder — individual customer terms).
- Reaction to rate change: up to 2 days → up to 15 minutes after publishing a new value.
- Discrepancies in weekly reconciliation: several dozen items → isolated ones, all explained.
- Eliminated repeated catalog export for price: one run instead of three.
The scheme became predictable: price in order, invoice, and storefront is calculated by one rule, and rate change does not require manager involvement.
How manual rate update differs from automatic in Bitrix
Manual mode is entries in the currency reference: for each currency, rate and denomination are stored, and the manager edits them in the admin panel. While there are one or two currencies and the rate is reviewed once a week, the scheme holds.
It breaks unnoticed: the value was updated, but price recalculation runs separately — and before it, old amounts hang on the storefront that the customer carries into the order.
Automatic rate update removes the operation itself: the value comes from a source — central bank or accounting system — on the exchange schedule and is written to the same reference fields.
The schedule is set by an agent: once a day before opening, every few hours, or at the moment a new export appears in exchange with 1C.
Then what matters is not the numbers, but the settings around them: how many decimal places to store, how to round, what to do if the discrepancy with the previous rate exceeds a specified threshold.
The difference is visible in documents. The order stores the rate fixed at checkout, and it is not rewritten retroactively; manual mode easily misses the fixation moment — weekend, holiday, closed admin panel.
Automation writes the value to the log and leaves history: for any date you can see which rate was active, and the exchange can be replayed without manual order edits.
Automation also has specific limitations: it needs a debugged exchange and error handler.
If the source is unavailable, the previous rate should remain and a notification to the responsible person should appear, not an empty or zero value that would cause the catalog to recalculate at zero.
Therefore, in Bitrix currency setup, manual mode is usually left as emergency — with mandatory logging and notification.
FAQ on exchange rates, rounding, and customer settlements
Currency rate in 1C-Bitrix is not one value: rate on date, rate fixed in order, and catalog recalculation rate.
Discrepancy between invoice and catalog is almost always explained by the fact that the order stores the rate at checkout, while the product card shows price at the current rate.
The task is not to "pull" one to the other, but to determine which source of truth for each operation.
A separate fork is price rounding. Rules are set at currency or price type level: to which decimal place, in which direction, and at what moment — before or after recalculation.
If you round before recalculation, the error in a cart of dozens of items creates a noticeable difference with the invoice total, so the order of operations is fixed explicitly.
Order placed at old rate — what to do with it?
The order stores the rate at checkout — this is expected behavior, not an error. We recalculate only by an explicit rule: for example, at payment or shipment at the rate on payment date. The rule is set in configuration so the manager does not edit amounts manually.
How to calculate discounts and markups if prices are in different currencies?
The discount is calculated in the order currency, otherwise its percentage in catalog and invoice will diverge. The order is the same for all rules: first recalculation by rate, then rounding. Markups inherit the same logic.
Why does the invoice differ from the catalog?
There are three typical causes: historical rate in order vs current in catalog, different rounding order, catalog price cache. Diagnostics takes minutes — compare the rate in order, the currency rate in settings, and the total after rounding.
Let's discuss the pricing scheme for your project
For the estimate to be based on the real pricing scheme rather than a standard preset, we need a snapshot of the current configuration and several answers on business logic.
They determine whether we touch the catalog module, discount mechanism, rounding rules, or exchange with 1C.
- Admin access — an account with rights to the catalog module and currencies section, plus access to staging if available: we verify rate and price format edits not on the production site.
- List of currencies — which currencies actually participate in sales, which is considered base for storing prices, and which are only displayed to the customer.
- Rate provider — central bank, commercial bank, exchange, own source, or manual entry: this determines the automatic update schedule and failure handling.
- Multi-currency audit — where prices are currently recalculated: in catalog, cart, orders, exports, and integrations. A discrepancy at one point breaks the final total.
- Rounding and formatting rules — rounding step, direction, separators, currency symbol position in the price template.
- Scenarios for customer groups — retail, wholesale, regions, partners: each group may have its own settlement currency and its own set of rules.
- Adjacent systems — exchange with 1C, payment systems, marketplaces, and feeds: it is important to know in advance who else reads prices from the catalog.
- What has already been tried — previous setup attempts, known errors, and places that must not be touched.
If some data has not been collected — not critical, we will clarify the missing parts in correspondence. Describe the task and send what you have on hand: we will return with an estimate, work stages, and a staging verification plan.