COGS Calculation for Usage-Based SaaS Founders: Practical Spreadsheet to Automated Cost Model Roadmap

Foundational Understanding: Is It COGS or OpEx? The First, Most Important Question

Before you can calculate anything, you must correctly classify your costs. The critical distinction is between Cost of Goods Sold (COGS), also known as cost of revenue, and Operating Expenses (OpEx). This isn't just an accounting exercise; it directly impacts your gross margin, a key metric investors use to judge your company's scalability and long-term viability.

The litmus test is simple: does the cost increase directly as you deliver your service to a paying customer? If yes, it is likely COGS. If the cost remains relatively fixed regardless of how many customers you serve, it is likely OpEx.

For a US company following US GAAP or a UK company on FRS 102, the principles for this classification are similar. For example, consider an AWS server. If that server is part of your production environment and its usage scales to serve billable customer activity, its cost is COGS. However, if a developer uses an identical server in a staging environment for research and development, that cost is OpEx. R&D costs are incurred to build future products, not to deliver the current one. Further guidance can be found in the IFRS guidance on accounting for cloud computing costs.

Getting this right is fundamental. Your SaaS gross margin, calculated as Revenue minus COGS, tells you and your investors how much profit you make from your core service before other business expenses. A high gross margin indicates a healthy, scalable business model. Misclassifying OpEx as COGS will artificially depress this number, sending the wrong signal about your company’s potential.

Part 1: The "Good Enough" COGS Model for Early-Stage Startups

The reality for most early-stage startups is pragmatic. You do not need an enterprise-grade system from day one. You need a spreadsheet that gets you most of the way there. Your initial goal is not perfect precision. As a guiding principle, "The goal for an early-stage COGS model is 80% accuracy, not 100% precision." Your focus should be on building a model that is directionally correct and helps you make better decisions today.

Most founders begin this process in a spreadsheet, pulling data from a few key sources: your cloud provider (AWS, GCP), key third-party API vendors (OpenAI, Twilio), and your payment processor like Stripe for usage data. What founders find actually works is a simple structure that tracks costs per customer.

In your model, you can list each customer and the services they consume. For each service, you would note their billed usage units, apply your calculated unit cost, and determine the total COGS for that specific activity. For instance, you might find CUST-001 used 1,000,000 API calls at a unit cost of $0.0005 for a total of $500, plus 50 GB of data storage at $0.10 per GB, adding another $5 in COGS.

To populate this, you start with proportional allocation. If your total AWS bill was $10,000 and product logs show that Customer A was responsible for 20% of total API calls, you can allocate $2,000 of that cost to them. It is an estimate, but it provides immediate insight into customer profitability. This initial usage-based COGS model provides the foundational visibility needed to manage your runway and understand core business dynamics.

Part 2: Identifying and Allocating Your Key Cost Drivers

Your AWS or GCP bill might be dozens of pages long, filled with line items that are difficult to decipher. The key is to avoid getting lost in the details and focus on what truly matters. For most SaaS companies, "The 80/20 Rule applies to COGS drivers; 2-3 services often drive 80% of costs."

Your first task is to identify these primary drivers. Scan your largest invoices from cloud and API providers. Typically, the culprits are obvious: Amazon S3 for data storage, EC2 for compute hours, or token usage from an AI provider like OpenAI. These two or three line items are where you should focus your initial energy.

Once you have identified a key driver, the next step is to calculate its per-unit cost. This metric is essential for building accurate financial models and setting prices that protect your margins. The calculation is straightforward: Total Cost of the service divided by the Total Usage Units. For example:

• An "Example cloud infrastructure cost: $1,000 total S3 cost for 10,000 GB of customer data results in a per-unit cost of $0.10 per GB."
• An "Example API usage cost: $5,000 paid to OpenAI for 1 billion tokens results in a per-unit cost of $0.000005 per token."

This per-unit cost is your foundational metric for understanding your unit economics. It connects your infrastructure spending directly to customer value. While more mature companies use sophisticated cloud cost allocation methods like resource tagging, starting with this blended per-unit rate is a powerful and sufficient first step. The FinOps Foundation provides deeper resources on cloud cost allocation as you scale.

Part 3: When the Spreadsheet Breaks, And What to Do Next

A spreadsheet is the perfect tool to start, but eventually, it will hold you back. Knowing when to upgrade is critical. The signs are usually a mix of operational pain and strategic limitations that become too significant to ignore.

How do you know it is time to move on? There are two clear indicators. The first is operational. "A key trigger to move off spreadsheets is when month-end COGS close takes more than two days of a technical or finance person's time." When your best engineer or co-founder is spending days manually exporting CSVs and reconciling numbers instead of building the product, the opportunity cost is too high. The operational pain becomes impossible to ignore. Exploring metering infrastructure options can help reduce this manual work.

The second trigger is strategic. "A key trigger is when a VC asks for gross margin by customer segment and it cannot be answered within 24 hours." This question is not just about the numbers; it is a test of your operational maturity and financial control. If you cannot answer it quickly and confidently, it signals a risk to potential investors.

A scenario we repeatedly see is a founder heading into a Series A fundraise who discovers during due diligence that their largest user has been on a legacy free tier. The company was unknowingly subsidizing this customer's heavy usage, which had completely distorted their overall SaaS gross margin. This is the kind of surprise that a robust usage-based COGS system is designed to prevent.

The evolution from here is natural. The next step is often a simple data warehouse that automatically pulls data from your various sources into one place for analysis. Dedicated cost management platforms are another option. The spreadsheet has done its job; it got you started, but now your scale demands a more automated, reliable system.

Practical Takeaways: Your COGS Roadmap

Managing your usage-based COGS is an iterative process. Your approach should evolve with your company's stage and complexity. Here is a simple roadmap to guide you.

Pre-Seed and Seed Stage

Stick with the "good enough" spreadsheet. Your goal is 80% accuracy, not perfection. Identify your top two or three cost drivers, calculate a blended per-unit cost, and use proportional allocation to get a directional sense of customer profitability. This is all you need to start making informed decisions about pricing and runway.

Series A

The spreadsheet is likely at its breaking point. If your month-end close is becoming a significant time sink or you cannot answer investor questions about margins by segment, it is time to evolve. Begin implementing basic cloud cost allocation through methods like resource tagging in your cloud provider. The goal is to improve the accuracy of your SaaS gross margin and gain more granular insights.

Series B and Beyond

At this stage, a spreadsheet is no longer a viable primary tool. You should have a more automated system, whether a data warehouse or a dedicated platform, that provides near-real-time visibility into your SaaS variable expenses. This granular data is no longer just for accounting; it is a critical input for strategic decisions about enterprise pricing, product roadmap, and overall financial planning.

Your first model will not be perfect, but starting with a simple, pragmatic approach will provide the financial clarity needed to scale confidently. Continue at the Usage-Based Pricing hub for more frameworks and deeper guides.

Frequently Asked Questions

Q: What are the most common COGS categories for a usage-based SaaS company?
A: The most common COGS are cloud infrastructure costs like compute and storage from providers like AWS, GCP, or Azure. Other typical costs include third-party API fees from services like OpenAI or Twilio, and sometimes specific data pipeline or content delivery network (CDN) expenses that scale directly with customer usage.

Q: How often should an early-stage startup update its COGS model?
A: At a minimum, you should calculate and review your COGS monthly as part of your financial close process. This frequency ensures you can spot trends in customer profitability, catch margin erosion early, and make timely adjustments to your pricing or infrastructure usage before problems become significant.

Q: Can employee salaries be considered COGS in a SaaS business?
A: Generally, salaries for R&D, sales, and marketing are considered OpEx. However, salaries for employees directly involved in delivering the service or providing mandatory customer support, such as a customer success or support team, can sometimes be partially allocated to COGS. Consult with your accountant to ensure proper classification under US GAAP or FRS 102.