Open source usage-based billing for AI and API products

Auditors look for an ingestion log that shows every event received, the idempotency key or transaction ID used to reject duplicates, and a reconciliation between events sent by the product and events counted by the billing platform. In a self-hosted Lago deployment, the event ingestion API and its stored event records are the primary evidence, and the product's own request logs are the upstream source to compare against. Kill Bill usage records follow a similar pattern through its usage API. Confirm with your engineers exactly which fields form the deduplication key, how late or out-of-order events are handled, and how dropped events are detected and replayed. DeployOpen prepares the evidence and the test records, but independent auditors and certification bodies issue any opinion on whether these controls are effective.

An invoice line should link to the metric, the billing period, the aggregated quantity and the individual events or aggregation job that produced it. Lago and Kill Bill both record usage against subscriptions and billing periods, so the invoice record, the usage records and the aggregation query can be exported together. Ask for a documented rule for rounding, tiering and credit application, and keep the query version used for each invoice run. Reviewers will sample invoices and ask you to rebuild the amount from raw events, so the trace must work for a closed period months later, not only for the current cycle.

Auditors expect an change history for every catalog item, price, metric definition and prepaid credit rule, with the user, the time, the old value and the approval. The evidence comes from the billing platform's audit trail for configuration changes, combined with your change management tickets and the code or infrastructure-as-code repository that deploys catalog changes. Record who can publish a price change and whether a second person must approve it. If pricing lives in a database managed outside the platform, the change path becomes harder to prove, so confirm where the authoritative catalog is stored before the first audit.

Reviewers ask for logs that show who logged in to the billing administration console, who changed configuration, who issued manual credits or refunds, and who accessed customer or payment data. Forward these logs from the Lago or Kill Bill containers, the reverse proxy and the database to a central, write-protected store with restricted access and a defined retention period. The FTC Safeguards Rule at 16 CFR 314.4 expects covered financial institutions to log the activity of authorized users, and that expectation is a useful benchmark even where the rule does not apply to your business. Confirm the retention period and the access list with your compliance lead.

Retention depends on the jurisdiction, the sector and the contracts, so the answer is a schedule you define with legal and finance, not a single number. For broker-dealers, the SEC's Rule 17a-4(b) requires preservation of records such as bills receivable or payable for not less than three years, the first two in an easily accessible place, which shows how regulators phrase retention. Plan storage for raw usage events, aggregated usage, invoices, credit notes and audit logs separately, because event volumes grow much faster than invoice volumes. Test restores from backups against the retention schedule, and confirm how deletion requests under privacy law interact with records you must keep.

The billing platform is in scope when it stores, processes or can affect customer data or financial reporting, and it should appear in the system description or the ISMS scope document. For SOC 2, the security common criteria CC1 to CC9 apply to every report, and the system description must name the billing components, their hosting and their third-party dependencies, including the payment gateway. For ISO/IEC 27001:2022, the scope statement and the Statement of Applicability must list the relevant Annex A controls for the platform. Accredited certification bodies, not ISO, decide certification, and an independent CPA firm issues any SOC 2 report. DeployOpen can prepare the system descriptions, control mapping and evidence packs for these assessments.

DeployOpen plans, implements and documents the billing platform in your environment, then prepares the evidence that auditors and regulators will request, such as configuration exports, access reviews, change records, reconciliation reports and test results. DeployOpen does not issue audit reports, attestations or certifications, and does not decide whether your controls are effective. That decision belongs to independent auditors, certification bodies or your regulator. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask any partner which evidence they will produce, in what format, and who keeps it after handover.

The effort is driven mainly by how many billable metrics you have, how many events you ingest, how complex your credit and pricing rules are, which payment flows you need, and which regulated controls apply. Each billable metric needs a defined event schema, aggregation logic and test cases, so ten metrics is a very different job from two. High event volume pushes the work toward load testing, partitioning and choosing an event store. Prepaid credits add balance logic, expiry rules and top-up flows. Payment flows and card handling add integration and PCI scoping work, and regulated controls such as audit trails and change approvals add evidence work on top of the build. Ask any partner to size the work against these five drivers in writing before agreeing a price.

Most of the delay in usage billing projects comes from decisions that were never made, so the client has to supply three things. First, pricing decisions: the billable units, unit prices, tiers, included allowances, credit bundles and how unused credits are treated. Second, named data owners who can confirm what each event means, which system is the source of truth for usage, and how disputes are resolved. Third, environment access: staging and production infrastructure in your own cloud account or data center, service accounts for the metering source, the payment gateway sandbox, the general ledger and the identity provider. Missing any of these pushes the schedule, and the written scope should list who provides each input and by when.

A strong internal team with backend, data and finance engineering experience can build a self-hosted billing stack, and some do. The questions to answer honestly are whether you have people who can operate Postgres or ClickHouse at your event volume, who will own the Lago or Kill Bill upgrades, who understands revenue recognition and tax well enough to validate invoices, and who will produce the evidence an auditor asks for. If those skills are thin, a partner can take on the planning, build, hardening and documentation while your team keeps ownership of pricing and data. DeployOpen works this way: it plans, implements, customizes, integrates, backs up and documents self-hosted platforms inside your own infrastructure, under a fixed scope agreed in writing.

Duration depends on scope, so no general timeline can be given. The main inputs are the number of billable metrics, the event volume and store design, the credit and payment flows, the tax and accounting integrations, and how many environments and approval gates your change process requires. Two projects with the same platform can differ widely in length for these reasons. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, after the requirements and pricing decisions are settled. When you request a proposal, ask for the milestones, the client inputs each milestone depends on, and what happens to the timeline if pricing rules change mid-build.

After go-live, costs recur in four areas. Infrastructure is the first: compute, storage and backups for the billing application, the event store and the payment-related components, which grow with event volume and retention. Upgrades are the second, since Lago and Kill Bill release regularly and each upgrade needs regression testing against your metrics and invoices. Monitoring and on-call support are the third, because a missed event batch or a stalled invoice run directly affects revenue. The fourth is ongoing support, which can be bought as a retainer covering upgrades, monitoring, security testing and changes to pricing. Ask any partner to separate one-time build fees from these recurring items so you can compare total cost of ownership over several years.

The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period under Articles 23, 25 and 50. From 12 January 2027, providers may not impose any switching charges under Article 29, and until then reduced charges may not exceed costs directly linked to switching. For a self-hosted build, the Act applies to a provider, not to you running your own software, so the practical lesson is to design exit now: keep usage history and invoices in documented, exportable formats, and keep your pricing rules and event schemas written down. Confirm with your legal team whether the Act reaches your specific arrangements.

Ask for a written scope that lists each billable metric, the event sources and expected volume, the event store choice and its reasoning, the credit model, the payment and tax integrations, and the accounting interface. The quote should show deliverables and acceptance criteria for each, the client inputs each one depends on, and the testing approach, including reconciliation of usage with invoices. Ask which items are one-time, which are recurring, and what is excluded, such as platform licenses, enterprise add-ons, cloud fees or third-party tax engine costs. Finally, ask how changes to pricing after sign-off are priced and approved, because that is where usage billing budgets most often move.

Three decisions move cost more than the rest. The first is the event store: Postgres may be sufficient for lower volumes, while ClickHouse adds operational skills and infrastructure that pay off at high event volume, so test both against your expected load before committing. The second is the credit model, because prepaid balances, expiry and refunds need careful ledger logic and tests. The third is how tightly usage is reconciled with invoices and the general ledger, since automated reconciliation takes more build effort but reduces manual finance work every month. Ask each partner to show how these three choices affect the quote and the recurring cost.