Section C · DE inside a neocloud · Critical chapter

Billing & Metering

The pipeline that determines who pays whom. Per-second metering, rating against contracts, invoice generation, dispute resolution. Get this wrong and the company loses revenue or angers customers — often both.

Why this is the most-critical pipeline

Billing has unique constraints:

Auditable. Every line on every invoice has to trace back to specific telemetry events.
Idempotent. Re-running the pipeline produces the same invoices — no double-billing.
Append-only. Once billed, the underlying records can't change.
Reconcilable. External payment systems and ledgers must match the pipeline's output.
Fast enough. Customers expect invoices monthly at minimum; many want daily / on-demand.

Billing is the pipeline where DE skills (data modeling, idempotency, lineage) meet finance discipline (auditability, controls). The DE function gets accounting and compliance partners for free as soon as they touch billing.

Metering

Metering converts raw fleet telemetry into billable units. For GPU rental:

Customer launches an instance. Event: instance.start.
Instance runs for some time. Per-second or per-minute heartbeats confirm it's still allocated.
Customer terminates or instance fails. Event: instance.stop with reason.
Metering pipeline computes total runtime, applies GPU SKU pricing, produces a usage record.

Subtleties that make this hard:

Heartbeat gaps — instance went down briefly, came back, is that billable?
Provider failure — instance died because of host failure; usually not billable.
Time zones and date boundaries — usage spanning a month boundary needs to split correctly.
Reserved vs on-demand — same instance might draw from a reservation OR overflow into on-demand.

Rating

Rating applies pricing rules to usage records. The complexity scales with contract structure:

Public list price. Simple: usage × list rate.
Volume tiers. Lower per-unit price above usage thresholds.
Reserved commitments. Customer prepaid for N GPU-hours; usage draws against the prepaid balance until exhausted, then on-demand pricing applies.
Custom pricing. Big customers have bespoke rates; rating engine has to know which contract applies.
Credits and promotions. Free credits, partner pricing, win-back offers all modify the rating.
Multi-currency. If billing supports multiple currencies, exchange rate handling is part of rating.

The rating engine is a contract-aware pricing service. The DE team builds the data model that supports it.

Invoicing

Invoicing aggregates rated usage into customer invoices. Components:

Period selection (typically monthly; daily for some customers).
Line item generation (one per SKU, region, or customer-specified breakdown).
Tax calculation (if applicable; can be a separate service).
PDF / HTML generation.
Payment processor handoff.
Customer-portal availability.

Invoicing typically integrates with a billing platform (Stripe, Maxio, custom). The DE team feeds the platform; the platform handles payment.

Disputes & corrections

Customers will dispute charges. The pipeline has to support:

Drill-down. Trace any invoice line back to the underlying instance starts/stops.
Credit memos. Issue refunds without violating the append-only constraint on the original invoice.
Adjustments. Apply corrections (e.g., refund for an instance that failed due to host issue).
Re-billing. If a systemic issue is found, regenerate corrected invoices.

The DE team designs the data model so corrections are first-class — never mutate billed history, always append correction records.

Audit and reconciliation

Auditors and finance teams need to reconcile billing data with other systems:

Sum of invoices = revenue recognized in the ledger.
Reserved-capacity drawdowns reconcile with the contracts table.
Tax calculations match jurisdictional rules.
Customer disputes and resolutions are tracked.

The DE team builds reconciliation reports that finance / audit can self-serve. When discrepancies arise, the lineage from invoice line to telemetry event lets investigation reach the root cause.

Per-second / per-token / per-job variants

Different neocloud business models meter different units:

Per-second GPU rental (RunPod, Lambda, CoreWeave on-demand, others). Meter: GPU-seconds × rate.
Per-token inference (Together, Hyperbolic inference, RunPod Serverless). Meter: input tokens + output tokens × per-token rate.
Per-job (some serverless flavors). Meter: jobs × per-job rate plus per-second compute.
Reserved capacity (enterprise neoclouds). Meter: contract-defined periodic fee plus overflow billing.
Marketplace transactions (Vast, TensorDock). Meter: marketplace fee on each transaction; provider receives net.

The metering schema and rating engine differ for each. Many neoclouds support multiple variants simultaneously.

✓ Check yourself

Answer from memory before opening each one.

An instance's heartbeat drops for four minutes after a host fault, then resumes. How do you decide what is billable?

Show answer
Decide by written policy, and encode it in the metering step. A gap caused by provider failure is usually not billable. Record the reason on the usage record so the line can be explained in a dispute. See metering.
A bug fix changes the totals when you rerun March's pipeline, and March invoices already went out. Which constraint did the design violate, and how do you correct?

Show answer
Billed history must be append-only and the pipeline idempotent. Never rewrite sent invoices. Append correction records, issue credit memos, and regenerate corrected invoices as new records if the issue is systemic. See disputes and corrections.
An instance runs from 23:00 UTC on 31 January to 02:00 UTC on 1 February. How should metering record it?

Show answer
Split it at the boundary into two usage records, one in each billing period, using a defined time zone. A single record would put all three hours in one month. See metering.
A customer prepaid 10,000 GPU-hours and uses 12,000 in the month. How does rating treat the usage?

Show answer
The first 10,000 draw down the prepaid balance, and the remaining 2,000 are rated at on-demand or contract overflow rates. Rating must know which contract applies and track the balance. See rating.
Finance reports invoices of $1.20 million but the ledger recognizes $1.17 million. How should the pipeline help you find the gap?

Show answer
Lineage from each invoice line to the telemetry events behind it, plus a reconciliation report. Diff by customer and period, then trace the differing lines. The design goal is that a discrepancy reaches a root cause. See audit and reconciliation.
A neocloud adds per-token inference billing beside per-second GPU rental. What changes in the metering schema?

Show answer
The unit and the event source: records come per request with input and output tokens rather than from start, stop and heartbeats, and the rate card differs. Keep one rating and invoicing path that handles each variant. See metering variants.

Takeaway

Billing must be auditable, idempotent, append-only and reconcilable, and these constraints shape the whole data model.
Metering turns lifecycle events into usage records, and rules for gaps, provider failures and period boundaries are written down and encoded.
Rating applies list prices, tiers, prepaid draw-down, custom contracts, credits and currencies, and so needs a contract-aware data model.
Corrections are new records; billed history is never mutated.
Every invoice line must trace to specific telemetry events, so reconciliation with the ledger is a query.
Different business models meter different units, and many neoclouds run several at once.

Billing is transactional, and the same data also drives internal decisions about capacity. → Customer Usage & Capacity Data