Invoice money field precision
All five money fields on invoice responses are rounded to 2 decimal places, half-up (cent precision):
| Field | Description |
|---|---|
total | Net total amount |
total_paid | Amount paid |
total_shipping | Shipping amount |
total_discount | Discount amount |
total_due | Amount still owed (total − total_paid). Already returned at 2dp before this change. |
Because every field uses the same cent-rounding model, the relationship total − total_paid = total_due holds in the API response. A value stored internally at 4 decimal places (e.g. 347.6550) is served as 347.66.
Note: Before this change,
total,total_paid,total_shipping, andtotal_discountcould carry up to 4 decimal places. If you have previously stored these values you may want to re-fetch and update your records.
Filtering on money fields
Range filters on money fields ([gte], [lte], [gt], [lt], [eq]) apply the same cent rounding before comparison, so a filter bound like ?total[gte]=100 is evaluated against the 2dp value that is also returned in the response body. There is no precision mismatch between what you filter on and what you receive.
Example
Fetch all invoices with an outstanding balance:
GET /external/api/v1/invoices?total_due[gt]=0
Fetch invoices for a company where the net total is in a range:
GET /external/api/v1/companies/{companyId}/invoices?total[gte]=500&total[lte]=1000
Reconciliation in your system
Because all money fields are cent-rounded:
total − total_paidin your code should equal thetotal_duereturned by the API (ignoring any floating-point representation noise — compare after rounding to 2dp on your side).- Do not subtract a manual offset to account for fractional-cent residuals; none exist in the current response.