Changelog 2026-09-14

Sep 14, 2026 - 6 min read - 1088 words

Statistics now cover any period you ask for, products finally know both of their prices, and e-invoicing statuses speak the platform’s language.

Statistics, over any period

The statistics endpoints used to think in calendar years and months. They now take a date range and a bucket size, like the dashboard does.

Every endpoint that covers a period accepts the same three parameters:

from and to — an inclusive date range, which takes precedence over year
year — shorthand for a whole calendar year, defaulting to the current one
periodicity — Daily, Weekly, Monthly (the default), Quarterly or Annually

Each bucket carries its own range, and a partial flag set when the requested range clipped it. A March bucket in a range ending on the 10th holds ten days of activity, so do not compare it with a full February at face value.

New endpoints:

GET /v1/Statistics/TurnoverComparison — turnover over a period against the same period one year earlier and against the period of equal length just before it. Pass expenses=true for purchases, and paid=true to count what was settled rather than what was invoiced.
GET /v1/Statistics/CashFlowByPeriodicity — receipts, expenses and profits, each as settled, outstanding and projected. Every list shares the same buckets, so index N is the same period throughout.

GET /v1/Statistics/TurnoverEvolution follows the same model. It takes from, to, year and periodicity, and compare (0 to 2) returns the same period one and two years back as extra series. It can also break down two new dimensions through type:

Margin — what the lines brought in, less what their goods cost
Discount — the gap between the gross amount and what was actually invoiced, line and document discounts included

⚠️ Breaking change: TurnoverEvolution now returns a single TurnoverEvolutionResult object instead of an array of years, and its years parameter is replaced by compare. The series are in series, the requested period first.

⚠️ Breaking change: these endpoints are removed, replaced by the ones above:

Removed	Use instead
`GET /v1/Statistics/SalesTurnoverStatistics`	`TurnoverComparison`
`GET /v1/Statistics/ExpensesTurnoverStatistics`	`TurnoverComparison?expenses=true`
`GET /v1/Statistics/MicrobusinessSalesTurnoverStatistics`	`TurnoverComparison?paid=true`
`GET /v1/Statistics/MicrobusinessExpensesTurnoverStatistics`	`TurnoverComparison?expenses=true&paid=true`
`GET /v1/Statistics/StatsByMonth`	`CashFlowByPeriodicity`, or `TurnoverEvolution` for invoiced sales and expenses

For a micro-business, paid is always applied: it is taxed on what it collects, not on what it invoices. Check company.isMicroBusiness in GET /v1/Settings before reading the numbers.

Who owes you, and how late

Four endpoints answer the questions you ask before picking up the phone.

GET /v1/Statistics/UnpaidInvoices — the aged balance of what customers owe you, as totals per age bucket
GET /v1/Statistics/UnpaidExpenses — the same for what you owe suppliers. Subtract one from the other for a net position.
GET /v1/Statistics/TopOverdueCustomers — customers with overdue payments, ranked by amount. take returns 1 to 20, 5 by default.
GET /v1/Statistics/PaymentDelay — how long payments actually take over a period, from the document date and from the due date, plus the share of the amount paid late. side is Customers (the default) or Suppliers.

An aged-balance bucket is keyed by period: negative is overdue, 0 is due today, positive is upcoming. The steps are 1, 7, 15, 30, 60 and 90 days, so -7 means more than 90 days late.

TopOverdueCustomers returns the age of each customer’s oldest unpaid payment and lastReminderOn, the date of the last reminder sent to them. null means they were never chased, which is not the same as chased and still not paying.

For PaymentDelay, read medianDaysToPayment and medianDaysLate rather than the averages. A handful of very late payers can drag the mean to a month while the typical invoice is paid on time.

Products, with both prices

A product now stores its sale price both excluding and including tax, and returns both, along with the margin figures derived from them:

taxExcludedPrice and taxIncludedPrice
margin — the tax-excluded price less the purchase price, per unit
markupRate — the margin as a percentage of the purchase price (FR « taux de marge »)
marginRate — the margin as a percentage of the sale price (FR « taux de marque »)

margin, markupRate and marginRate are computed on every save. A value you send for them is ignored.

Two fields are deprecated as a result:

Deprecated	Use instead
`unitPrice`	`taxExcludedPrice`
`isUnitPriceTaxIncluded`	`taxIncludedPrice`, to send a tax-included price

⚠️ Behaviour change on read: unitPrice is now always the tax-excluded price, and isUnitPriceTaxIncluded is always false. unitPrice used to hold whichever price the product was entered in, so for a product priced tax-included it now returns a different number. If your code read the flag before using the price, the result is the same. If it assumed the price included tax, read taxIncludedPrice instead.

Writing works as before. unitPrice on its own is read as tax-excluded, and isUnitPriceTaxIncluded: true still means the price you send includes tax.

Markup is not margin

Document lines had a marginRate that divided the margin by the purchase price. That ratio is a markup rate, and products now have a real marginRate that divides by the sale price. Both could not share one name.

⚠️ Breaking change: on quote, invoice and credit lines, marginRate is renamed markupRate. The value is unchanged. Only the name is new.

E-invoicing statuses, as the platform names them

eInvoicingStatus on invoices returns the code defined by the e-invoicing platform, not an internal name:

api:uploaded, api:validated, api:sent, and so on, for the access point’s own steps
fr:200 to fr:228 and fr:501 for the French lifecycle statuses — fr:200 is Déposée, fr:212 is Encaissée, fr:213 is Rejetée
ppf:* for the public platform’s flows, and aoz:* for statuses added by Altoviz

⚠️ Breaking change: if you compared this field to names like FrSubmitted or ApiSent, switch to the codes. The full list is in the EInvoicingStatusCode schema.

One status is new: aoz:importerror marks a received invoice that could not be turned into an expense yet, because its Factur-X could not be read or its supplier could not be matched. It is retried automatically, and it is replaced by the next fr:* status the platform sends.

Settings

GET /v1/Settings returns three new values:

sales.outstandingLimit — the default maximum outstanding balance for a customer that has no limit of its own
sales.invoices.invoiceZeroQuantityLines — whether invoicing a quote brings along lines with nothing left to invoice, such as a zero quantity or a line already invoiced in full
eInvoicing.validateAddressesBeforeSubmit — whether both parties’ e-invoicing addresses are checked before an invoice is submitted

sales.marginRate is removed.