Skip to main content

​
Amounts, roundings and totals

When you push POS sales and payments into an accounting system, the numbers must match to the cent. The sum of your revenue lines, VAT, and payments must equal the order total, and the resulting entry must balance. This guide explains how the Unified API exposes POS order amounts, and the method we recommend to keep them correct once booked. The sections below cover the decimal precision of the amounts you receive, the rounding rule to apply, how to handle VAT, how to split a global discount, the POS‑specific points on tips and payments, and the final reconciliation check.
This guide describes the recommended method, not a constraint the API enforces. When you consume the POS Unified API and write the result into accounting yourself, you are responsible for rounding. If you post through Chift’s accounting Unified API, see also Invoice amounts validation.

​
🔢 1. Decimal precision

The API response may return POS amounts with more than 2 decimals. For example, unit_price, total, or tax_amount can carry up to 3 decimals. The API often derives a net amount from a gross total or a quantity, and it keeps that finer precision.
Treat every monetary value from the API as raw input. Do not assume it is already at 2 decimals. Do not compare two amounts for equality before you round both.

​
🧮 2. Rounding rule

Apply a single, consistent rounding rule to every amount before you book it: 2 decimals, round half up. Examples:
  • a unit_price of 2.599 becomes 2.60
  • a computed net of 2.5950413… becomes 2.60
Avoid “banker’s rounding” (round half to even), which is the default in some languages and libraries. It drifts from amounts that use standard commercial rounding.

​
🧾 3. Handle VAT per rate

Reuse the tax amounts the API provides. Do not recompute them. Each order exposes its VAT in the taxes array, grouped by rate (tax_rate, tax_amount, total), and each line has its own tax_amount. This avoids a rounding error that the source system does not have. If you must derive VAT from a gross (tax‑inclusive) amount and a rate, use the remainder method so that net + VAT always equals the exact gross:
Example: gross = 3.14, tax_rate = 21
  • net = round(3.14 / 1.21, 2) = 2.60
  • vat = 3.14 − 2.60 = 0.54.
Always reason per VAT rate (and, if you map revenue to several accounts, per account × rate). Group your lines by tax_rate before you compute net and VAT. Never compute on a single global total, which would hide compensating rounding differences between rates.

​
➗ 4. Splitting a global discount

When a discount applies to the whole order rather than to a single line, spread it across the VAT rates pro rata of each rate’s base. To avoid a missing cent, give the remainder to the last bucket rather than round it separately:
This guarantees that the sum of the per‑rate discount shares equals the global discount exactly.

​
💶 5. Tips and payments

Two POS‑specific points determine whether your sales side matches your payments side:
  • Tips are separate from the order total. total does not include total_tip (order) or tip (payment). Book them on a dedicated account. Do not add them to revenue.
  • Only count valid payments. Exclude payments whose status is Canceled or Failed before you sum them.
The order total is tax‑inclusive (TTC). Your coherence check on the payment side is:
This term appears only when an order is invoiced and settled later (B2B). For a fully paid order, it is zero.

​
✅ 6. Reconcile and balance

After you round each amount per rate to 2 decimals separately, a residual difference of a few cents can remain between the sum of your booked lines (net + VAT) and the order total. Book that residue on a rounding account so the entry balances (debit = credit):
  • a gain account for a positive difference (for example, 758);
  • a loss account for a negative difference (for example, 658).
A residue of a cent or two is normal rounding and belongs on the rounding account. A difference larger than ~1 € is not a rounding issue — it signals inconsistent source data. Stop and investigate rather than absorb it.

​
In short

Round every amount to 2 decimals half‑up, reuse the VAT the API provides, reason per rate, split global discounts with the remainder on the last bucket, keep tips out of revenue, and close each entry with a reconciliation that sends any residual cent to a rounding account. This is what keeps your accounting totals equal to the original POS amounts.