How should usage be metered if it becomes an invoice?

As immutable events with an idempotency key, aggregated into period totals that are stored rather than recomputed. The moment usage becomes money, the event log stops being telemetry and becomes an accounting record - which means events are never edited, a duplicate submission is rejected by a unique constraint rather than by a check, and the total for a closed period is frozen so that a late-arriving event lands in the next period instead of silently changing an invoice somebody already paid.

Our invoice totals do not match our own dashboard.

They are almost always reading different things - the dashboard recomputes from events now, the invoice was generated from a total as it stood at the time. Both are defensible individually and the discrepancy is not. The arrangement that works is one stored total per customer per period, frozen when the period closes, which the invoice, the dashboard and the finance export all read. There should be exactly one number, and it should be a row.

A customer cancelled at Stripe and our application still thinks they are active.

Because the application treated the webhook as reliable and had no way to notice it was missed. Webhooks are delivered best effort - they arrive late, twice, or not at all - so they cannot be the only source of subscription state. What works is handling each webhook idempotently as a state change and running a periodic reconciliation that compares the application's view with the provider's and reports differences. The reconciliation is what turns a missed webhook from an unbilled customer into a line in a report.

Our trial logic has edge cases nobody can reason about.

Usually because trial state is inferred from dates scattered across several columns. A trial is a period with a start, an end and an outcome, and asking whether a customer is in one should be a single question with a single answer. The cases that break naive logic are the ordinary ones - a trial extended by support, a customer who paid early, a customer who cancelled during the trial and came back - and each is easy against an explicit record and impossible against three nullable timestamps.

Laravel in Austin

Laravel development for Austin SaaS and usage-based products

A Laravel development company for Austin SaaS businesses. Metering that has to agree with an invoice, a trial that ends on a date, and a subscription whose state lives at a payment provider.

Updated November 4, 2026

Austin's software companies bill for what customers used, which turns an event log into an accounting record and changes what the backend is allowed to do with it.

In a flat-rate business, usage data is telemetry - approximately right is fine, a lost event is a rounding error, and nobody audits it. The moment usage becomes an invoice, every one of those assumptions becomes a liability. A duplicated event is an overcharge, a lost event is revenue that never existed, and a recomputed total that disagrees with a sent invoice is a support ticket from somebody's finance department.

Austin metering events are accounting records

Which means they get treated like accounting records rather than like logs.

Each event is immutable once written. Each carries an idempotency key from the system that generated it, enforced by a unique constraint so that a retried submission is rejected by the database rather than by a check somebody might later remove. Nothing edits an event; a correction is a new event that offsets it, exactly as a ledger works.

The aggregation follows the same logic. The total for a billing period is computed when the period closes and then stored, not recomputed on demand. Otherwise an event arriving three days late silently changes an invoice that has already been paid, and the business discovers it when the figures stop reconciling two months later.

The arithmetic discipline is the usual one - integer units, rounding applied once at a defined point. Money and dates are the decisions you cannot undo is the background, and usage billing is where both halves arrive together.

One number, and it is a row

The most common complaint on these systems is that the dashboard and the invoice disagree, and the cause is that they are different calculations.

The dashboard recomputes from events as they stand now. The invoice was generated from the total as it stood when the period closed. Each is internally consistent, and the difference between them is impossible to explain to a customer.

So there is one stored total per customer per period, frozen at close, and the dashboard, the invoice, the revenue report and the finance export all read it. If somebody wants to know what today's usage looks like mid-period, that is a different and clearly labelled figure - an estimate, not a total.

Laravel and Stripe both believe they own an Austin subscription

Austin SaaS businesses almost all run subscriptions through a payment provider, which creates a second source of truth whether anybody intended it or not.

The application holds a view of whether a customer is active. The provider holds its own. They are synchronised by webhooks, and webhooks are delivered best effort - they arrive late, they arrive twice, and sometimes they do not arrive at all. A system that treats them as reliable will eventually serve a cancelled customer for free or lock out one who paid.

Two things fix it. Each webhook is handled as an idempotent state change, so a duplicate is harmless and the order of arrival does not matter. And a scheduled reconciliation compares the two views and reports differences, which is what converts a missed webhook from a silent fault into a line in a report somebody reads. Payment webhooks in Laravel covers the handling; the reconciliation is the part most implementations skip.

An Austin plan change mid-period changes what the meter means

Tiered pricing and mid-period plan changes do not compose by accident.

A graduated price says the first ten thousand units cost one rate and the next ninety thousand cost less. That calculation needs a period to run over. Change the plan on the eleventh and the period has split in two, and the question of whether the customer's tier progress carries across the boundary is a commercial decision rather than a technical one. Reset it and a customer who upgraded is punished for upgrading. Carry it and the arithmetic has to track tier consumption against a plan that no longer applies.

Either answer is defensible; what is not defensible is the answer emerging from whichever way the code happened to loop. So the billing period becomes its own record with the plan and the tier basis attached, a plan change closes one and opens the next, and the rule about carrying progress is written down in one place where somebody in finance can read it.

Commitments complicate it further and are common in this market. A customer commits to a volume for a year, draws down against it monthly, and overage prices differently from the committed portion. That is a balance with a term, drawn down by metered usage, and it has to be visible to the customer mid-period - because the question they ask is not what the invoice will be, it is how much of the commitment is left.

Laravel quotas on an Austin API, enforced in the request path

Billing data and quota enforcement are the same numbers read at two different speeds, and conflating them breaks one or the other.

Enforcement happens in a request that has to return in milliseconds, so it reads a counter rather than aggregating events. Billing happens once a period and has to be exactly right, so it aggregates the events and never trusts the counter. Keeping both, and keeping the event log as the authority, means a lost increment costs a slightly generous rate limit rather than a wrong invoice.

The boundary is where the races live. Two requests arrive simultaneously with one unit of quota remaining, and both read the counter before either writes. An atomic increment that returns the new value, with the decision made on that returned value, closes it; a read followed by a write does not. The same applies to a period rollover, where requests either side of midnight must land in the right bucket, in the customer's zone rather than the server's.

Soft limits are worth more than hard ones here. A customer who hits the ceiling mid-integration and gets a wall of errors with no explanation churns. A grace allowance, a response header that says how much is left, and a notification sent before the limit is reached turn the same enforcement into something a developer on the other side can work with - and the data for all three is already being collected for the invoice.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - state privacy laws, sales tax on software, invoicing - is on the United States market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption and no US entity on our side.