> ## Documentation Index
> Fetch the complete documentation index at: https://zenskar.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Per unit

## Concepts

### What per-unit pricing is

Per-unit pricing is a pricing model where a single rate applies to every unit, with no brackets at all. The amount is simply the quantity multiplied by the rate.

```
PER-UNIT PRICING:
  Customer uses 150 units
  Rate: $2.00/unit
  → 150 × $2.00 = $300.00
```

| Aspect             | Per unit                                   | Tiered                                     | Volume                                      |
| ------------------ | ------------------------------------------ | ------------------------------------------ | ------------------------------------------- |
| Rate determination | The same rate for every unit, always       | Each portion gets its own rate             | Total quantity picks one rate for all units |
| Brackets           | None                                       | Yes                                        | Yes                                         |
| Invoice display    | Single line item                           | Multiple line items, one per tier consumed | Single line item (one rate)                 |
| Best for           | Simple linear pricing, no volume incentive | Progressive rates, usage-based incentives  | Bulk discounts, committed volume deals      |

Because there's only one rate, there's no bracket determination, no tier boundaries, and no tier reset period to configure. Per-unit pricing is the simplest of the three models, and it's also the baseline the other two are compared against.

### How it applies to point in time and period of time products

Both product types can use per-unit pricing, but what the "unit" and the "rate" represent still differs between them, the same distinction that runs through every pricing model on this platform.

| Aspect                 | PIT per unit                             | POT per unit                            |
| ---------------------- | ---------------------------------------- | --------------------------------------- |
| Quantity nature        | Cumulative consumption, or a fixed grant | Current snapshot                        |
| Price expression       | Per unit                                 | Per unit per pricing period             |
| Bracket-related config | None                                     | None                                    |
| Change trigger         | A new usage event, or a new purchase     | An amendment (adding or removing units) |

For PIT products, per-unit pricing is the natural fit for metered usage: every event that gets recorded is billed at the same rate, and the invoice for a period is just the sum of usage in that period multiplied by the rate. There's no cross-period accumulation to think about, since there's no bracket boundary that cumulative usage could ever cross.

For POT products, per-unit pricing is expressed per unit per pricing period, for example \$20 per seat per month, and quantity is typically a snapshot that changes through amendments rather than usage events. Because the rate never changes with quantity, an amendment doesn't require any recalculation beyond simple proration: the days before the amendment are billed at the old quantity, and the days after are billed at the new quantity, each at the same unit rate.

### Proration

Proration is simpler for per-unit pricing than for tiered or volume pricing, since there's no bracket split to recompute.

| Scenario                                       | What's prorated                                          | Rate affected?          |
| ---------------------------------------------- | -------------------------------------------------------- | ----------------------- |
| POT: mid-period start or end                   | The price (by days), then × quantity                     | No, the rate stays flat |
| POT: mid-period amendment                      | The price per segment (by days), then × segment quantity | No, the rate stays flat |
| PIT: prepaid, fixed quantity, mid-period start | The quantity grant itself (by days)                      | No, the rate stays flat |
| PIT: postpaid, metered, mid-period start       | Nothing, actual usage is used                            | No, the rate stays flat |

For a PIT prepaid grant, whether the grant is prorated for a partial period or charged in full is itself configurable (partial period handling: prorate or full), with prorate as the default. Because the unit rate is fixed regardless of quantity, proration for per-unit pricing only ever scales the price or the quantity by a day-fraction. It never needs to reconsider which rate applies, the way tiered and volume pricing do.

### How it interacts with other pricing features

Per-unit pricing can be combined with other features, and the order they're applied in matters. Raw usage is first floored by any minimum quantity commitment, then reduced by any quantity discount, and only that effective quantity is multiplied by the unit rate to compute the amount. A minimum spend commitment is evaluated against that amount next, followed by any percentage or fixed discount.

Since there's only one rate, a quantity discount or minimum quantity commitment changes the amount in a straightforward, linear way. There's no bracket for the adjusted quantity to land in differently, unlike tiered and volume pricing, where an adjusted quantity can shift which rate applies. The full calculation stack is laid out step by step in the [reference](#order-of-operations-full-calculation-stack) section below.

## How-to guides

### How to set up per-unit pricing for a metered PIT product

1. Open the price editor for the product and set the pricing model to **Per Unit**, with currency set to the currency you're billing in.
2. Set **Price per unit**, for example \$2.00.
3. Leave **Usage is metered** checked, and select the usage aggregate (meter) that supplies the quantity. Quantity here comes from recorded usage events, not a fixed grant.
4. Save. A customer using 150 units in a billing period is billed 150 × $2.00 = $300.00 for that period, as a single line item. There are no tiers to configure and no tier reset period, so usage in one billing period never interacts with usage in another.

### How to set up per-unit pricing for a seat-based POT product

1. Open the price editor for the product and set the pricing model to **Per Unit**, with currency set to the currency you're billing in.
2. Set **Price per unit**, for example \$20.00, and set the **Pricing Period** the rate applies over, for example Monthly.
3. Leave **Usage is metered** unchecked if quantity is a fixed count you set directly (for example, a seat count on the contract) rather than derived from usage events.
4. Save. A customer starting the month with 30 seats is billed 30 × $20.00 = $600.00 for the month. If the customer amends the contract mid-period to add seats, the days before the amendment are billed at the old quantity and the days after at the new quantity, both at the same unit rate.

### How to change the unit rate on an existing price

A pricing preset can't be edited or removed once created, only added to. To change the rate:

1. Create a new pricing preset on the product with the updated **Price per unit**.
2. Mark the new preset as default if it should apply to new contracts going forward, or select it explicitly on the contracts that should use it.
3. Existing contracts keep referencing whichever preset they were set up with, so a rate change doesn't retroactively affect invoices already generated under the old preset.

### How to verify a per-unit calculation on an invoice

1. Open the invoice and locate the product's line item.
2. Confirm the billed quantity matches the expected usage or seat count for the period.
3. Multiply that quantity by the configured **Price per unit** and confirm it matches the line item amount, before any minimum quantity, quantity discount, minimum spend, or percentage/fixed discount is applied. If any of those features are configured, check the [order of operations](#order-of-operations-full-calculation-stack) to see where each one adjusts the amount.

## Reference

### Per-unit configuration

**Required fields**

| Field          | Description                                                       |
| -------------- | ----------------------------------------------------------------- |
| Price per unit | The unit rate charged for every unit                              |
| Currency       | Based on the currencies supported by the selected business entity |

**Optional configuration**

| Field                   | Description                                                                           | Default                   |
| ----------------------- | ------------------------------------------------------------------------------------- | ------------------------- |
| Usage is metered        | Whether quantity comes from a usage aggregate rather than a fixed input               | Unchecked                 |
| Billing offset          | Prepaid or postpaid                                                                   | System default            |
| Usage aggregate         | Links metered quantity to the price, when usage is metered                            | Default per pricing model |
| Partial period handling | For a PIT prepaid grant: prorate the grant for a partial period, or charge it in full | Prorate                   |

There are no brackets, no tier boundaries, and no tier reset period for per-unit pricing. The rate is the same regardless of how much or how little is consumed.

### Order of operations (full calculation stack)

```
1. Raw usage, quantity from aggregate or fixed input
2. Minimum quantity commitment (if configured): effective quantity = max(raw usage, minimum quantity)
3. Quantity discount (if configured): adjusted quantity = effective quantity − quantity discount
4. Per-unit calculation: amount = adjusted quantity × rate
5. Minimum spend commitment (if configured): amount = max(per-unit amount, minimum spend)
6. Percentage / fixed discount (if configured):
   fixed: amount − discount (floored at $0)
   percentage: amount × (1 − discount%)
7. Final product total, ready for invoice
```

### Scope

| Dimension          | Coverage                                             |
| ------------------ | ---------------------------------------------------- |
| Product types      | Point in time (PIT) and period of time (POT)         |
| Bracket directions | Not applicable, per-unit pricing has a single rate   |
| Quantity subtypes  | Homogeneous (fungible units); heterogeneous deferred |

### Glossary

| Term             | Definition                                                                                                                                                     |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Unit rate        | The single price applied to every unit, regardless of quantity                                                                                                 |
| Usage is metered | A toggle indicating quantity comes from a usage aggregate rather than a fixed grant                                                                            |
| Pricing period   | For a POT price, the recurring window (for example, monthly) the per-unit rate is expressed over                                                               |
| Forward split    | POT behavior where an amendment creates two segments, pre-amendment at the old quantity, post-amendment at the new quantity, each billed at the same unit rate |