Billing & Metering

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:

1. Customer launches an instance. Event: instance.start.
2. Instance runs for some time. Per-second or per-minute heartbeats confirm it's still allocated.
3. Customer terminates or instance fails. Event: instance.stop with reason.
4. 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.

Takeaway

Billing is the most-consequential data pipeline in any neocloud. Every other piece of data infrastructure ultimately feeds into or supports it. Get the data model, idempotency, and lineage right from day one or pay for it indefinitely. The next chapter looks at the customer-usage and capacity-planning data that runs alongside billing.