Exchange is excluded from this API/CLI release. Any historical Exchange API or CLI example in this guide is unavailable; native portal behavior is outside this exclusion. See [current release scope](/developers/guides/release-scope?lang=en).

# Renewal forecast

The API and portal share a readable overview of active service periods for domain registrations, Hosting, Exchange and spam filters. The displayed price is an estimate based on the **current product catalog**. Existing payment agreements, subscriptions, invoices and actual invoice lines remain authoritative. This overview creates no order, invoice, payment or supplier request.

## Viewing your own company

Use `GET /api/v1/accounts/{account}/billing/renewal-forecast` with `billing:read`. The connection sees only the selected authorized company and its explicitly permitted resources. An invoice restriction does not grant access to a domain or mailbox forecast with the same numeric ID.

Parameters are `limit` from 1–100 (default 20), `horizon_days` from 1–366 (default 31) and the `cursor` from the previous response. The period starts on the current calendar day. Cancelled services, DNS-only zones without a registration and private or deleted Exchange mailboxes are not shown as customer products due for renewal. Spam filters use the same ownership check and count only enabled products.

```bash
binadit billing renewal-forecast list --account 123 --horizon-days 31 --output json
```

An example row:

```json
{
  "id": "renewal:domain:42",
  "source": "service_period_forecast",
  "resource_type": "domain",
  "resource_id": "42",
  "account_id": 123,
  "name": "example.test",
  "period_ends_on": "2026-11-01",
  "binding_status": "verified_company",
  "pricing_source": "current_catalog_estimate",
  "invoice_id": null,
  "payment_available": false,
  "pricing_available": true,
  "currency": "EUR",
  "estimated_price_excl": "12.50",
  "estimated_price_incl": "15.13",
  "period_months": 12,
  "estimated_next_period_ends_on": "2027-11-01",
  "catalog_products_active": true
}
```

This is an illustration, not an actual quote. A missing or invalid product price, currency or period produces `pricing_available: false`; no amount is invented. A product no longer active for new sales may still belong to an existing service; `catalog_products_active` exposes that distinction. The estimate does not change the existing contract price.

## IDs and actual payments

Treat the `renewal:…` ID as an opaque identity in a separate namespace. It is not an invoice ID, historical transaction number, payment code or new order. Never use it as an invoice payment argument. The metadata states `source: service_period_forecast` and `not_an_invoice: true`.

Actual invoices are under `billing/invoices`. An existing invoice owned by the company can be paid through the existing secure `billing/invoices/{invoice}/pay` flow. New orders and explicit product changes still require reviewed quotes and their corresponding confirmation. The historical `billing/upcoming-transactions` collection is separate legacy administration; those rows are not replaced by this forecast or mapped as invoices.

In the portal, the dashboard and **Renewal forecast** use the same new read overview. The old button pointing to an unimplemented payment page has been replaced by a link to actual invoices. The calculation performs no legacy balance processing or direct debit.

## Internal platform overview

`GET /api/v1/accounts/{account}/admin/billing/renewal-forecast` requires `admin:read`, enabled administration features and an actual internal administrator with recent passkey verification. An owner or service connection gains no platform rights through this endpoint.

```bash
binadit admin billing renewal-forecast list --account 123 --horizon-days 90 --output json
```

A missing, archived, blocked or ambiguous company binding is shown as `requires_reconciliation`, without a price or guessed new account ID. This gives support a concrete source resource to investigate; it grants no permission to create an invoice for another company. The portal administrator retains the existing browser policy; the public administrator API separately requires recent passkey verification.