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

The API delivers amounts with up to 3 decimal places. Apply a single, consistent rounding rule to every amount before you book it into accounting: 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. The API always returns tax_amount. Chift takes it from the POS software when the software provides it, and computes it with the method below when the software does not. Recomputing it yourself from a rate adds a rounding error that the reconciled value does not have. Each order groups its VAT in the taxes array. Each entry holds three fields for one rate:
  • tax_rate: the VAT rate (for example, 21).
  • tax_amount: the VAT amount for that rate.
  • total: the tax‑inclusive amount (TTC) for that rate.
Get the net (tax‑exclusive) amount by subtraction:
Example: total = 12.10, tax_amount = 2.10
  • net = 12.10 - 2.10 = 10.00
Book net on the revenue account and tax_amount on the VAT account, per rate. Each order line also carries its own total, tax_amount, and tax_rate. Use the same subtraction to get the line net when you book at line level.
This is how Chift derives the tax when the POS software provides only a tax‑inclusive amount and a rate. Chift applies it for you and returns the result, so use the value directly. It is shown here to explain the amounts you receive:
Example: total = 3.14, tax_rate = 21
  • net = 3.14 / 1.21 = 2.5950…, returned at 3 decimals as 2.595
  • vat = 3.14 - 2.595 = 0.545
Always reason per VAT rate (and, if you map revenue to several accounts, per account × rate). Aggregate your amounts by rate before you book them. Never collapse everything into a single global total, which would hide compensating rounding differences between rates.

​
➗ 4. Splitting a global discount

This split applies only when you consume the Unified API and book to accounting yourself. Chift’s Sync performs it automatically.
Each line item’s total already includes any line‑level discount. The order’s total_discount field is the sum of all line‑level discounts plus any remaining global discount, and it is tax‑inclusive:
Only remaining_global_discount needs to be split across VAT rates. Compute the residual, then spread it pro rata of each rate’s tax‑inclusive total. To avoid a missing cent, give the remainder to the last bucket rather than round it separately:
Here rate_total is the tax‑inclusive total for that rate and items_total is the tax‑inclusive total of all order lines. Each share is tax‑inclusive. Get its net part by dividing by the rate:
This guarantees that the sum of the per‑rate discount shares equals the remaining 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.