Partner, SDO CPA LLC / CEO, Growthy
The default chart of accounts inside QuickBooks Online or Xero looks fine on day one. By month twelve, SaaS accounting breaks it. The generic COA hides deferred revenue inside Sales. It lumps AWS into Office Expenses. It gives you no clean way to show gross margin to an investor. Most SaaS founders don't catch it until the first real diligence call. A question about deferred revenue then exposes a year of cleanup work.
Just spun up books for a SaaS company? You're in the right cluster. The rules your bookkeeper uses for a consulting firm or an agency don't carry over. Subscription revenue creates obligations that sit on the balance sheet for months or years. Commissions become contract assets. Engineering payroll splits between R&D expense and capitalized software. A generic COA can't track any of that.
This guide gives you a chart of accounts built for SaaS from day one. Two personas shaped the structure. Priya Patel is a new founder setting up books for a $200K ARR company. She wants a template to paste into QBO before her first investor update. Sarah Chen is a bookkeeper extending a default QBO COA for a SaaS client. She needs to know which accounts to add, when, and why. We'll cover both paths.
What is a chart of accounts for SaaS, and how is it different from a generic one?
A SaaS chart of accounts is a numbered list of every account your books use. It is built to handle subscription revenue rules that generic COAs miss. The gaps matter. SaaS needs Deferred Revenue accounts (current and non-current) because customers prepay for service you owe over time. It needs Contract Assets when you deliver before billing. It needs Capitalized Commissions under ASC 340-40 and Capitalized Software Development under ASC 350-40. It needs COGS sub-accounts for hosting, payment processing, and customer support so gross margin is real. A default QBO or Xero COA ships with about 50 generic accounts and none of these. Adding them up front saves a year of cleanup later.
The COA that QBO and Xero ship with was built for a generic small business. It assumes you sell something, get paid, and book revenue right away. That model works for a coffee shop, a law firm, or a contractor. It breaks the moment you sell an annual SaaS subscription.
A fresh QuickBooks Online file gives you about 50 accounts out of the box. You get Cash. You get Accounts Receivable and Accounts Payable. You get Owner's Equity, Sales, and Cost of Goods Sold as one line. You get Office Expense, Rent, Utilities, Payroll Expense, and a few more. Xero is similar. The setup is clean for service firms and retailers. It has zero SaaS-specific accounts.
Nothing on the liability side handles prepaid contracts. There's no Deferred Revenue. There's no Contract Asset. The COGS section is one line. That means hosting, payment processing, and customer support all fold into one number. You can't break it down later without rebuilding the GL.
A working SaaS COA adds three groups the defaults skip. First, a Deferred Revenue family on the liability side. That means current (within 12 months) and non-current (beyond 12 months). Add Contract Assets on the asset side for work delivered ahead of billing. Second, COGS sub-accounts that split out hosting, payment processing, customer support, and third-party API fees. Third, an OpEx structure that handles R&D versus capitalized software under ASC 350-40, plus capitalized commissions under ASC 340-40.
Without these, your P&L lies. Revenue looks bigger than it is. That's because you're recognizing cash receipts as sales. Gross margin is made up because COGS is one line. R&D and capitalized software get mixed. That skews both your operating margin trend and your balance sheet.
$500K ARR is the threshold where the default COA starts costing you money. Three pressures hit at once. First, investor reporting. A Series A or even a Seed extension pack asks for MRR, ARR, NRR, gross margin, and CAC payback. None of those come out of a default COA. Second, audit prep. At $1M+ ARR, you're a candidate for a review or audit. Auditors ask about ASC 606, ASC 340-40, and ASC 350-40. A clean COA cuts the audit work in half. Third, multi-revenue tracking. By $500K ARR, most SaaS companies have two or more revenue streams (subscription plus services or usage). A default COA can't split them.
The single biggest mistake in a SaaS COA is one Sales account. SaaS revenue almost always has multiple performance obligations under ASC 606. The GL should show that from day one.
This is the recurring revenue from a customer's contract. It's your MRR and ARR base. Every SaaS COA should have Subscription Revenue as its own top-level account. Examples: a $99 per month SMB plan, a $5,000 per month enterprise plan, or a $50,000 per year annual prepay. All of these flow into Subscription Revenue. From there they split between recognized revenue and Deferred Revenue based on the period covered.
Implementation fees, training, custom integrations, and onboarding services live here. Under ASC 606 they often count as a separate performance obligation. That means they have their own timing (usually delivery-based, not ratable). Keep them apart from subscription. Mixing them inflates your subscription number and breaks NRR math. Clean rule: if it's billable hours or a fixed-fee project, it's Professional Services, not Subscription.
When a customer upgrades from a $99 plan to a $299 plan, that extra $200 per month is expansion. Many SaaS firms track expansion apart from new-logo subscription. That way they can compute Net Revenue Retention. The GL doesn't have to do this if your billing system tracks it. If you're early and the billing system is light, an Expansion Revenue sub-account inside Subscription Revenue is the cleanest path.
If you charge per API call, per seat above a baseline, per transaction, or per GB stored, that's usage-based revenue. Under ASC 606 it's often variable consideration. That has its own rules. Track it in a separate account. The recognition pattern is different from flat subscription. A common SaaS setup: Subscription Revenue (recognized ratably), Usage Revenue (recognized when used), Professional Services Revenue (recognized on delivery), Expansion Revenue (sub-tracked for NRR).
Deferred Revenue is where most SaaS COAs first fail. The default QBO file has no deferred revenue account at all. A SaaS company that sells one annual contract on day one already has a liability the default COA cannot record.
This holds subscription obligations the company owes to customers in the next 12 months. A customer prepays $12,000 for a one-year subscription on January 1. The entry: debit Cash $12,000, credit Deferred Revenue, Current $12,000. Each month, $1,000 moves from Deferred Revenue to Subscription Revenue as you deliver the service. By year-end the deferred balance is zero (no renewal yet). For where deferred revenue lives on the balance sheet, see the deferred revenue spoke.
This holds subscription obligations beyond 12 months from the balance sheet date. Multi-year contracts (common in enterprise SaaS) create non-current deferred revenue. A customer prepays $36,000 for three years on January 1. The first $12,000 goes to current deferred. The other $24,000 sits in non-current. Each month-end, $1,000 reclassifies from non-current to current as the obligation shortens. Most early SaaS firms skip this split until they have multi-year contracts.
You issue a credit (refund, goodwill credit, comped month) that hasn't been used yet? It sits here. This account keeps refund obligations out of Deferred Revenue. Otherwise it would skew the deferred balance. Examples: a $500 service credit issued during a support escalation that the customer hasn't used, or a refund approved but not yet sent.
Contract Assets sit on the asset side of the balance sheet. They belong in this section because they mirror Deferred Revenue. A Contract Asset shows up when you've delivered service the customer hasn't been billed for. Example: you finish a $20,000 implementation on day 30. The contract says billing happens on day 45 at a milestone. For 15 days, the $20,000 sits as a Contract Asset. Once invoiced, it moves to Accounts Receivable.
A single COGS line is the second-most-common SaaS COA failure. Investors, auditors, and your future CFO all care about gross margin. A single COGS line makes gross margin a guess.
AWS, GCP, Azure, Vercel, Cloudflare, and any other infra that runs your product belongs here. It's direct. It scales with usage and customer count. The test for COGS versus G&A: does the cost grow when revenue grows? Hosting passes. A Cloud Infrastructure or Hosting and Infrastructure account inside COGS is the right home. Don't bury it in Software Subscriptions inside G&A.
Stripe, Adyen, Braintree, and other processor fees scale with revenue (typically 2.9% plus $0.30 per transaction for Stripe). Every dollar of subscription revenue carries a payment processing cost. That makes it COGS. Putting it in G&A understates COGS and inflates gross margin. A clean Payment Processing account inside COGS is the right answer.
The allocated cost of CS and CSM headcount belongs in COGS, not G&A. Helping customers is part of delivering the service. That's the textbook meaning of cost of goods sold for a service business. Allocate the share of headcount time that goes to direct customer support (typically 70-100% of CSM pay) to a Customer Support COGS account. The rest stays in G&A.
Your product calls Plaid for bank connections, Twilio for SMS, OpenAI for inference, or other paid APIs? Those costs scale with usage. They belong in COGS. A Third-Party Services or API and Data Costs account inside COGS catches these. This is the line that grows fastest for AI-native SaaS. There, inference costs can rival or exceed hosting.
Engineering payroll is the single largest expense for most SaaS firms. It's also the most often mis-recorded. ASC 350-40 sets the rules for how internal-use software costs are treated. The rules are specific.
ASC 350-40 covers software built for internal use. That includes most SaaS products. (The company is the user; customers reach the software as a service.) Under ASC 350-40, costs split into three stages. The preliminary stage (pre-feasibility) is expensed as incurred. The app development stage (after technical feasibility) is capitalized. The post-launch stage (upkeep, bug fixes, small fixes after launch) is expensed.
Capitalized: developer salaries, contractor fees, and other direct costs during the app development stage. Once a feature reaches technical feasibility, the engineering time to build it can capitalize as a software asset on the balance sheet. (Technical feasibility means a detailed program design exists or a working model has been done.) The asset then amortizes over its useful life (typically 3 to 5 years).
Expensed: research, exploration, prototyping before feasibility, and ongoing upkeep after a feature launches. The R&D Expense account holds these. Many early-stage SaaS firms expense 100% of engineering payroll until the capitalization math matters. (That's typically post-$5M ARR for tax and audit reasons.)
The blur happens because "feasibility" is a judgment call. Engineering work doesn't fit neatly into stages. A small team building V1 might span all three ASC 350-40 stages in one sprint. Most early-stage SaaS firms (under $5M ARR) take the safe path. They expense everything as R&D until audit pressure or a tax reason pushes them to capitalize. That's defensible and simple to run. By the time you're audited, your CFO and audit firm will rebuild the capitalization schedule.
ASC 340-40 (Other Assets and Deferred Costs, Contracts with Customers) requires you to capitalize the incremental costs of obtaining a contract with a customer. For SaaS, that mostly means sales commissions.
Any commission paid as a direct result of winning a contract counts as an incremental cost. Say the AE got a $5,000 commission for closing a $50,000 ACV contract. That $5,000 capitalizes. The asset sits on the balance sheet as a Contract Asset or Deferred Commission Expense (account naming varies). It then amortizes over the expected benefit period.
The amortization period is the expected customer life, including expected renewals. For most SaaS firms, this is 3 to 5 years. A contract has an initial 1-year term. The company expects most customers to renew for an average of 4 years. The commission amortizes over 4 years, not 1. This is one of the most-debated SaaS accounting calls. It's one of the first things auditors will ask about.
ASC 340-40 has a practical expedient. If the amortization period is one year or less, you can expense the commission as incurred. You don't have to capitalize. Many early-stage SaaS firms use this expedient for SMB contracts where renewal is uncertain. For enterprise contracts with multi-year terms, the expedient often doesn't apply. Full capitalization is the right answer. Note: Bobby is a CPA firm partner, not personally a CPA. Confirm ASC 340-40 with your CPA before locking the policy.
Here's a 20-account starting template. It handles day one through about $500K ARR. The numbering uses the standard 1000s/2000s/3000s/4000s/5000s/6000s setup. That keeps the file compatible with QBO and Xero defaults. For SaaS bookkeeping year-one setup, see the SaaS bookkeeping spoke. For software choice, see the SaaS accounting software comparison.
Account # | Account Name | Type | Notes |
|---|---|---|---|
1000 | Cash, Operating | Asset | Main checking |
1010 | Cash, Reserve | Asset | Optional second account |
1100 | Accounts Receivable | Asset | From invoicing |
1200 | Contract Assets | Asset | Delivered, not yet billed |
1500 | Prepaid Expenses | Asset | Annual software, rent |
2000 | Accounts Payable | Liability | Vendor invoices |
2100 | Deferred Revenue, Current | Liability | Within 12 months |
2110 | Deferred Revenue, Non-Current | Liability | Beyond 12 months |
2200 | Customer Credit Liability | Liability | Issued, not applied |
3000 | Owner's Equity / Common Stock | Equity | Founder equity |
4000 | Subscription Revenue | Revenue | Recurring SaaS |
4100 | Professional Services Revenue | Revenue | Implementation, training |
4200 | Usage Revenue | Revenue | Consumption-based |
5000 | COGS: Hosting and Infrastructure | COGS | AWS, GCP, Azure |
5100 | COGS: Payment Processing | COGS | Stripe, Adyen |
5200 | COGS: Customer Support | COGS | Allocated CS payroll |
5300 | COGS: Third-Party APIs | COGS | Plaid, Twilio, OpenAI |
6000 | R&D Expense | OpEx | Engineering payroll |
6100 | Sales and Marketing | OpEx | Sales, ads, content |
6200 | General and Administrative | OpEx | Rent, legal, finance |
By $500K ARR, you'll need more detail to support investor reporting and audit prep. Add these accounts: Capitalized Commissions (asset, ASC 340-40). Commission Expense (OpEx, the amortization line). Sales Payroll (split out from S&M). Marketing Programs (split out from S&M). Customer Success Payroll (allocated portion in COGS). Software Subscriptions (G&A sub-account). And Contract Liabilities reclassification entries. That's about 6 to 8 new accounts. See chart of accounts for saas.
By $5M ARR, the COA needs multi-entity, multi-currency, and capitalized software development. Add these: Capitalized Software Development (asset, ASC 350-40). Amortization of Capitalized Software (contra-asset). Intercompany Receivables and Payables (for multi-entity). Foreign Currency Adjustment (for global expansion). Deferred Tax Asset / Liability (for ASC 740). Plus sub-ledgers for Capitalized Commissions by cohort. This is also when most firms switch from QBO to a mid-market GL (NetSuite, Sage Intacct, or similar). At that point, the COA tops 100 accounts and consolidation logic gets complex. A cross-cluster note: the pattern here is the same as any chart of accounts build. The SaaS-specific accounts are layered on top of a standard accrual frame.
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.
Related: SaaS Accounting, Chart of Accounts, AI Bookkeeping.
Free during alpha. Read-only access. You review every sync.
CPA firm partner who got tired of watching bookkeepers click categorize 500 times a day. Built Growthy to fix it.
View author profileGrowthy is dedicated to helping businesses of all sizes make informed decisions. We adhere to strict editorial guidelines to ensure that our content meets and maintains our high standards.
Day-1 through end-of-year SaaS bookkeeping setup for founders. Chart of accounts, deferred revenue, Stripe, 1099s, and ASC 606 awareness without overengineering.
Practitioner comparison of 7 SaaS accounting options. QBO, Xero, Maxio, Chargebee, RecVue, Stripe Billing, and Growthy mapped to ARR stage and contract complexity.
Where deferred revenue lives on the SaaS balance sheet, the JE pattern on signing vs cash vs recognition, the monthly roll-forward, and what changes the balance in real-world contract churn.