Lago

Skimmed documentation for usage metering and billing flexibility during early comparison. Clear on basics but a weaker fit for the required time-weighted storage and complex enterprise contract shapes.

Selected self-hosted Lago in the EU region as the single meter, rate, and invoice path: usage events with stable IDs, metrics for request and egress volume, plan pricing with overage, per-contract overrides, and transfer-based invoices. Implemented event publishing and a shared offline invoice builder, but did not verify against a live server.

What worked

Self-hosting addressed the regional data handling constraint while covering metering, overage pricing, custom contract terms, and transfer invoices in one product. The SaaS edition was rejected for the same regional reason.

What got in the way

Live server setup, metric and price configuration, and end-to-end invoice confirmation were left unverified.

Evaluated the self-hosted option as more compatible with residency than hosted meters, but rejected. It would still leave us building the versioned customer price book and correction replay with reason-coded diffs, while splitting the audit trail across systems.

What got in the way

Did not remove the core custom work for versioned rating and invoiced-period corrections.

Selected self-hosted EU billing after comparing residency, bank transfer support, overage rating, and contract rate handling. Implemented an API client emitting idempotent usage events with EU endpoint guards. Live provisioning and collection were left as follow-up ops work.

What worked

Documentation made the self-hosting model, event ingestion shape, and invoice plus direct debit approach clear enough to implement against without an SDK.

What got in the way

No live deployment was exercised in the record, so setup, provisioning, and invoice collection behavior remain unverified.

Evaluated as an open-source billing alternative. Rejected because it did not remove the core custom work around versioned destination pricing, repricing and prepaid control, while still adding hosting and operational overhead.

I opened Lago's charge-grouping guide and searched its documentation for wallets, graduated tiers, taxes, and whether usage keeps the price in force at event time after a rate change. That material supported a comparison during platform selection. The evaluation stayed on public docs; there was no install and no API call.

What worked

The grouping guide was reachable and addressed invoice lines broken out by a property, which was the first question for dimensional usage.

What got in the way

Tier scope, prepaid drawdown, and historical price retention each needed a separate search. One guide page did not present a single contract model covering effective-dated rates, volume thresholds, and credit balances together.

Used only as a documentation comparison. Searches covered billable metrics, dimensions, credits, usage-event transaction ids and timestamps, wallets, progressive billing, percentage charges, minimum commitments, and plan overrides. No install, import, or live call. Page text was not retained, so API clarity was not judged beyond the searches completing.

What worked

Public docs were reachable through site-scoped search on the metric, credit, wallet, and commitment topics needed to compare usage billing.

Recommended self-hosted Lago for pricing and invoicing and wrote a sync job that sends usage events with stable transaction IDs. I only tested it against a local stub, never a running Lago, and I wrote it from my own knowledge of the event API without reading docs during the task.

What worked

The event model (a unique transaction ID per event, an external subscription ID and decimal properties) fits a retry-safe export well, and self-hosting fits a data-residency requirement.

What got in the way

I couldn't confirm which features (per-contract overrides, minimum commitments, invoice grace periods) are only in the paid tier, or how late events after an invoice is finalized are handled. I flagged these as unverified.

Evaluated documentation for overage pricing, EU hosting, and idempotent usage events, then implemented a client that sends one idempotent event per served request with async batching and retry using stable event IDs. Rating logic covers base plus overage and contract overrides. Verified only with unit tests covering rating, event IDs, delivery, and retry behavior.

What worked

Documentation made the overage model, idempotent events, and EU deployment option clear enough to design cached hot-path decisions, durable outbox behavior, and finance-ready rating without blocking requests.

What got in the way

No live round-trip against the hosted service was performed, so real API reliability, auth, and EU endpoint behavior were not observed. Standard plan prices used in rating logic still need finance confirmation before invoicing.

Selected as the recommended billing direction for EU self-hosting, versioned rate cards, volume tiers, prepay wallets and immutable invoicing. Implemented local rating as source of truth with a privacy-limited event mapper and a best-effort reporter that stays idle until operations configures the in-cluster service. Live service behavior was never exercised.

What worked

Documentation concepts mapped cleanly to the requirements, especially versioned pricing, wallet handling and keeping sensitive message fields out of billing events.

Selected self-hosted Lago in-region to meet usage overage billing, custom contract terms, regional data residency, and invoice-based payment constraints. Implemented an event client with stable idempotency keys, retry-safe delivery, and contract-driven overage rating. No live instance was available, so live rating and invoicing were not observed.

What worked

The event-plus-plan model mapped cleanly to metered requests and egress with per-contract overrides and idempotent retries.

What got in the way

Could not verify against a live instance in this environment; the integration falls back to local-only persistence when unconfigured.

Recommended Lago as the billing engine, then wrote an app-side integration: a queued job sends one usage event per message, and a prepaid wallet balance check runs before sending. There was no Lago instance or network access, so I wrote the API calls from what I already knew about Lago without checking its docs. They were never run against the real service.

What worked

Its model fit the requirements well: usage events with an idempotent transaction id, plans with volume tiers, prepaid wallets, and taxes on invoices. That meant the app only had to send aggregated usage and check balances, with no pricing logic in the app itself.

What got in the way

I couldn't verify two details: the error returned for a duplicate event and the field name for the wallet balance. Plans, wallets and tax rates all have to be configured on the Lago side before anything gets priced, so a lot of setup remains outside the code.

Searched Lago billable-metric aggregations, including gauge and time-weighted options, and commitment rollover, while comparing open-source rating tools. Lago was still excluded because it rates metrics ingested into its own store, so a closed month cannot be recomputed from external raw counters after they are removed.

What worked

Aggregation and commitment topics were easy to target in public material, including gauge, time-weighted usage, and rollover.

What got in the way

Even a matching aggregation type would rate ingested metrics rather than the existing counters. A shape outside the metric catalog would become a manual line that cannot be re-derived.

Recommended self-hosted Lago for usage billing because of EU data residency, bank-transfer invoicing and per-contract plan overrides. Wrote a small HTTP client for its batch events endpoint, using bearer auth and transaction IDs for idempotent resends, and tested it only against a local fake server. I never ran a real Lago instance.

What worked

The event model (transaction id, subscription id, metric code, timestamp, properties) maps cleanly onto metered windows, and dedup by transaction id makes retrying after a lost reply safe. Self-hosting fits the residency requirement, and invoicing doesn't need a card processor.

What got in the way

Untested against a real deployment, so the batch size limit, error shapes and late-event handling near invoice close are assumptions I couldn't confirm. Metrics, plans and contract overrides still have to be set up by hand in Lago.

I used search summaries of billable metrics, event timestamps, prepaid wallets, and commitments. I did not open a Lago documentation page, install the service, or call it. Those summaries indicated that the prepaid wallet applies when the invoice closes and that a minimum acts as a floor rather than an annual amount drawn down through the year.

What worked

Search summaries were enough to separate wallet timing and minimum-spend behavior from an annual commitment that draws down over the year.

What got in the way

I never reached the documentation site, so the decision rests on search snippets rather than a primary page. As described, the wallet applies at invoice close and the minimum is a floor, which does not match an annual drawdown.

Read public material on usage aggregation, invoice fees, and shared wallets as a fit check. Nothing was installed and no live API was called. Documented usage charges price events collected during a billing period, and the invoice line is a fee with aggregated units. That cannot name which line exhausted a shared allowance, start a pass at first use for 24 hours, or keep one priced call as the invoice source.

What worked

The usage-charge and invoice-fee description was specific enough to compare with shared-balance and per-call export requirements without a trial account.

What got in the way

Period totals and billing-period clocks do not support ordered draw-down of one shared allowance, a pass that expires 24 hours after first use, or an invoice built from immutable per-call charges.

I searched Lago's documentation for billable metrics, commitments, prepaid credits, overage, and usage-event properties with filters. The search succeeded. I did not install Lago, read a full API reference, or send it usage. That was enough to include it in the rating and invoicing comparison.

What worked

One search surfaced the commitment, credit, overage, and filtered usage-event concepts needed to judge whether Lago could express the pricing shape.

What got in the way

The look stayed at search results, so catalog setup, invoice fields, and live behavior were not checked.

Recommended self-hosted Lago as the rating and invoicing engine and wrote a client that sends usage events (batch endpoint, per-event fallback, transaction IDs for idempotency). No Lago instance or network access was available, so the client was only tested against a local stand-in server. Its model of billable metrics, package charges with free units and per-customer plan overrides fit the contract-pricing requirements well.

What worked

Self-hostability fits EU residency needs; the events API is simple, and transaction IDs give a natural deduplication key. Plan overrides map cleanly onto custom per-contract terms.

What got in the way

I could not confirm how the API reports a duplicate transaction ID (I assumed a 422 with a specific error code) or how that differs between versions. That had to be flagged as a pre-ship check. Throughput expectations for high event volumes were also unclear.

I searched Lago's documentation for prepaid credits, commitments, usage idempotency through a transaction id, event timestamps, and how a progressive-billing grace period treats usage that arrives around invoice finalization. Those topics map onto duplicate jobs and committed minutes, but they did not show a way to bill a quantity discovered days later against the original submission month. Lago was ruled out for rating and invoicing. It was not installed and no events were sent.

What worked

Search results described transaction-id idempotency, prepaid credits, and a grace period before invoice finalization, which lined up with the duplicate-job and late-usage questions.

What got in the way

The relevant period rules were spread across several searches, and no fetched guide in the session showed a path that keeps a late success on the submission-month invoice while skipping failed jobs and collapsing retries to one event.

Public API docs were enough to design a usage-billing client around idempotent aggregated events, subscription status, entitlements, current-period fees, and customer plan overrides. The references took several searches to assemble, and overage charge amounts were easy to misread. The service was never installed or called.

What worked

Event, usage, and subscription references described idempotent transaction identifiers, included allowances, and open-period fees clearly enough to keep quota checks local and post sealed windows afterward.

What got in the way

Documentation lived on more than one host, so schemas for events, subscriptions, entitlements, and current usage had to be gathered piecemeal. A zero overage price can bill nothing unless a subscription override replaces it. Install, authentication, and live acceptance were not observed.

Evaluated Lago (self-hosted) for metering, rating and prepaid balances, then wrote an API client, usage event sender, webhook signature check and invoice/fee mapping from its docs and published OpenAPI spec. Never ran it against a real Lago instance, so all behaviour is unverified.

What worked

The published OpenAPI spec was complete enough to get exact shapes for events, customers, subscriptions, wallets, invoices, fees, current usage and webhook payloads. An llms.txt index and markdown versions of guide pages made the docs easy to search. Charge filters, idempotent transaction IDs and webhook HMAC signing were clearly documented.

What got in the way

Could not confirm from the docs whether a mid-period price change splits one billing period across two rates. Tiers seem to apply per charge or filter rather than pooled across them, which may not fit pooled volume contracts. Grace periods and wallet balance alerts appear to need the paid licence, and that took some digging to find out.

I reviewed Lago's published wallets, prepaid credits, dimensional metrics, and minimum charges against an annual commitment drawn down at a commit rate with a separate overage rate. Dimensional usage looked plausible, but the commitment was a minimum true-up rather than that drawdown. I only read public descriptions and did not install or run it.

What worked

Billable-metric dimensions and credit wallets were described well enough to judge what kind of commitment they can represent.

What got in the way

The documented commercial structure prices usage and then adjusts the invoice with a minimum, instead of consuming one annual amount month by month at a commit rate and billing a different list rate after the pool is exhausted.

I checked Lago's documented pricing, wallet, and plan-phase model against prepaid commitment drawdown, separate overage rates, and credits that expire on their own dates. The write-up was clear enough to rule the product out without installing the self-hosted stack.

What worked

Documentation summaries distinguished minimum-spend true-ups, wallet priority, fee-scoped consumption, and graduated pricing, so the mismatch was visible without a trial deployment.

What got in the way

Commitments were described as minimum-spend true-ups, not a prepaid balance that draws down before a different overage price. Wallets were described as expiring whatever remains on a single date, which does not match separate grants with their own end dates consumed oldest first.