Revvly
Docs
Guide

Measure the period, then bill it.

A metered charge can only be totalled once its period has actually happened. Revvly captures that total as a usage reading, holds the invoice until the reading is settled, and gives you the surfaces to settle it. A period is never billed on a number nobody looked at.

Which components this applies to

Two independent things decide how a component measures: what happens to its quantity at the period boundary, and which number in the period gets rated. Only the first one gates an invoice.

Resets each period
Consumption that belongs to its period and dies with it — API calls, tokens, transactions. The total is only final once the period has closed, so these are the components that produce a reading and gate an invoice. They must bill in arrears: there is nothing to charge at the moment a period opens.
Carries forward
A standing level that changes only when something changes it — seats, licences, a storage high-water mark. Rebaselined at the boundary rather than zeroed, so nothing here waits on a reading and nothing here holds an invoice.

Independently of that, you choose which number is rated:

Highest observed
The peak reached during the period.
Total over the period
Everything accumulated across it.
Value at period end
The level standing at the moment the period closed.

Components authored before these two settings existed were converted from their old measurement mode automatically: Peak became a carried-forward quantity billed on its highest value, Cumulative became a per-period quantity billed on its total. Nothing changed about how they bill.

The cycle

  1. 1
    Usage accrues
    Through the period, an integration posts increments to the usage API, or nobody does and an operator will enter the figure later. Which of the two Revvly expects is the component’s capture mode.
  2. 2
    The period closes
    A daily sweep captures the accumulated total as a reading before the live counter resets, so the number that will be billed is fixed at the boundary rather than read back afterwards.
  3. 3
    A grace window runs
    For an integrated meter the reading stays open for a day after close, so events delayed by a queue or a retry still land in the period they belong to.
  4. 4
    The reading seals, or asks for you
    An hourly sweep settles what it can. A meter that reported seals on its own; one that did not is handled by the policy below, and anything left needing a decision raises a task.
  5. 5
    The invoice issues
    Once every reading it carries is sealed or waived, the held draft issues: it takes its invoice number and its dates at that moment, and enters receivables like any other invoice.

Reading states

Only Sealed and Waived release an invoice. Every other state holds it.

Path of a usage reading
  1. Period closes
    The total is captured as a reading.
  2. Accumulating
    API capture, grace window still open.
    or
    Awaiting
    Manual capture, no value entered yet.
  3. Sealed
    Quantity is final.
    or
    Waived
    Not billed, with a reason on record.
    or
    Unverified
    API sent nothing; invoice stays held.
  4. Held invoice issues
    Once every reading is sealed or waived.
Only a sealed or waived reading lets the held invoice issue; every other state keeps it held.
Accumulating
API capture. The period has closed but the grace window has not expired, so late events still count towards it. Nothing to do — it seals itself.
Awaiting
Manual capture, no value entered yet. Waiting on a person. Revvly raises a task, and the reading is reconsidered on every sweep, so a late entry resolves it without anyone reopening anything.
Unverified
API capture, and the grace window expired having received nothing at all. An integration that broke and a customer who used nothing look identical from the counter, so Revvly refuses to guess: it never bills this as zero on its own.
Sealed
The billable quantity is final. Releases the invoice. A sealed reading records where its number came from — the integration, an operator, an operator overriding a quiet integration, or the zero policy below.
Waived
You decided not to bill this period, with a reason on the record. Releases the invoice and charges nothing for it.

What silence means, per component

A period that received nothing is ambiguous, and the ambiguity is expensive in both directions: bill it as zero when an integration was broken and you lose the revenue silently; hold it for review when zero is the ordinary outcome and you generate a held invoice and a task every period, for every such client, forever. So it is a per-component decision — a fact about what is being metered, not about who is being billed.

Review (default)
Seal the period as Unverified, hold the invoice, raise a task. Right for a meter where usage is expected every period. This is what every component does unless you say otherwise.
Zero
Seal an unreported period at zero and let the invoice go. Right for overage on a plan a client rarely exceeds, or a pay-per-incident charge that is empty most months. The reading records that its zero came from the policy, not from a person or an integration — so the audit trail never claims a measurement that was not made.

Capture mode normally comes from the client: an integrated client is API, everyone else is manual. One component on one subscription can be pinned the other way, with a reason kept for audit — for the client who integrates most of their meters and reports one by hand.

Working the queue

Bulk usage entry
Every open reading across the workspace in one grid, each row showing the client, the component, the plan and the subscription. Linked from the client page and the Subscriptions tab. This is where a month of manual meters gets worked.
Finance → Awaiting
Every held draft invoice, oldest first, with the metered period, the hold reason and how long it has been waiting; anything past a week is flagged. Each row links to the invoice and to the subscription that will release it.
Tasks
One task per period that needs a person, with the client attached: a manual meter awaiting entry, or an integration that has gone quiet. They are distinct kinds, so the two problems do not end up on the same queue.
Correct
Supersede a sealed reading with a different quantity and a reason, any time before its invoice issues. The original is kept.
Waive
Settle a period you have decided not to bill, with a required reason. Releases the invoice, charges nothing.

Held drafts are not pending invoices

Whether a document has been issued and whether it has been paid are separate questions, and a held draft answers only the first. It has no invoice number, no invoice date, no due date and no payment status, which is exactly what keeps it out of receivables, out of AR aging and out of payment reminders: nothing is owed until it issues. It picks all of those up at the moment it issues, so invoice numbers stay in issue order.

Drafting and holding was chosen over declining to invoice at all. An invoice that exists and says “draft, awaiting usage” is far easier to act on than one that silently does not exist because a period never sealed. For the same reason an abandoned draft is voided rather than deleted — the record that a period was expected to bill and did not is what an audit needs.

What holds an invoice

  • A reading on it is not yet sealed or waived
  • The subscription is contracted to bill a per-period metered component that nothing is tracking usage for — the invoice is held with that component named, rather than issued without it

The second case is the one worth knowing about: an untracked component produces no line at all, so without the hold the renewal would issue the base charge alone and the metered charge would disappear from the bill in silence.

Related