Revenue recognition is an accounting principle that determines the specific conditions under which a business can claim earned revenue. For SaaS companies, especially those with usage-based or consumption-based billing, this gets complicated. You can’t just recognize revenue the moment a customer pays an invoice; you must recognize it as you deliver the service.

This is governed by the ASC 606 standard, which states that revenue is recognized when the customer gains control of the promised goods or services. In a usage-based model, the “service” is delivered every time a user consumes a resource—makes an API call, processes a transaction, or uses a gigabyte of storage. Aligning your billing system with this principle is crucial for accurate financial reporting and compliance.

For engineers, this isn’t just an accounting problem. The way you design your metering and billing infrastructure directly impacts how your company reports its financial health. Getting it wrong can lead to misstated earnings, compliance issues, and major headaches for your finance team.

ASC 606 outlines a five-step framework for recognizing revenue. For a usage-based SaaS model, the key is understanding how these steps apply to a variable, ongoing service.

The five core steps are:

1. Identify the contract with a customer: This is typically the subscription agreement or terms of service your user agrees to.
2. Identify the performance obligations: What did you promise to deliver? In usage-based models, this is often a “stand-ready obligation”—the promise to be available and ready to provide a service on demand.
3. Determine the transaction price: This is the total compensation you expect to receive. For usage-based billing, this amount is variable and not fully known upfront.
4. Allocate the transaction price: If you have multiple distinct services (e.g., a base subscription fee plus overages), you allocate the price to each one.
5. Recognize revenue when (or as) performance obligations are satisfied: This is the most critical step. For a stand-ready service, you recognize revenue as the customer consumes units of service over the contract term.

The main challenge is the mismatch between when a customer might pay (e.g., pre-paying for credits) and when they actually use the service. Revenue can only be recognized as consumption occurs.

Building a system that handles usage-based revenue recognition correctly requires thinking about specific accounting patterns from the start. Here are a few critical concepts and how they translate to system design.

Accurate, auditable metering is the foundation. Your system must reliably track every billable event.

• System Design: Implement a durable, idempotent event pipeline for usage data. Every API call, data transfer, or billable action should generate a usage record that can be aggregated.
• Financial Impact: This usage data is the source of truth for both invoicing the customer and telling your finance team how much revenue to recognize for a given period.

This is the accounting term for pricing that changes based on usage. The total contract value isn’t fixed.

• System Design: Your billing system needs to calculate variable charges based on aggregated usage data. This involves applying tiered pricing, per-unit costs, or other models after the billing period ends.
• Financial Impact: At the end of each financial period (e.g., monthly), the finance team needs a reliable report of accrued usage to estimate revenue, even if it hasn’t been billed yet.

This concept applies when you promise to provide access to a service over a period, and the customer consumes it at their discretion. Think of an API service or cloud infrastructure.

• System Design: Your platform must be architected for high availability to fulfill this promise. From a billing perspective, your system needs to distinguish between the right to access the service and the actual consumption of it.
• Financial Impact: For a pure pay-as-you-go model, revenue is recognized as usage happens. If there’s a base fee for access, that portion might be recognized straight-line over the month, while the usage component is recognized as it’s consumed.

Many SaaS companies sell “credits” that customers can draw down. This improves cash flow but adds a layer of complexity to revenue recognition.

• System Design: You need a ledger system to track the customer’s credit balance. When a customer buys credits, you record the payment and a corresponding liability (unearned or deferred revenue). As they use the service, you draw down their credit balance and convert that liability into recognized revenue.
• Financial Impact: Cash received from selling credits is not revenue. It’s a liability on your balance sheet until the service is actually used. Your system must provide a clear report showing how much deferred revenue was converted to recognized revenue in a period.

Building a compliant usage-based billing system is complex. Here are some common pitfalls:

• Inaccurate Metering: Dropped events or double-counting can lead to incorrect bills and revenue reports. Your system needs to be resilient and auditable.
• Handling Disputes and Adjustments: When a customer disputes a charge, you need a clear process for issuing credits or making adjustments. This requires not only updating the invoice but also reversing the corresponding revenue recognition entry.
• Mid-cycle Plan Changes: Customers upgrading or downgrading in the middle of a billing cycle create complexity. Your system must correctly prorate charges and recognize revenue for the portion of the month spent on each plan.
• Data Reconciliation: The data in your billing system and your accounting ledger (like NetSuite or QuickBooks) must match. This often requires building robust data pipelines and reconciliation reports to ensure consistency between engineering and finance.

• Collaborate with finance early: Don’t build in a silo. Work with your finance or accounting team to understand their requirements for revenue reporting. Map out data schemas and reporting needs before you write code.
• Build an auditable event stream: Use a system like Kafka or a dedicated event store for usage data. Ensure every event has a unique ID, a timestamp, and relevant metadata. This creates an immutable log that can be replayed or audited if discrepancies arise.
• Separate billing from revenue recognition: While they are related, they are not the same process. A customer might be billed at the end of the month for all their usage, but from a reporting standpoint, revenue is recognized daily as usage occurs. Design your data models to support both views.
• Think in ledgers: For handling things like prepayments, credits, and deferred revenue, a double-entry ledger system is the gold standard. It ensures that all debits and credits balance and provides a clear audit trail.

Kinde’s billing engine is designed to handle the complexities of modern SaaS pricing, including usage-based models, making it easier to keep your billing and revenue recognition in sync.

It provides a flexible framework for defining plans with both fixed and variable components. You can create metered features and then report usage against them via the API. This structured approach ensures that all the necessary data for accurate revenue recognition is captured at the source.

• Metering: Kinde allows you to define metered features within your plans. You can then use the API to push usage data for each customer, creating a reliable source of truth for consumption.
• Flexible Pricing Models: Kinde supports various pricing models, from simple per-unit costs to sophisticated tiered pricing. This allows you to construct plans that align with your business model while ensuring the underlying data is clean and structured.
• API-driven Usage: By providing a simple API endpoint to record metered usage, Kinde allows engineers to focus on their core product logic while ensuring that every billable event is tracked accurately for both billing and financial reporting.

This separation of concerns—where your application reports usage and Kinde handles the aggregation, rating, and invoicing—is a powerful pattern for building a compliant and scalable billing system.

• Pricing models
• About plans
• Add metered usage for a customer via API