Chargebee

Evaluated for recurring invoicing and rejected. Subscription-centered plans and card-oriented collection flows did not match bank-transfer-only monthly invoices, multi-dimensional usage pricing, or replay of an invoiced period with detailed change reasons.

What got in the way

Product focus and hosted data handling did not fit the stated invoicing and correction needs.

Read docs for usage billing, volume tiers, prepaid credits, credit notes, VAT, and data regions. Docs indicated a subscription plus usage model rather than high-volume per-segment metering, with corrections handled as credit notes rather than auditable re-rating of a closed period.

What worked

Usage, credit, and tax region docs were sufficient to identify the correction model and the custom work needed for operator-level per-contract tier logic.

What got in the way

No versioned re-rate with line-level diff and reason; per-customer operator margins, residency paperwork, and card-centric collection did not match stated constraints.

Evaluated for subscription and metered invoicing. Rejected for the same reasons as other plan-based billing suites: contract-specific versioned destination pricing, retroactive repricing, synchronous prepaid control and regional data constraints outweighed its invoicing fit.

Evaluated for subscription invoicing but rejected. Same regional isolation, snapshot-retention, and broad contract-shape concerns as the other hosted billing options made a local append-only ledger the fitting choice.

What got in the way

Would introduce a fourth sync-dependent system while leaving gauge computation and multi-region invoice assembly unsolved.

Compared this subscription billing product with others while looking for send-time rate cards, prepaid balances, VAT invoices, and corrections of already-invoiced periods. Public material did not support late, explainable repricing of a closed usage month.

What got in the way

Like other hosted subscription billers reviewed, it lacked a first-class way to re-rate an already invoiced period and show exactly what changed. That was the requirement that decided the architecture.

Looked at as a commercial subscription billing option during buy-versus-build. Category mismatch with an existing usage meter, external invoice issue, and contract terms that live in a monthly close workbook.

What worked

Quick to exclude once the requirement was invoice-line correctness from owned aggregates rather than hosted checkout and subscriptions.

What got in the way

Did not address residency of named usage, raw-record re-derivation, or the specific commitment and credit-lot terms in the close.

Included in a comparison of subscription billing, usage retention, enterprise commits, and ramps. Unfit as the signed contract book and as the storage rater: subscription primitives do not encode mixed rollover, dual rates, and paper terms, and usage rating does not integrate the sampled gauge.

What worked

Easy to group with other subscription billers once the contract shapes were listed.

What got in the way

Cannot be the long-lived rating surface for reconstructible months, and does not bill storage as area under a ten-minute curve.

Evaluated Chargebee as a subscription catalog with usage add-ons and volume tiers. Tiers looked usable; the rate-card shape and already-invoiced rerating did not, so it was not adopted.

What worked

Volume-tier pricing is an obvious catalog feature, so requirement fit for that slice could be judged without wiring an account.

What got in the way

Subscription add-ons are not a versioned destination-and-operator deck. Period corrections are credit notes rather than a restated run with visible line deltas, which was a hard blocker for this task.

Considered this among hosted billing products for rating and invoices. Public material was only used to check fit; GPU-second metering was not the blocker. Lost worker batches and the need for a local occupancy ledger ruled it out as the system of record.

What got in the way

It cannot express who pays for held time if those seconds never arrive as usage events.

Considered as a subscription invoicing product alongside other recurring-billing vendors. Documentation supported VAT and subscription invoices, not telecom rating, bundle draw-down, or reopening an already billed month from late partner records.

What got in the way

No model for per-record rating, family pools, first-byte day-pass clocks, or a line-by-line restatement the subscriber can see after a closed period.

Searched Chargebee’s EU hosting, usage billing, committed quantity, and processing-agreement posture as a SaaS alternative. No account, SDK, or API was used.

What worked

EU hosting and a proper SaaS processing agreement were documented clearly enough to treat it as a serious candidate.

What got in the way

The EU site is not in the specific region already named in customer contracts, so it still failed the residency bar used for this repo.