Changelog

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 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.

{
  "id": "mprp_5RmXe2QbtKfYuA9DcNH3P",
  "comparator": "IN",
  "meter_property_variable_id": "mpva_2PnBx7VdtRgLmE4WcQJ8K"
}

Create a variable with POST /v1/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, which takes an add set and a remove set and applies both as one change:

{
  "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 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 stays readable with long lists. A condition expands 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 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 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

• Overriding one pricing on a schedule no longer asks you to resend the discounts, commitments and markups you did not touch. PATCH /v1/pricing-plan-schedules/{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 <pricing> but override for <pricing> 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 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.

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

• An invoice number prefix that references a custom field 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 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 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 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 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

• 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 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 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 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 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

• 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.