SKU (Stock Keeping Unit)

A Stock Keeping Unit (SKU) is a unique alphanumeric code that identifies a specific product or service in a company's catalog. In billing and pricing systems, SKUs serve as the bridge between what customers purchase and how revenue is tracked, recognized, and analyzed.

For a SaaS company, each plan variation needs its own SKU. An Enterprise annual plan might be "ENT-BILL-YR", while a Starter monthly plan could be "STR-BILL-MO". Add-ons get separate SKUs: "ADDON-API-10K" for 10,000 additional API calls. This granularity allows billing systems to automatically apply correct pricing, track feature usage, and properly recognize revenue.

Why SKUs Matter for Billing Operations

Revenue Recognition and Compliance

Modern billing platforms use SKUs to automate revenue recognition under ASC 606 and IFRS 15. Each SKU maps to specific accounting treatment—subscription SKUs might follow ratable recognition over the contract term, while usage-based SKUs could trigger recognition upon consumption.

Without proper SKU structure, finance teams manually categorize transactions, creating delays and compliance risks. A well-designed SKU system enables automated revenue waterfall reports and audit-ready documentation.

Pricing Flexibility

SKUs enable sophisticated pricing strategies by allowing different prices for the same underlying product based on billing frequency, contract length, or bundled features. A company might offer:

• SKU "ANALYTICS-MO" at $99/month

• SKU "ANALYTICS-YR" at $990/year (two months free)

• SKU "ANALYTICS-3YR" at $2,670 (enterprise discount)

The same analytics product, three SKUs, three different pricing models—all tracked separately for revenue analysis.

Quote-to-Cash Automation

Sales teams configure quotes by selecting SKUs. Each SKU carries its pricing rules, contract terms, and billing requirements. When the quote becomes an order, the billing system knows exactly what to charge, when to invoice, and how to handle renewals or usage overages.

SKU Structure for Subscription Businesses

Effective SKU naming encodes essential billing attributes. A common pattern for SaaS companies:

[Product]-[Tier]-[Billing Period]-[Variant]

Examples:

• CRM-ENT-YR-500U (CRM Enterprise, Annual, 500 users)

• API-PRO-MO-1M (API Professional, Monthly, 1M calls)

• STOR-BAS-MO-100G (Storage Basic, Monthly, 100GB)

This structure supports several billing requirements:

Billing Period Recognition: The system knows whether to recognize revenue monthly or annually based on the SKU itself, without requiring additional configuration.

Usage Limits: For metered billing, the SKU can encode included usage, making it straightforward to calculate overages and apply overage pricing.

Upgrade Paths: Clear SKU hierarchies make it easier to define upgrade and downgrade flows, with proper proration logic.

SKU vs Other Product Identifiers

Different identifiers serve different purposes in billing systems:

SKU: Internal identifier for billing and inventory tracking. Each company defines their own SKU structure based on business needs.

Product ID: Generic database identifier that might be an auto-incremented number. Not meaningful for reporting or analysis.

Price ID: In some billing systems (like Stripe), a separate identifier specifically for the price point. One product can have multiple price IDs for different currencies or billing frequencies.

The key difference: SKUs typically encode business meaning (product type, tier, billing terms), while database IDs are arbitrary. For revenue reporting and analytics, SKUs provide context that raw IDs cannot.

Common SKU Challenges in Billing

SKU Proliferation

Creating separate SKUs for every minor variation leads to unwieldy product catalogs. A company selling software with user-based pricing doesn't need SKUs for 1 user, 2 users, 3 users, etc. Instead, use a single SKU with quantity-based pricing: customers buy quantity 5 of SKU "PROD-USER-MO".

Inconsistent Naming

When sales operations and product teams create SKUs independently, you get "PREMIUM-ANNUAL" alongside "PREMIUM-YR" and "PREM-ANN". This fragmentation makes revenue analysis difficult. Establish SKU governance before the catalog grows.

Missing Metadata

SKUs like "PROD-001" don't convey information useful for revenue analysis. Finance teams can't segment revenue by product line without additional lookup tables. Build meaning into the SKU structure from the start.

SKU Management in Modern Billing Platforms

Usage-based pricing models complicate SKU management. A customer might subscribe to a base plan SKU, consume usage tracked against a separate usage SKU, and purchase one-time add-ons with their own SKUs. All need to appear correctly on invoices and roll up properly in revenue reports.

Billing platforms like Meteroid handle this by allowing SKU hierarchies and relationships. A base subscription SKU can have associated usage SKUs, and the system knows how to:

• Combine them on a single invoice

• Apply different revenue recognition rules to each

• Track which usage belongs to which subscription

• Handle proration when plans change mid-cycle

When to Create New SKUs

Create a new SKU when:

• The price differs (same product, different billing frequency)

• Revenue recognition differs (one-time vs subscription)

• The underlying product or service differs meaningfully

• You need to track the item separately in revenue reports

Don't create a new SKU when:

• Only the quantity changes (use quantity on the line item)

• Only customer-specific metadata differs (use custom fields)

• The difference is purely presentational (same price, same product)

The test: if your finance team needs to report on this variation separately, it probably needs its own SKU.

Implementation Considerations

For early-stage companies, start with a simple, consistent naming convention that encodes product line, tier, and billing frequency. Document the structure and ensure everyone creating SKUs follows the same pattern.

For companies with existing SKU inconsistencies, a migration project becomes necessary. This typically involves:

1. Auditing existing SKUs to identify inconsistencies

2. Defining the new SKU structure

3. Creating a mapping from old to new SKUs

4. Migrating historical data for consistent reporting

5. Updating billing system configuration

The migration path depends on your billing platform's capabilities. Some systems allow SKU aliasing, where multiple SKUs map to the same underlying product. Others require full data migration.

SKUs and Revenue Analytics

Revenue operations teams rely on SKU-level data to answer questions like:

• Which product tiers drive the most revenue?

• How does annual vs monthly billing affect customer lifetime value?

• Which add-ons have the highest attach rates?

• Where should we focus product development resources?

These analyses only work if SKUs are structured consistently and encode meaningful attributes. Garbage in, garbage out—poorly designed SKUs produce unreliable analytics.

A thoughtful SKU structure serves as the foundation for data-driven pricing decisions and revenue optimization.