> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.solvimon.com/changelog/2026/9/30/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.solvimon.com/_mcp/server. ## Summary Meter property variables give you a named, reusable list of values that a pricing condition matches with `IN` or `NOT_IN`, so a list of hundreds of values lives in one place instead of inside every condition that needs it. An invoice-level discount now reaches one-off lines, and it is spent once per invoice rather than once per billing period. You can now attach JSON, HTML, Markdown, PPTX and POTX files to a quote template. A product, a product item, a pricing plan and a quote template now carry guidance for AI agents. A reverted wallet grant now says why it was reverted. Domestic UK self-billing invoices carry the HMRC wording. ## Pricing **A reusable list of values for a pricing condition** A [meter property](/platform-guides/meter-and-event-design/meter/meter-properties) condition can now point at a meter property variable: a named, reusable list of values bound to one meter property. The condition references it with `meter_property_variable_id` and a comparator of `IN` or `NOT_IN`, instead of repeating the values inline. A country list, a SKU range or a set of merchant ids is therefore defined once, and every pricing item config that matches on it follows the same list. **`A condition that matches a variable`** ```json A condition that matches a variable { "id": "mprp_5RmXe2QbtKfYuA9DcNH3P", "comparator": "IN", "meter_property_variable_id": "mpva_2PnBx7VdtRgLmE4WcQJ8K" } ``` Create a variable with [POST /v1/meter-property-variables](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/post-meter-property-variables), with `meter_property_id` or `meter_property_reference` and its initial `values`. A variable holds up to 10,000 values. Afterwards you edit the list through [PATCH /v1/meter-property-variables/\{id}/values](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/patch-meter-property-variables-by-resource-id-or-reference-values), which takes an `add` set and a `remove` set and applies both as one change: **`Add two values and remove one`** ```json Add two values and remove one { "add": ["FR", "BE"], "remove": ["LU"] } ``` The response reports what happened per value: `added`, `removed` and `skipped`. A value you already hold is skipped rather than duplicated, and a value you do not hold is skipped on removal, so the same request can be sent twice without a different outcome. [GET /v1/meter-property-variables/\{id}/values](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/get-meter-property-variables-by-resource-id-or-reference-values) reads the list, paged, and each value carries the `added_at` of when it entered the list. The variable itself reports `value_count` rather than inlining the values, so [GET /v1/meter-property-variables](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/get-meter-property-variables) stays readable with long lists. A condition [expands](/platform-guides/for-developers/expanding-responses) `meter_property_variable_id` into `meter_property_variable`. Changing the list changes what future events match. Events that were already priced are not reprocessed. Solvimon refuses to delete a variable that a condition still references. **A quantity for a one-off item bought through the portal** A [one-off](/platform-guides/products-and-pricing/pricing-plans/one-off-pricing) item priced `FLAT` bills a unit price times a count. The portal-facing schedule customization now carries `units`, the same per-config quantity the desk-facing schedule already took. A customer buying through the [hosted checkout](/platform-guides/customers-and-billing/hosted-checkout) can therefore order three of something, and the invoice preview shows what three will cost before they confirm. Each entry names a `pricing_item_config_id` and a `number`. A config you leave out falls back to its `default_units`, and then to 1. ### Fixes bug-fix * Overriding one pricing on a [schedule](/platform-guides/customers-and-billing/subscriptions/schedule-configurations) no longer asks you to resend the discounts, commitments and markups you did not touch. [PATCH /v1/pricing-plan-schedules/\{id}](https://docs.solvimon.com/api-docs/configuration-api/pricing-plan-schedules/patch-pricing-plan-schedules-by-resource-id) validated the clauses against the request body instead of against the state of the schedule, so an override on its own failed with `discount applies to but override for is updated or removed`. The validation now reads the schedule. * A subscription on a rate card pricing plan now expands `pricing_plan_version_id`. The expansion returned nothing for this plan type. ## Invoices **An invoice-level discount reaches one-off lines, and is spent once** A one-off line added with [POST /v1/invoices/\{id}/lines](https://docs.solvimon.com/api-docs/transaction-api/invoices/post-invoices-by-resource-id-lines) now opts in to the invoice-level discounts of the subscriptions on that invoice. Set `applicable_for_clauses` to `["discount.totals"]` and the line counts towards the discount, and is discounted by it. Leave it out and the line stays outside them, as before. The field is only for a one-off line added to a regular invoice: a one-off invoice has no subscription clauses to apply. An invoice-level discount of a fixed amount is now also spent once per invoice. An invoice that holds a period billed in advance and a period billed afterwards used to apply the full amount to each of them, so a 50 EUR discount came off twice. **Domestic UK self-billing invoices carry the HMRC wording** Under HMRC self-billing rules, a domestic UK self-billed VAT invoice has to state whose output tax the VAT is. Solvimon now adds the tax note `SELF_BILLING_UK_DOMESTIC`, "The VAT shown is your output tax due to HMRC", to an invoice that is self-billing with both parties in the United Kingdom. Other self-billing invoices and other countries are unchanged. See [Tax](/platform-guides/invoicing/tax). **A future invoice can take its date from finalisation** When a subscription starts in the future and its first invoice is finalised in advance, the invoice date used to be the start date of the subscription even with `WHEN_INVOICE_GOES_TO_FINAL` set. The invoice date now follows the setting, so it is the date the invoice was actually finalised. Your numbering and your reporting periods therefore line up with when the document was issued. ### Fixes bug-fix * An invoice number prefix that references a [custom field](/platform-guides/platform-configuration/custom-fields) is now validated when you configure it. The prefix supports `{{customer.custom_fields[reference]}}` and `{{billing_entity.custom_fields[reference]}}`, and these were resolved for the first time at finalisation. Solvimon now checks the reference when the configuration is saved, and guards a custom field that a prefix depends on against being renamed or removed. * Self-billing invoice number settings now fall back correctly when no configuration exists yet. `self_billing_invoice_number_configuration` and `self_billing_credit_invoice_number_configuration` now return the default when not set. * The invoice PDF now shows the invoice number in its title rather than the resource id, carries the tax details block below the price details, and uses larger body and heading sizes. Bold text no longer breaks mid-word. ## Wallets and credits **A reverted grant says why it was reverted** A [wallet grant](/platform-guides/wallets-credits/credits-in-pricing-plans) issued by a charge is reverted when that charge disappears, for example when a schedule is shortened so its period is no longer billed. The grant now carries `reverted_at` and `revert_reason`, and can no longer be spent. The reason is one of `INVOICE_VOIDED`, `SCHEDULE_DATES_CHANGED`, `SCHEDULE_DELETED`, `SUBSCRIPTION_CANCELLED`, `SUBSCRIPTION_UPGRADED`, `SUBSCRIPTION_VOIDED`, `SUBSCRIPTION_CANCEL_UNDONE` or `WALLET_GRANT_REVERTED`. You can therefore tell a balance that fell because a customer spent it from one that fell because the charge behind it was removed. Before this, a grant whose charge was gone stayed funded and spendable. Grants reverted before this release have neither field set. ## Quotes **More file types on a quote template** A [quote template](/platform-guides/customers-and-billing/quoting/quote-templates) attachment, and a quote that inherits it, now accepts JSON, HTML, Markdown, PPTX and POTX in addition to PDF. Sales can therefore send a deck or a structured appendix through the quote portal, not only a PDF. [POST /v1/documents](https://docs.solvimon.com/api-docs/configuration-api/documents/post-documents) takes the matching `content_type`: `application/json`, `text/html`, `text/markdown`, `application/vnd.openxmlformats-officedocument.presentationml.presentation` and `...presentationml.template`. `text/plain` is accepted only when the document name ends in `.md` or `.markdown`, because editors commonly send that type for Markdown. Solvimon validates the content against the type it claims, and rejects a macro-enabled PowerPoint file. The limit is 10 MB, and 25 MB for PPTX and POTX. **A name on a quote** A [quote](https://docs.solvimon.com/api-docs/configuration-api/quotes/post-quotes) now takes a `name`, as a subscription already did. A sales team working on several quotes for one customer can label them, instead of telling them apart by resource id. ## AI and MCP **Guidance for AI agents on a catalog resource** A product, a product item, a pricing plan and a quote template now carry an `agent_context` object with a `guidance` field, up to 2,500 characters. It is free text written for an AI agent rather than for a customer: when to pick this plan, what the item actually covers, which deal shapes it suits. Solvimon's MCP server hands this to agents alongside the catalog metadata, so an agent choosing a template or a plan reads your intent instead of guessing from names. Desk has an input for it on each of these resources. ## Event ingestion ### Fixes bug-fix * Deleting an event now returns `deleted: true`. `POST /v1/ingest/meter-data/{id}/delete` performed the delete but answered with the event as it was read before the update, so the response said `false` while the next `GET` said `true`. ## Desk **A wallet that holds money reads as money** Desk now shows a `CREDIT` [wallet type](/platform-guides/wallets-credits/credit-types-wallets) funded with an amount as a currency balance everywhere a wallet appears: the balance, the top-up, and the deduction on the invoice line. An invoice line can be paid by more than one wallet, so each line lists what every wallet contributed. Before this, Desk assumed credits throughout, and a money wallet was shown as a quantity of credits. **Manage the lifecycle of an approval policy** An [approval policy](/platform-guides/customers-and-billing/quoting/approval-policy) can now be created as a draft and released when it is ready, and deprecated or archived when it is not needed. The actions sit in the same context menu as the other catalog resources, and use [POST /v1/approval-policies/\{id}/activate](https://docs.solvimon.com/api-docs/configuration-api/approval-policy/post-approval-policies-by-resource-id-activate) and its deprecate and archive counterparts. A policy that approves live traffic is therefore no longer edited in place. **Refresh the custom fields on a final invoice** The refresh menu on a `FINAL` invoice now offers "Refresh custom fields", next to customer information, PO number and payment acceptors. A [custom field](/platform-guides/platform-configuration/custom-fields) with `copy_value_to_invoice` that changed after the invoice was issued can therefore be pulled onto it from Desk. **A quantity for a one-off flat item** The subscription and quote screens now have a quantity input on a one-off item priced `FLAT`, so you set how many are being bought when you add the item. ### Fixes bug-fix * The audit log now shows the name of the user who made a change, instead of the raw user id. * The event filter now selects a meter by its reference, which is what ingestion uses, instead of by name. * The events screen keeps its table and its detail panel apart, and the filter no longer shows two clear buttons.