The engineering bottleneck with assembled stacks
Finance partners reconstruct usage from three systems at month-end: the product’s own logs, the payment provider’s counters, and a spreadsheet that reconciles them with hope. Disputes are unanswerable because the event trail was never a first-class record — it was log exhaust, rotated away before the invoice it should have justified was questioned.
Architecture on the Software Lifecycle Cloud
Metering is a write pattern, not a platform: every billable action puts a small row — customer, kind, quantity, timestamp — into the events table, keyed for per-customer reads. The monthly worker folds events into balances with the pricing rules as project code, and invoice drafts appear as records finance can inspect line by line. Analytics over the same events shows usage beside revenue, because it is the same table.
The invoice is a query, not an investigation
When a customer disputes a line, the answer is the events under it — timestamped, in the project, undeleted. Pricing changes are code changes with review dates, so “what did this cost in March” is answerable by the rules that were live in March, kept in git with the rest of the project. That is a materially different posture from asking a billing vendor what its counters remember.
- Events are ordinary table writes from the code paths that do the billable work
- Pricing rules are reviewed code, so historical invoices can be re-derived under historical rules
- Invoice drafts wait at a human step; the payment provider only ever sees approved amounts
What the payment provider still does
Charging cards, dunning, tax documents, and refunds stay with your payment provider — this pattern owns measurement and justification, not money movement. The meter feeds the provider approved drafts; the provider’s events (payment succeeded, failed) write back into the same tables, closing the loop in one place.
Frequently asked questions
As small table writes from the functions and workers doing the work — keyed by customer and time so aggregation is a scan of one customer’s slice. The write is the meter; there is no separate pipeline to keep in sync with product behaviour.
Yes, because pricing is code with an effective date. The aggregation worker applies the rules that governed each event’s timestamp, and the draft shows its arithmetic. Finance reviews drafts at a workflow step before the provider is involved.
No. It replaces the spreadsheet between your product and the provider: measurement, aggregation, drafts, and dispute evidence. Cards, tax invoices, and dunning remain the provider’s job, with outcomes written back as events.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.