Cycle

Simplified billing for complex pricing

The introduction of AI and agents has increased expectations for the software we build. Rather than being a tool used to get the task done, it is now expected to do the task for our customers.

We, as builders, have stepped up to the challenge. The software we build now handles much more of the surface area of the task, doing more of the work. But this has increased the complexity of how we price and get paid for doing that work.

Billing was broken, even before SaaS

Telephone companies were struggling with usage-based billing in the 1990s, simultaneously overcharging and undercharging customers, leading to regulatory step-in. Software in its infancy was shielded from this complexity. From yearly enterprise contracts with IBM, to pay-once-own-forever CDs, to shareware, freemium, and per-seat, pricing stayed simple.Jube Shiver Jr., “Dial ‘M’ for Mistakes: Billing Systems Outpaced by a Telephone Explosion,” Los Angeles Times, May 7, 1993“An explosion in the number of telephone lines, services and rates is taxing phone company computers, costing users an estimated $160 million a year in overcharges.”Telecom Regulatory Authority of India, Quality of Service (Code of Practice for Metering and Billing Accuracy) Regulation, 2006“Every service provider shall, by the 30th April of every year, appoint an auditor from the panel of auditors notified by the Authority.”

Billing, even for this simpler model of pricing, was hard. Most of the billing code was built in-house by engineers who wanted to work on something else. Pricing changes were slow to roll out, required engineering support, were inaccurate, and still fell down in the face of billing complexity.Mark Dominus, “Moonpig: a billing system that doesn’t suck,” December 16, 2013“…severely constrained the sort of pricing structures and deals that could actually be executed.”

Billing is hard now, and AI made it 10x harder

We expect billing to be solved in 2026, only to be disappointed. We have to choose between metering point solutions, code-led pricing changes or customizing an entire OSS project to your needs. Usage-based pricing, metering, enterprise plans, credits, and taxes will overwhelm any homegrown billing system.Metronome, a usage-based billing platform.Orb, a billing platform for usage-based pricing.Lago, an open-source metering and billing platform.

The reason billing remains unsolved is that we cannot derive a common ontology of billing. Two customers inside the same company might have vastly different billing shapes when we take into account custom pricing, enterprise contracts, and grandfathered pricing. This makes it hard for pricing to be represented by rigid data models.

Introducing Cycle, billing as a directed graph

Cycle represents the billing ontology as a directed graph, and billing is derived by walking the graph. This lets us model subscriptions, credits, overages, one-off charges, and complex pricing as nodes on the graph that aggregate into an invoice.

This eliminates all the issues associated with billing. We have multiple billing graphs for enterprise and per-user billing, and bill every customer differently without the constraints of a single data model.

How the future of billing should be

  1. Billing should be easy, even for complex pricing. We support any degree of complexity in pricing, abstracting it away into a system that is easy to integrate for engineers and easy for product and sales to experiment with pricing.
  2. Billing should be real-time. We should be able to calculate the billing state for our customers at any given time, in real time. This allows us to derive real-time usage limits and entitlements, improving our odds of taking better care of the customer.
  3. Billing should be auditable. Every charge should be traceable back to the billing event that created it. Every invoice should be accurately reproducible at any point in time.

How we are building that future at Cycle

Cycle is the future of billing. We are building towards that future with these core decisions.

  1. Billing is represented as a graph. By representing billing as a graph, we can support all billing ontologies and represent N-complex pricing.
  2. Billing implementation is derived from the graph. Developers get access to implementation details specifically tailored to the billing ontology of your organization, reducing time to implement and effort to maintain.
  3. Billing is aggregated in real time. By having a real-time, high-throughput event aggregation system, we can meter usage-based billing precisely, and limit and bill for usage without any delay.

Get started with Cycle

We are starting with early-growth AI teams who are migrating from self-built billing systems or prebuilt ones. Our integrations team will handle the migration for you, helping you set up your custom billing graph and run extensive tests to make sure you are billing correctly.