Illustrative example: one program sends an order amount. Another saves the number without its currency and substitutes its own default. The field is populated and the integration reports success. The manager discovers the problem in a report and unexpectedly becomes a currency detective.
For an integration, an amount is more than a number. Its meaning travels with it: currency, amount type and conversion rule. Check this both for exchanges involving Bitrix24 and when keeping a different CRM, or customer relationship management system.
Define which amount you are sending
Price before discount, order total, amount paid and outstanding balance can all hide behind a short field label, “Amount”. Record which value is the source and who changes it.
Send currency as an explicit agreed code. A screen symbol helps people, but an integration needs a stable reference. Do not infer currency from interface language, customer country or website address: these are different attributes.
For a company in Kazakhstan, check KZT for tenge separately if using local currency. Overseas contracts may use another currency; a regional setting must not silently replace it.
Preserve the original value during conversion
If one system requires a base-currency amount, agree the rate source, effective date, conversion direction and owner of rate updates. Keep enough information to understand how the result was calculated.
Do not convert the same amount again at every transfer stage. It should be clear which value is original and which is already converted. Otherwise technically successful transfers will multiply the business meaning along with the figures.
According to official Bitrix24 instructions, CRM currency rates do not update automatically; they are edited manually. Do not promise current rates by default. If a separate update mechanism exists, check its source, schedule and failure behaviour.
Agree precision and rounding
A decimal comma in a file and a decimal point in a programmatic exchange may need different parsing rules. A thousands separator must not become part of the number. Check the stored value, not only its attractive display.
Define whether rounding occurs on individual product lines or after addition. If systems calculate differently, explain a discrepancy through the rule rather than repeatedly correcting it by hand.
Bitrix24 exchange-rate settings have precision limits described in the same instructions; a quantity of currency units can be used where needed. Do not substitute “everything is one-to-one” for these parameters. Do not change the base currency on a live portal for an experiment without assessing the consequences.
Test with training records
Prepare an ordinary order, an order with a fractional amount and a record in another currency. Compare the source amount, currency code, saved value and report display for each.
Then try an unknown code and an empty currency. An agreed response is to stop the disputed record and show the cause to an owner, rather than silently selecting any available currency. This is an integration requirement, not a guarantee built into every connector.
Test the reverse direction too, if it exists. A round trip must not gradually change the amount through repeated conversions and rounding.
What to bring to a review
Bring anonymised examples from both systems, field definitions and the rule your company considers correct. You do not need to decide which program to replace first: fixing currency transfer and calculation may be enough.
Use the QQDev REST API development page to discuss this exchange. Start with one disputed record and the expected result. That is more useful than asking for “matching amounts” without defining the amounts themselves.