List invoices

Page size, 1–100. Default 25.

Opaque pagination cursor from a previous response's pagination.next_cursor.

Sort direction. Ordering is ALWAYS by when the record was CREATED in Finero, never by when it changed — updated_since narrows the set but does not reorder it, so the most recently updated row is not necessarily first. Creation time is immutable, which is what lets the cursor stay stable: ordering by a value that changes would move a row mid-walk and make a page skip or repeat it. Default desc (newest first by creation time).

Return pagination.total_count — the number of rows matching the filters, ignoring paging. It is the SAME number on every page, including alongside a cursor. Off by default: an exact count scans the whole filtered set, so asking on each page pays repeatedly for an answer that does not change — ask on the first request and keep it.

Return only invoices with this collection status — Finero's own payment record, so paid means FINERO collected it and an invoice settled elsewhere is inactive. Combines with every other filter, and with include_total.

Filter by ISO 4217 currency code.

Exact-match filter on the ERP invoice number.

Filter by ERP connection.

Only invoices updated at or after this ISO 8601 timestamp. updated_at moves when the invoice's own data changes (an ERP delivery, a retirement, an edit), NOT when only Finero's collection state does (collection_status, collection_outstanding, amount_collected, erp_push_state, has_active_payment_link): poll GET /v1/payments?confirmed_since= for collections. The bound INCLUDES its own timestamp, so polling with the newest updated_at you have seen returns that row again every time - expected, and not a change.

Only invoices for this customer, by the stable customer.id on the invoice. This is the ONLY safe way to total one customer's exposure — grouping by name merges two customers who share one, and grouping by email splits a customer across its billing addresses.

Only invoices whose payment write-back to the ERP is in this state. failed is the one to watch: money Finero collected is not represented in the ERP, so its own balance overstates what is owed — and without this filter a stuck invoice is invisible unless you already know its number.

Only invoices with (true) or without (false) an active Finero payment link. Combine false with collection_status=open and due_before for the overdue-and-unlinked worklist in one call.

Only invoices whose collection_due_date is on or before this date (YYYY-MM-DD), INCLUSIVE. The overdue worklist is due_before=<today> with collection_status=open. FILTERS ON collection_due_date, so an invoice that has none is excluded — and one has none precisely when nothing on it is collectible, which is also when it can still owe money. Date bands therefore never sum to the whole book: check a total against a call with no date filter, never against the bands. amount_collected under ANY date filter is PARTIAL and never a collected total: a fully paid invoice has no collection_due_date so its collections drop out, while a partly collected OPEN invoice keeps its own and stays in. Ask with no date filter for what was collected.

Only invoices whose collection_due_date is on or after this date (YYYY-MM-DD), INCLUSIVE. Combine with due_before for one aging bucket — but because BOTH ends include their own date, adjacent bands must not share a boundary: use due_before=X then due_after=<X plus one day>, or every invoice dated exactly X is counted twice and the profile sums to more than the book. Every collection_due_date exclusion and the partial-amount_collected caveat described on due_before applies here identically.