One kopeck apart: why invoice totals in Bitrix24 and 1C don't match

Invoice totals in Bitrix24 and in 1C, the accounting system most Russian companies run on, differ by a few kopecks. Not always, but often enough, and 1C usually gets the blame: after all, Bitrix shows the "right" total.

An analysis of 7,753 product rows showed the opposite. 1C does the math correctly. The kopecks come from Bitrix24, and its documentation doesn't say a word about it.

Where the kopecks come from

Bitrix24 smart invoices don't round the price to the kopeck when they save a product row. The database holds prices like 805.23809523, 232.66285715, 3784.725. Out of 7,753 rows on this portal, 6,996 had a pre-tax price longer than two decimals. That's 90%.

How such a price appears:

• The manager enters the row total, not the price. Bitrix24 divides the total by the quantity and stores the result as is: 4 × 1625.00000001 = 6500.00.
• Percentage discounts. 7,737 of 7,753 rows had one, and almost any percentage discount leaves a tail on the price.
• The 5% VAT rate. The price with tax is divided by 1.05, which almost always gives an endless fraction.

1C can't store prices like that: a document price is in rubles and kopecks. During the exchange it truncates the price to the kopeck, and the error is multiplied by the quantity. At a quantity of 214, a single row can be off by up to 43 kopecks. The worst invoice on the portal was off by 94 kopecks.

Bitrix24 calculates one document two ways

The second cause is subtler. Within a single invoice, Bitrix24 rounds differently:

• the invoice total is calculated from the sum: add up all rows, round once at the end;
• the tax is calculated per row: round each row's VAT, then add them up.

On the 405 invoices where the two methods give different results, the tax matched the per-row calculation in 404. We had to reconstruct the formulas from the core code (CCrmProductRow::preparePrices) and verify them on all 7,753 rows: the REST documentation describes the price fields without any formulas.

Why you can't adjust 1C

The first idea is usually to tune rounding in 1C so it matches Bitrix. But here 1C follows the law.

• The Russian Tax Code (Article 168, clause 2) requires VAT to be calculated for each line item. So the per-row tax total is the correct one.
• The rules for VAT invoices (Government Resolution No. 1137) require rubles and kopecks. Rounding to whole rubles isn't allowed.

So "fixing" 1C means breaking its correct calculation to match an incorrect one.

What doesn't help

All tested, so you don't have to:

• Price rounding rules in Bitrix24. That's a product catalog feature. It doesn't apply to CRM invoice product rows.
• Precision settings and changing the column type in the database. Only works on-premise. This portal is in the cloud, with no access to files or the database.
• Rounding in 1C. Against the law, see above.

What to send to 1C

The fix belongs in the exchange:

1. Send the row total, not the price. The row total in Bitrix24 is correct. Only the price obtained by division is off.
2. Calculate the document total as the sum of rounded rows. That's not the "Amount" field (opportunity) on the invoice card: it's calculated from the sum.
3. Calculate VAT per row, as the law requires.
4. If the total is fixed, put the kopeck difference on one row, the one with the largest amount. Don't spread it across all rows. 1C:Trade Management 11 has a dedicated discount type for exactly this, "СкидкаНаценкаОкругление" (rounding adjustment).

Two traps along the way

crm.item.productrow.list returns at most 50 rows. It's paginated, and without walking the pages an invoice's rows are silently cut off at the fiftieth. Four invoices on this portal were cut this way, with up to 58 rows each. On the first pass they showed "unexplained" VAT. After loading the missing rows, they matched. If your 1C integration pulls rows with this method, check that it walks the pages. Otherwise 1C receives incomplete invoices.

The "tax included in price" flag isn't always true. One invoice had 51 rows where the flag was off but the price already included tax: 441 against a pre-tax price of 420, exactly 420 × 1.05. The receiving system will add VAT a second time, and the difference will be 5%, not a kopeck.