# How billing works

> The objects and flow behind recurring revenue on VINR.

Billing composes a handful of objects — customers, products, prices, subscriptions, and invoices — into recurring revenue. Once you understand how they fit together and how money moves, every capability (trials, proration, usage, dunning, tax) is a variation on the same flow.

## Core objects

| Object         | What it answers                                                           |
| -------------- | ------------------------------------------------------------------------- |
| `customer`     | *Who* is being billed (shared with [Payments](/docs/payments/customers)). |
| `product`      | *What* you sell.                                                          |
| `price`        | *How much* and *how often* — e.g. €20 / month.                            |
| `subscription` | The ongoing *relationship* that generates invoices.                       |
| `invoice`      | A *statement* for one billing period that Billing collects.               |

```typescript
// A product can have many prices (monthly, yearly, regional).
const product = await vinr.products.create({ name: 'Pro plan' });

const price = await vinr.prices.create({
  product: product.id,            // "prod_..."
  amount: 2000,                   // €20.00
  currency: 'EUR',
  recurring: { interval: 'month' },
});                               // "price_..."
```

## From price to invoice to payment

A subscription is the engine. On each cycle it does the same four things:

### Generate a draft invoice

At the start of the period, the subscription creates a draft `invoice` with line items from its prices (and any [usage](/docs/billing/usage-based-billing) or one-off [invoice items](/docs/api-reference/invoice-items)).

### Finalize

VINR applies [discounts](/docs/billing/coupons-and-discounts) and [tax](/docs/billing/tax), then finalizes — locking the invoice and computing the amount due.

### Collect

The finalized invoice becomes a [payment](/docs/payments/how-payments-work) against the customer's default method. This is where Billing hands off to Payments.

### React

VINR emits `invoice.paid` (or `invoice.payment_failed`, which triggers [dunning](/docs/billing/dunning-and-recovery)). You fulfil access on the event.

## Billing cycles & anchors

The **billing cycle anchor** is the moment each period begins. By default it's the subscription's creation time, so a subscription created on the 15th bills on the 15th. You can align cycles (e.g. everyone bills on the 1st) by setting an explicit anchor — VINR [prorates](/docs/billing/trials-and-proration) the first partial period.

> Changing quantity or price mid-cycle creates **proration** line items on the next invoice — credit for unused time and a charge for the new rate. See [Trials & proration](/docs/billing/trials-and-proration).

## Where Payments fits

Billing decides *what* and *when*; Payments executes the collection. That separation means everything you configured in Payments — stored methods, [SCA](/docs/payments/strong-customer-authentication), retries, multicurrency — applies automatically to recurring charges. Failed collections flow into dunning rather than silently lapsing.

## Where to go next

[Products & prices](/docs/billing/products-and-prices) — Model your catalog and pricing.

[Subscriptions](/docs/billing/subscriptions) — The full subscription lifecycle.

[Create a subscription](/docs/guides/create-a-subscription) — A runnable end-to-end guide.