POST /v1/invoices/import never read the monetary totals your document states.
total_amount and amount_due were written as null, and no later update
filled them in, so an imported invoice kept both nulls for its whole life.
You could see it on GET /v1/invoices/{id}, where totalAmount came back
null for every document you had imported.
It also has a consequence on the French settlement path, where settlement is derived by comparing recorded payments against the amount due. With no amount due, that comparison cannot conclude, so a fully paid invoice could not be projected as settled.
Two amounts, read separately
Both values now come from your document: TaxInclusiveAmount (BT-112) for the
total, PayableAmount (BT-115) for the amount due.
They are read separately, with no fallback from one to the other. An invoice carrying a prepaid amount states two genuinely different figures, and borrowing the total to stand in for the amount due would understate what is owed — which would project an invoice as settled before it is.
Amounts are converted to minor units using the currency's real exponent, so JPY and BHD are recorded at the right magnitude rather than assumed to have two decimals.
When an amount cannot be trusted, the column stays null
Four cases leave the column null rather than record a figure we would have to
guess: the amount is absent, unreadable, negative, or stated in a currency that
contradicts the document currency. Each carries its own reason in our internal
signal, so an alert says which one happened instead of inferring it.
A figure too large for the column is also recorded as null rather than
refused. That is a deliberate divergence from POST /v1/invoices, where the
amount is computed from a payload you can still change and a 422 is
actionable. On import you hand us a legal document the network accepts, and
refusing it because our column is 32 bits wide would be stricter than Peppol
itself.
Documents imported before this change keep their nulls. There is no backfill.