Skip to content
P

Plans, entitlements & billing

How plan tiers map to entitlements, how usage is metered, and where limits are enforced.

Every organisation is on a plan tier, and the tier is what governs how much of the platform the organisation can use. This page explains the model; the generated Plans & limits reference lists the current tiers and their entitlements.

Tiers and entitlements

There are several tiers, from a free tier up to enterprise. A tier resolves to a set of entitlements — named limits and feature flags such as the API rate limit, usage caps, and access to particular capabilities. Most entitlements come from a shared set of defaults; a tier overrides the ones that differ (for example, the per-minute API rate limit is pinned per tier). This keeps the model consistent: adding a new limit means adding it to the defaults, and only the tiers that deviate carry an override.

Metering

Usage-based entitlements are metered. As requests flow through the API, a metering step records usage against per-organisation counters; a rollup worker aggregates them. Metering is best-effort and fully guarded — a metering failure never fails the underlying request. This gives billing an accurate, auditable view of usage without putting the billing path in the critical path of every API call.

Where limits are enforced

  • Rate limits are enforced by a Redis sliding-window limiter, per plan, on the API. Exceeding a limit returns a rate-limit error with the standard headers — see the Rate limits guide.
  • Feature entitlements are checked where the feature is used.
  • Usage caps are enforced against the metered counters.

Choosing and changing a plan

Signing up creates the organisation on the Free tier. Paid tiers are bought from Settings → Billing, which opens the payment provider's hosted checkout — card or SEPA Direct Debit.

Once you have a subscription, the provider's customer portal is where it is managed: upgrade, downgrade, cancel, and payment-method changes all happen there. PIE deliberately does not reimplement those: the portal already handles proration, and keeping card details out of our system is a feature rather than a limitation.

An organisation admin sees their own plan, usage and invoices. A platform admin can still set a tier or a per-tenant entitlement override directly — that is how bespoke arrangements and grandfathered limits are expressed.

What a payment is worth

Prices are published net of VAT. Where VAT applies it is added at checkout; EU businesses that supply a valid VAT identification number are reverse-charged, and the invoice says so. Annual billing is charged at ten months' price.

A subscription is not treated as paid until the provider confirms the payment. This matters for SEPA Direct Debit, which settles in days rather than instantly and stays reversible by the payer for several weeks.

Cancelling

Cancelling moves the organisation to Free; it does not suspend or delete anything. Published products, passports and portals keep working. What changes is that the paid capability gates close and you cannot create beyond the Free ceilings — so a cancellation is a downgrade rather than a shutdown.

Approaching a limit

Enforcement is a two-step ladder rather than a cliff:

  • Warn. As usage approaches a ceiling, responses carry an X-Entitlement-Warning header naming the entitlement, and the app shows a dismissible banner linking to billing.
  • Block. At the ceiling, the operation is refused with a clear error identifying the limit, and an audit record is written. The first block in a billing period also sends a notification, which cannot be turned off — it arrives at the moment work has been refused.

Reads are never blocked, so you can always see your plan and usage.

Your invoices

Every invoice we issue is stored in PIE, under our own control, and served to you from that copy — not by linking you out to the payment provider.

That is a deliberate difference and it matters for one reason: German law (§ 147 AO, § 257 HGB) requires invoices to be retained for ten years, and that obligation is ours, not the provider's. A provider link is a document held by somebody else, on their terms, for as long as they choose. If the account were closed, suspended in a dispute, or migrated to a different provider, those links would stop resolving while the obligation remained.

What this means for you in practice:

  • Invoices stay available in Settings → Billing for the full retention period, independent of any payment provider.
  • Links are short-lived and personal. Opening an invoice generates a link valid for a few minutes. It is not a permanent URL, so do not bookmark or share it — open the invoice again instead. Each access is recorded.
  • Occasionally you will see a provider link. An invoice is archived moments after it is issued; if you open one in that window, the provider's copy is offered so you are never left without a document. This is temporary and we are alerted when it is not.
  • Erasure requests do not remove invoices. If you ask us to erase your personal data, we anonymise the billing contact on the record and keep the invoice itself, because the law requires us to. Your data-access response tells you exactly which documents are held on that basis and when the retention period ends. They are used only for billing and audit.

Invoices issued outside self-serve checkout — Enterprise agreements, for instance — are held in the same archive under the same terms.

Related