A unit price with more than 4 decimals is rejected, not rounded
A unit_price with more than 4 significant decimals now answers 422 LINE_UNIT_PRICE_TOO_MANY_DECIMALS instead of being rounded silently. Round to 4 decimals, or send the line total.
The contract has always said unit_price supports up to 4 decimal places, but a price with more was rounded silently to 4: 1000 × 0.12345 was invoiced at 0.1235 with a base of 123.50, and 0.00001 was stored as 0. The invoice then said something different from what you sent.
Now that line answers 422 LINE_UNIT_PRICE_TOO_MANY_DECIMALS and the invoice is not created or changed. Trailing zeros do not count: 10.500000 is still 10.5.
What else changed
- Applies wherever you send a
unit_price: creating and editing invoices, corrective invoices, and recurring invoice templates. - Who is affected: integrations that send prices with 5 or more significant decimals, typically computed by division (
total / quantity) without rounding. - What to do: round the price to 4 decimals before sending it. If what you know is the line total, send it in
total_excluding_taxortotal_including_taxand the unit price is derived from it.
Where to go next
Stripe: manual 0 % rates and the buyer's country on paid invoices
A manual 0 % tax rate in Stripe is invoiced for buyers in the peninsula or the Balearic Islands, and `invoice.paid` reads the buyer's country from the payment.
More than one NIF on the API plan: a 403 that routes to sales
On the API plan with no agreed price, a second NIF, or going Live with several, answers `403 CONTACT_SALES_REQUIRED` with a link to sales.