> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.lucanto.eu/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.lucanto.eu/_mcp/server.

# Changelog

Notable changes to the Lucanto API — new endpoints, fields, and breaking
changes. Filter entries by tag and subscribe via [RSS](./changelog.rss).

## October 16, 2026

## Added: payment QR format on documents

Invoices, proformas, credit notes and quotes accept `payment_qr_format`
(`auto`, `pay_by_square`, `spayd`, `epc`, `none`). `auto` picks the format the
customer's banking app reads: PAY by square for Slovakia, QR Platba for
Czechia, EPC QR for other EEA countries. Omit it to inherit the workspace
default; send `null` to go back to it. A document reads it back as
`settings.payment_qr_format`: its own choice, `null` while it follows the
workspace default, and for a document issued before the setting existed.

A single document (get, create, update and the lifecycle actions) also returns
`settings.payment_qr_resolved` (`PaymentQrResolved`): the QR that will actually
print as `format` (`pay_by_square`, `spayd`, `epc` or `null`) and the `reason`
for it. List items leave it out. The MCP document tools take and return the
same fields.

## Added: proforma on-payment settings

`PATCH` document settings accepts `on_payment_preset` (`tax_document`,
`regular_invoice_paid`, `nothing`, or `null`) and `on_payment_autonomy`
(`confirm`, `auto`, or `null`) in the new `proforma` section
(`DocumentSettingsProforma`). The preset is what a new proforma issues when the
customer pays it. Send `null` to go back to the default.

`auto_on_payment` on a proforma now accepts `null`, which means `nothing`;
omitting it applies the workspace's `on_payment_preset`.

## Added: French and the `cs` language code

`fr` is accepted and returned as a user language (`language` on `/user`) and as
a document language (`pdf_language`, `default_pdf_language`).

The Czech code is now `cs`. `cz` is still accepted on input as a deprecated
alias, but it is never returned: responses carry `cs`.

## Added: bank account archiving and `currency_editable`

`PATCH` bank account accepts `archived`: `true` archives, `false` restores
(restoring takes a plan slot; at the cap it returns `429` with
`code: feature_limit_exceeded`). The default account cannot be archived (`422`).
A `null` is ignored.

`BankAccount` returns `currency_editable`. It is `false` for an account synced
from a bank that reported its currency; a different `currency` is then refused
with `422`. It is `true` for a manual account, and for a synced account whose
bank sent no currency.

## Changed: `default` on bank accounts

`default: true` makes the account the default and demotes the current one.
`false` or `null` on the current default leaves it the default; to change the
default, promote another account. An archived account cannot become the
default (`422`).

## Added: CSV bank statements and informational entries

`BankStatement.file_type` can now be `csv`. `BankStatementEntry.status` has a
new value, `informational`: a zero-amount line the statement prints for
information (such as a fee summary). It is never imported; correcting its
amount to a non-zero value turns it back into `pending`.

## Added: statement-imported transactions can be corrected

`Transaction` returns `statement_imported` (the row came from an uploaded
statement, so a misread can be corrected; rows the bank delivered are locked)
and `correctable`. `GET /workspaces/{workspace_id}/transactions/{id}` also
returns `corrections`, the correction history oldest first, with `reason`,
`origin` (`web`, `api`, `mcp`), `occurred_at` and `field_changes`.

## Added: bank charges when pairing a payment

`POST /workspaces/{workspace_id}/transactions/{id}/pair` accepts `charges`:
bank charges deducted from a payment before it arrived, in the record's own
currency. Only for money received for an invoice or proforma. The record is
settled at the gross (`document_amount`, or what arrived plus `charges`) and
the transaction keeps its booked amount. `charges` must be greater than zero
and smaller than the gross.

On a bank-converted row, a `document_amount` above the bank's original amount
requires `charges`; without it the pairing is refused with `charges_required`.
In one currency, a `document_amount` sent with `charges` must equal `amount`
plus `charges`. The other refusals are `422` responses with the reason in
`message`.

## Added: tax forecast conversion fields

`TaxForecast` returns `unconvertible_invoice_count` and
`unconvertible_expense_count`: documents of the year with no exchange rate to
the workspace currency. They are left out of the totals rather than summed in
a foreign currency. Each `TaxForecastScenario` returns `available` and
`unavailable_reason` (`vat_payer` or `null`), and `recommended_method` is never
`flat_rate` while `scenarios.flat_rate.available` is false.

## Changed: VAT threshold watch

`GET /workspaces/{workspace_id}/tax/vat_threshold` accepts `as_of` (an ISO date
at or before today; defaults to today). `VatThresholdWatch` adds `as_of`,
`country`, `rule_id`, `status` (`supported`, `needs_review`, `not_applicable`),
`period` and `period_key`, `reasons`, `turnover_complete`, the threshold
comparators, `primary_crossing` and `secondary_crossing`
(`VatThresholdCrossing`), `effective_payer_on` and `effective_payer_basis`, and
`obligations` and `obligation_candidates` (`VatThresholdObligation`). `needs_review`
and `complete` stay as compatibility fields for `reasons` and
`turnover_complete`.

## Added: MCP bank statements, matching and sync history

New tools for bank statements, transaction matching, transaction correction and
bank sync history (see the table on the MCP page for scopes):
`lucanto_list_bank_statements`, `lucanto_get_bank_statement`,
`lucanto_list_bank_statement_entries`, `lucanto_import_bank_statement`,
`lucanto_update_bank_statement_entry`, `lucanto_import_bank_statement_entries`,
`lucanto_skip_bank_statement_entries`, `lucanto_unskip_bank_statement_entries`,
`lucanto_preview_bank_statement_csv`, `lucanto_import_bank_statement_csv`,
`lucanto_suggest_transaction_matches`, `lucanto_match_transaction`,
`lucanto_unmatch_transaction`, `lucanto_correct_transaction`,
`lucanto_get_bank_sync_history` and `lucanto_request_bank_history_backfill`.

`lucanto_match_transaction` accepts `charges`. Matching across currencies, or
with `charges`, returns a summary with a `confirmation_token` first; confirm
with it. The result reports `outcome.bank_charges` apart from the exchange
difference. The summary may carry `suggested_charges`, an estimate of the
shortfall to the full amount that is never applied unless you pass it.

## Added: VAT deduction method on expenses over MCP

`lucanto_create_expense` and `lucanto_update_expense` accept the VAT deduction
method, as the REST API does. Deduction fields are accepted only when the
workspace is a standard VAT payer.

## September 26, 2026

## Changed: invoice PDFs are ISDOC.PDF where ISDOC applies

`GET /workspaces/{workspace_id}/invoices/{id}/pdf` now returns an ISDOC.PDF
for an issued invoice in a Slovak or Czech workspace: a PDF/A-3 that looks
and prints like before, with the ISDOC XML embedded so accounting software
such as POHODA, KROS or Money can import it. The response is still
`application/pdf`; the filename ends in `.isdoc.pdf`.

Drafts, cancelled invoices, other workspace countries, and any invoice
whose ISDOC cannot be built get the plain PDF, named `.pdf`, as before.
`?variant=plain` forces the plain PDF, and `plain` is the only accepted
value. The `ETag` now differs per variant, so a cached plain PDF is not
served as the default. The MCP `lucanto_get_invoice_pdf_url` tool names
the file the same way.

## September 25, 2026

## Added: German (`de`) as a user and document language

`language` on `GET /user` and `PATCH /user` now accepts and returns `de`.
Unlike `uk`, German is also a document language: `pdf_language` on invoices,
credit notes, proformas and quotes, the `locale` on the send-e-mail bodies,
and the document-settings defaults accept `de`, so PDFs and customer e-mails
can be rendered in German.

## Added: manual reminders for proformas

`POST /workspaces/{workspace_id}/proformas/{id}/send_reminder` sends a
payment reminder for an issued, unpaid proforma, like the invoice endpoint.
It needs the `manage:proformas` scope and the same plan and trial gates as
`send`.

## Changed: reminders are queued and limited to one per document per UTC day

`POST …/invoices/{id}/send_reminder` and the new proforma endpoint no longer
send the e-mail during the request. A `200` means the reminder was accepted
and queued; `reminder_count` and `last_reminded_at` are updated once it is
actually sent, so the document in the response does not show them
incremented yet. The limit is one reminder per document per UTC calendar
day, replacing the rolling 24-hour window; a second call the same day
returns `429` with `retry_after_seconds` counting down to UTC midnight.

## Changed: `mark_paid` defaults `paid_on` to the workspace's day

When `paid_on` is omitted on `POST …/invoices/{id}/mark_paid` or `POST
…/proformas/{id}/mark_paid`, the payment is dated today in the workspace's
`time_zone` rather than the server's UTC date. A payment recorded shortly
after midnight local time now lands on the correct day.

## Added: fifty MCP tools across documents, expenses, banking and projects

The MCP server now covers quotes, proformas and credit notes (list, get,
create, update), sales orders (list, get), expenses (list, get, create,
update), projects (list, get, create, update), contacts (get, update),
document settings (get, update), and read-only bank accounts, transactions
and loans. Each tool needs the matching resource scope; lifecycle actions
for types other than invoices stay on the REST API. The full catalogue is on
the [MCP server](/mcp) page.

## Added: `read:loans` scope

Tokens can carry `read:loans`, used by the MCP loan tools. Loans are
read-only: `write:loans` and `manage:loans` are accepted but grant only
read access.

## Added: Claude.ai sign-in to the MCP server with OAuth 2.1

Claude.ai (web, mobile and Cowork) connects to
`https://app.lucanto.eu/api/mcp/v1` by signing the user in rather than
using a pasted token. The user approves the requested access on a consent
screen, capped by their workspace role, and the connection appears under
**Settings** > **Personal API access**, where it can be revoked. OAuth access
tokens work only on the MCP endpoint, not on the REST API; personal access
tokens keep working on both.

## September 17, 2026

## Added: Ukrainian (`uk`) as a user language

`language` on `GET /user` and `PATCH /user` now accepts and returns `uk`
alongside `sk`, `cz`, `en` and `ro`. It sets the language of the app and of
the e-mails Lucanto sends to that user.

Document languages are unchanged: `pdf_language` on invoices, credit notes,
proformas and quotes, and `locale` on the send-e-mail bodies and the MCP
`lucanto_send_invoice` tool, still take `sk`, `cz`, `en` or `ro`. A user whose
language is `uk` receives PDFs and customer e-mails in the document's own
language; a document without one falls back to the workspace's country
language, never to the user's UI language.

## September 7, 2026

## Breaking: create/update bodies for invoices, credit notes, proformas and quotes reject unknown fields

`InvoiceWritable`, `CreditNoteWritable`, `ProformaWritable`, `QuoteWritable`,
their `LineItemInput` shapes, and the `*SendRequest` bodies (including the
nested `invoice_email` / `credit_note_email` / etc. objects) now declare
`additionalProperties: false`. A request carrying a key outside the
documented schema is rejected with `422` instead of being silently ignored.
The legacy `{ "document": { ... } }` wrapper and the Rails-style indexed
`line_items` object (`{"0": {...}}`) are still accepted by the server for
backward compatibility, but neither is part of the documented schema — send
a flat top-level body with `line_items` as an array. File uploads
(`attachments`) travel as multipart form fields, outside this JSON body.

## Breaking: line-item removal uses a boolean `_destroy`

`_destroy` on `InvoiceLineItemInput`, `CreditNoteLineItemInput`,
`ProformaLineItemInput`, and `QuoteLineItemInput` is now `type: boolean`.
The previous `"true"`/`"false"` string enum is no longer part of the
documented schema — send `true` to remove a line item on update.

## Breaking: `mark_paid.amount` is a decimal string with documented over/under-payment semantics

`amount` on `POST …/invoices/{id}/mark_paid` and `POST
…/proformas/{id}/mark_paid` must match `^\d+(\.\d{1,2})?$` — no thousands
separators, no comma decimal separator. Omitting it, or sending an explicit
`null`, settles the whole outstanding balance and `payment_status` derives
to `paid`. A smaller amount records a partial payment: `payment_status`
becomes `partially_paid` and `amount_due` drops by that amount, so you can
call the endpoint again for the next instalment. An amount above the
outstanding balance is accepted and recorded in full, and `payment_status`
then derives to `overpaid`.

## Breaking: MCP `lucanto_send_invoice` follows the plan and trial gates

Sending an invoice by email over the MCP server is now gated the same way
as the web app and the REST API. On a plan without email sending the tool
returns a subscription error with `reason: "feature_not_available"`; a
trial workspace can send one document email per day and gets
`reason: "trial_send_cap"` once that is used up. The daily counter is
shared across all three surfaces, and a request that fails validation does
not consume it.

## Added: read-only sales orders API

`GET /workspaces/{workspace_id}/sales_orders` and `GET
…/sales_orders/{id}` return a customer's orders to you, tracked until fully
invoiced. Both need the `read:sales_orders` scope; the resource is
read-only, so the token scope picker offers it at the read level only. Reference the id as `sales_order_id` on an invoice or proforma to
record which order it fulfils. A sales order carries no payment
instructions: `payment_status`, `amount_paid`, and `amount_due` are always
`null`, and `overdue`/`paid_late` are always `null` too. `status` moves
through `draft` → `confirmed` (number minted) → `fulfilled` (system
transition once every ordered line is invoiced, reversible if the invoiced
total drops), plus `rejected`, `reopened`, and `canceled`.

## Added: delivery date, texts and item descriptions over MCP

`lucanto_create_invoice` and `lucanto_update_invoice` now accept
`delivery_date`, `opening_text`, `closing_text`, and a per-item
`description`, matching the REST create and update bodies. Invoices imported
through an MCP client no longer lose these fields on the way in.

## Fixed: issuing without a number series, email language, and `mark_paid` errors

* `POST …/invoices/{id}/issue` and the MCP `lucanto_issue_invoice` tool now
  answer `422` with "No number series is set up for this document type.
  Supply a document number or create a number series." instead of a generic
  transition error when the workspace has no series for that document type.
* Document emails sent over the API and MCP are rendered in the document's
  language; they no longer fall back to English. An explicit `locale` on the
  send request still overrides it, and `locale: null` keeps the default.
* `mark_paid`'s `422` now names an invalid `amount` (not a decimal string
  with at most two decimals) as a documented failure cause, alongside no
  outstanding balance, a `bank_account_id` outside the workspace, and a
  transaction that fails validation.

## August 30, 2026

## Statutory exchange-rate anchors, and ČNB rates for Czech workspaces

Automatically fetched `exchange_rate` values on foreign-currency documents
and expenses now follow the statutory anchor: the case day is the delivery
date (falling back to the issue date), valued for Slovak workspaces at the
ECB reference rate declared the preceding day, and for Czech workspaces at
the ČNB rate for the case day itself. Czech workspaces can also elect the
D−1 ČNB rate or a fixed rate list (pevný kurz) per workspace, and the
settings screen generates the matching internal directive text.

* Consumers reading `exchange_rate` on newly created records see
  day-correct statutory values; user-entered rates are never overwritten.
* A one-time correction re-anchored the stored `exchange_rate` on five
  historical expenses whose value provably came from the old fetch — each
  carries a full before/after audit trail in its metadata. No settled,
  manually entered, or document rates were touched, and payment statuses
  were provably unaffected.

## Breaking: document `status` is now lifecycle-only; payment state moves to `payment_status`

The single `status` enum on invoices, proformas, credit notes, and quotes
no longer mixes lifecycle and payment. `status` now carries only the
document's lifecycle, with a per-type value set:

* invoices, credit notes: `draft`, `issued`, `sent`, `canceled`
* proformas: adds `settled` and `expired`
* quotes: `draft`, `issued`, `sent`, `accepted`, `rejected`, `expired`, `canceled`

The removed values — `exposed`, `in_due`, `active`, `paid`, `unpaid`,
`partially_paid`, `paid_above_price`, `paid_after_due_date` — are replaced
by new read-only fields:

```json
{
  "status": "sent",
  "payment_status": "partially_paid",
  "overdue": true,
  "paid_late": false,
  "status_transitions": {
    "issued_at": "2026-08-12T09:14:00Z",
    "sent_at": "2026-08-12T09:20:00Z",
    "locked_at": "2026-08-14T07:02:00Z",
    "transmitted_at": null,
    "canceled_at": null
  }
}
```

`payment_status` (`unpaid`, `partially_paid`, `paid`, `overpaid`; `null`
for non-payable documents) is derived from actual payments, using the same
rounding tolerance as the rest of the app. `overdue` is derived from
`due_date` and the outstanding balance — there is no stored overdue status
to poll or update. Update any code that reads or filters on the old
combined values.

## Breaking: `status` is no longer writable — use action endpoints

Create and update bodies no longer accept a `status` field. Documents are
moved through their lifecycle with the action endpoints — `POST
…/invoices/{id}/issue`, `POST …/credit_notes/{id}/issue`, `POST
…/quotes/{id}/accept` — and payment is recorded, not declared: `POST
…/invoices/{id}/mark_paid` creates a real payment record for the
outstanding balance, and `payment_status` derives from it.

```diff
- PATCH /workspaces/42/invoices/1   { "status": "paid" }
+ POST  /workspaces/42/invoices/1/mark_paid
```

Two behavior changes ride along:

* Drafts are unnumbered — `number` is `null` until the document is issued,
  when it is minted from the workspace's number series. Draft numbers no
  longer consume a slot in the series.
* A document locks after its first accounting effect (a payment, or
  transmission), visible as `status_transitions.locked_at`. Content edits
  on a locked document are rejected; correct it with a credit note.

## August 28, 2026

## Settle documents across currencies

`POST /workspaces/{workspace_id}/transactions/{id}/pair` now accepts
`document_amount` — the settled amount in the paired record's own currency —
so a transaction can settle a document or expense held in a different
currency (a EUR card charge paying a USD invoice). The allocation stores both
legs: the bank amount in the transaction's currency and the settled amount in
the document's, and payment status derives from the settled side. Decimal
input is locale-tolerant (`72,90` and `72.90` both parse).

* Omitting `document_amount` keeps the existing same-currency behaviour
  unchanged.
* The realized exchange rate is derived from the two amounts; on settled
  records the summary shows the resulting exchange difference with its
  563/663 account for double-entry workspaces.
* Suggestions never auto-pair across currencies: cross-currency candidates
  appear in `GET .../transactions/{id}/suggestions` (and the document-side
  mirror) with `currency_conversion` among their `match_reasons`, for
  explicit review.

## August 16, 2026

## Review, import, and retry bank statement extraction

Bank statement rows staged by AI extraction are now reviewable through the API.
List a statement's staged rows with
`GET /workspaces/{workspace_id}/bank_statements/{id}/entries`, add one the
extraction missed with `POST .../entries`, and book the reviewed set as
transactions with `POST .../entries/import` — omit `entry_ids` to book
everything `pending`, or pass `force: true` to push past a statement that
doesn't balance.

* `POST .../bank_statements/{id}/retry_extraction` re-parses a PDF with a
  stronger model when rows were dropped.
* `DELETE /workspaces/{workspace_id}/bank_statements/{id}` removes a duplicate
  upload without touching transactions already booked from it.
* All of these require the `manage:bank_accounts` scope.

## Merge duplicate bank accounts

`POST /workspaces/{workspace_id}/bank_accounts/{id}/merge_into` folds a
duplicate-IBAN account into the one the bank actually writes to. Every
transaction, statement, and document referencing the source is repointed at
the target and the source is archived; nothing is deleted. The source can't
carry a bank connection, and the workspace's default account can't be merged
away.

## Pair and unpair bank transactions

Transactions can now be settled, unsettled, and deleted through the API.

* `POST /workspaces/{workspace_id}/transactions/{id}/pair` links a transaction
  to the document or expense it pays for.
* `POST .../transactions/{id}/pair_with_transaction` links a refund to the
  charge it reverses.
* `POST .../transactions/{id}/unpair` undoes either.
* `DELETE /workspaces/{workspace_id}/transactions/{id}` hard-deletes a
  transaction and re-derives the payment status of whatever it settled.
* `GET .../transactions/{id}/suggestions` returns the same scored candidates
  as the app's "Suggested matches"; `GET .../invoices/{id}/transaction_suggestions`
  (also on proformas and credit notes) returns the mirror — transactions
  likely to settle that document.

Transaction responses also gained `display_name`, a ready-to-render
counterparty label, and `pairable`, which names what the transaction
currently settles.

## August 1, 2026

## Upload and inspect bank statements

You can now list, retrieve, and upload bank statements under
`/workspaces/{workspace_id}/bank_statements`. Uploads accept one camt.053 XML or PDF
file up to 10 MB: XML imports synchronously and deduplicates known transactions,
while PDFs can run asynchronous AI extraction and expose a pollable extraction
status.

## July 29, 2026

## Control transaction notifications per bank account

Workspace owners can now list and update the new-transaction push switch for each
eligible connected bank account. The resource keeps this per-account switch separate
from the user's global `new_transaction` notification category; a push is sent only
when both settings are enabled.

## July 28, 2026

## Refuse suspended workspace memberships

REST, mobile JWT, and MCP access now exclude suspended workspace memberships.
Requests resolve the workspace as not found, matching the behavior for a
membership that was removed and avoiding disclosure of the suspended seat.

## July 27, 2026

## Identify imported documents

Invoice, proforma, quote, and credit-note responses now include `import_source`.
It records whether a document originated in KROS, ISDOC, SuperFaktura, or another
supported import path; `null` means the document was created in Lucanto.

## July 25, 2026

## Limit employees to their own records

The built-in employee role now lists and retrieves only the documents and
expenses that member created, across REST and MCP. Employees can still create
and manage their own documents; API-created documents are attributed to the
calling user so they remain visible. Inaccessible record IDs return not found
rather than revealing another member's data.

## July 21, 2026

## Inspect workspace roles and effective permissions

Workspace responses now include the caller's built-in `user_role` and resolved
`permissions`. Permission values use `<area>:<level>` keys such as
`documents:manage`, so clients can gate actions using the same effective access
rules as Lucanto, including custom roles.

## July 20, 2026

## Breaking: bank account prefix renamed

The Czech-style account prefix field is now named `account_number_prefix` on bank
account requests, responses, and embedded bank-account objects. The former
`prefix_number` field is removed; update both serializers and write payloads.

## July 14, 2026

## Look up Slovak and Czech companies

You can now search the authenticated business-registry endpoint by IČO or company
name with `GET /registry/lookup`. Results are normalized across the Slovak and Czech
registries, and an unavailable upstream registry returns `502` so clients can fall
back to manual entry.

## Forecast tax obligations and the VAT threshold

Two read-only workspace endpoints now expose a tax and levy forecast and progress
toward mandatory VAT registration. The forecast applies to Slovak self-employed
workspaces; unsupported entity types return `applicable: false` instead of an
inapplicable estimate.

## Send invoice payment reminders

You can now send a dunning email for an issued, unpaid invoice with
`POST /workspaces/{workspace_id}/invoices/{id}/send_reminder`. The returned invoice
includes `reminder_count` and `last_reminded_at`; the operation requires the
`manage:invoices` scope and applies the same feature and anti-spam gates as invoice
sending.

## Register mobile push devices

JWT-authenticated mobile clients can now register or refresh an APNs token with
`POST /devices` and unregister it with `DELETE /devices/{id}`. API keys are denied
because push registration belongs to a signed-in user session.

## July 13, 2026

## Update the current user's profile

You can now update `name`, `language`, and `locale` with `PATCH /user`.
Every field is optional, and `name` accepts `null` when it should be cleared.
Email, password, and avatar changes remain on their dedicated account flows.

## July 12, 2026

## Read bank transactions

You can now list and retrieve workspace bank transactions through
`GET /workspaces/{workspace_id}/transactions` and
`GET /workspaces/{workspace_id}/transactions/{id}`. The list is cursor-paginated
and supports account, date, matching-status, `kind=credit|debit`, and full-text filters.
Transactions remain read-only; writes continue to come from bank sync and Lucanto's
matching flows.

## July 8, 2026

Workspace document defaults now live under one endpoint that spans every document
type, and quote responses no longer carry payment instructions.

## Document defaults: one endpoint for every type

Workspace-level document defaults are now managed through a single endpoint,
replacing the invoice-only `invoice_settings`:

* `GET /workspaces/{workspace_id}/document_settings`
* `PATCH /workspaces/{workspace_id}/document_settings`

The body is grouped by section — `shared`, `invoice`, `quote`, and `proforma` —
so one call reads or updates the defaults for a given type. Beyond the payment-QR
toggle, it now covers the default payment method, delivery method, due days,
footer note, PDF language, quote validity, and whether to show the signature. A
per-document value still wins over the workspace default, which wins over the
built-in behavior.

The former `invoice_settings` endpoint is removed; its `show_payment_qr` setting
now lives at `document_settings["invoice"]`.

## Quotes no longer return payment instructions

A quote is a price offer, not a payment request, so a quote response no longer
includes the `payment` block — payment method, bank account,
variable/specific/constant symbols, and the pay-by-square QR. Invoices,
proformas, and credit notes are unchanged.

## July 4, 2026

Richer payment and delivery details on documents, plus workspace-level
invoice defaults. All additive — existing integrations are unaffected.

## New: payment variant and means code on documents

Invoices, proformas, credit notes, and quotes now return a fuller payment
block. Alongside `payment_method`, each document carries:

* `payment_type` — the variant within a method (`sepa` under `bank_transfer`,
  `credit_card` under `card`, and so on). Free-form text for the `other`
  method.
* `means_code` — the EN 16931 **BT-81** payment means code (UNCL4461),
  derived from the method for UBL and ISDOC export (`30` credit transfer,
  `10` in cash, `48` card, `58` SEPA direct debit).

`payment_type` is accepted on create and validated against the method it
belongs to.

```json
{
  "payment_method": "bank_transfer",
  "payment_type": "sepa",
  "means_code": "58"
}
```

## New: delivery method on documents

Documents now carry `delivery_method` — a free-form carrier or delivery mode
such as `courier` or `pickup_point` — accepted on create and returned in
responses, independent of the payment fields.

## New: hide the payment QR, per document or per workspace

Each document returns a `settings` object with `show_payment_qr`, which
controls whether the PDF renders a pay-by-square QR code. Set it on create
for a single document, or set a workspace default with the new endpoint:

* `GET /workspaces/{workspace_id}/invoice_settings`
* `PATCH /workspaces/{workspace_id}/invoice_settings`

A per-document value wins over the workspace default, which wins over the
built-in behavior (QR shown for bank-transfer invoices).

## MCP: create_invoice accepts the new fields

The `create_invoice` MCP tool now accepts all the fields introduced above.
Invalid enum values — an unknown `payment_method`, say — now return a clear,
self-correctable tool error instead of a generic failure.

_Showing the 20 most recent of 28 entries. Append `/llms.txt` to the changelog URL for the complete index._