Chart of Accounts for Software Development Studios: A Practical Structure Guide

Key Takeaways

• A software studio's chart of accounts must separate project revenue, retainer revenue, and any product/SaaS revenue — blending them hides margin differences that matter for pricing decisions.
• Subcontractor costs belong in COGS, not operating expenses — misclassifying them overstates gross margin and distorts project profitability.
• Tooling and SaaS subscriptions used directly on client work are COGS; internal tooling (Slack, HR software) belongs in operating expenses.
• Per-project reporting is best achieved through accounting dimensions (classes, projects, or jobs) rather than multiplying accounts — keep the COA lean and use dimensions for the detail.
• Capitalized software development costs follow ASC 350-40 (for internal-use software) or ASC 985-20 (for software built to sell) — the rules differ, and the distinction belongs in your COA from day one.

A chart of accounts for a software development studio is the numbered list of every account your accounting system uses to record transactions — and for a dev shop, the default QuickBooks or Xero template will mislead you almost immediately. Generic templates don't distinguish project revenue from retainer revenue, don't know where to put subcontractor costs, and have no concept of capitalized development work. This guide covers the structure a software studio actually needs, account by account.

Why a Generic COA Fails a Software Studio

A standard small-business chart of accounts is built around product sales and simple service income. A software studio's revenue and cost structure is fundamentally different.

In practice, a dev shop typically earns revenue from at least two or three distinct streams: fixed-price project work, time-and-materials engagements, ongoing retainers or maintenance contracts, and sometimes a SaaS or licensed product the studio has built for itself. Each stream carries a different margin profile. Professional services revenue typically runs 30–40% gross margin, while subscription revenue can reach 75–85% — blending them into a single revenue line makes your P&L useless for pricing decisions.

On the cost side, a generic template lumps subcontractors into "professional fees" alongside legal and accounting costs. That's a COGS misclassification that inflates your reported gross margin and makes project profitability invisible.

The fix isn't adding 50 accounts. As accounting-wise.com notes, if you need analysis, use dimensions — classes, departments, locations, or projects — rather than proliferating accounts. The COA provides the categories; dimensions provide the per-project detail.

How to Structure the Chart of Accounts for a Software Studio

The standard numbering convention works well and is consistent across QuickBooks, Xero, and most accounting platforms:

Leave gaps between account numbers — use 4100, 4200, 4300 rather than 4001, 4002, 4003 — so you can insert new accounts without renumbering. NetSuite's guidance on SaaS COA structure recommends this explicitly: if AR starts at 1200 and prepaid expenses at 1300, accounts 1201–1299 remain open for future AR sub-accounts.

Asset Accounts (1000–1999)

The capitalized software development account (1300) deserves particular attention. Whether and how you capitalize development costs depends on what you're building — see the section on capitalization below.

Revenue Accounts (4000–4999)

This is where most generic templates fail a software studio. Separate your revenue streams from the start:

If you want to understand the revenue recognition mechanics for fixed-fee work, our guide on fixed-fee software project revenue recognition covers the ASC 606 framework in detail.

COGS Accounts (5000–5999)

COGS for a software studio includes every cost that is directly tied to delivering client work. Getting this right is what makes gross margin meaningful.

Subcontractors belong in COGS. This is the most common misclassification in dev shop accounting. When a contractor is engaged to deliver client work, that cost is a direct cost of revenue — not a G&A or professional fee. Misclassifying it in operating expenses overstates gross margin and makes project profitability invisible.

Kruze Consulting's startup COA template shows contractors and consultants as a distinct line within professional fees at the operating expense level — that structure works for a startup with no client-delivery contractors, but a dev shop billing contractor time to clients needs those costs in COGS, not below the gross margin line.

Tooling classification depends on use. A GitHub Enterprise license used exclusively on client projects is COGS. Slack, your HR platform, or your internal project management tool is an operating expense. When a tool is used for both, allocate based on a reasonable split and document the methodology.

Operating Expenses (6000–7999)

Liability Accounts (2000–2999)

Deferred revenue is non-negotiable if your studio bills project deposits or retainers upfront. Under ASC 606, payments received before performance obligations are satisfied must be recorded as contract liabilities on the balance sheet, recognized as revenue only as you deliver. Two separate deferred revenue accounts — current and long-term — keep your balance sheet clean and your revenue recognition accurate.

Where Do Subcontractor and Tooling Costs Sit?

Subcontractor costs for client delivery sit in COGS (account 5200). Tooling used on client projects sits in COGS (account 5300). Everything else — internal tooling, G&A contractors, legal — sits in operating expenses.

The practical test: if the cost disappears when you stop working on client projects, it's COGS. If it persists regardless of client volume, it's an operating expense.

Example: Hypothetical Dev Shop Cost Classification

Consider a hypothetical 12-person software studio billing $300K/month across six client engagements (illustrative figures):

• Contract developer engaged for a specific client build → COGS (5200)
• GitHub Enterprise license used across all client repos → COGS (5300)
• Figma license used by designers on client work → COGS (5300)
• Slack → Operating expense (6400)
• Outside legal counsel for contract review → Operating expense (6600)
• A contractor helping with internal marketing → Operating expense (6500)

Getting this split right matters for gross margin. According to dualentry.com, if your gross margin comes in below 65%, it's worth reviewing whether costs have been misclassified into COGS — or whether they should be there and your model carries higher-than-average services costs. The same logic applies in reverse: if gross margin looks unusually high, check whether subcontractor or hosting costs have been left out of COGS.

How to Enable Per-Project Reporting from the COA

Per-project reporting does not require a separate account for every project. That approach creates an unmanageable COA and breaks historical comparability as projects roll on and off.

The right approach: use accounting dimensions — called Classes in QuickBooks Online, Projects in Xero, or Jobs in some platforms — to tag transactions to specific engagements. As afternoon.co notes in their 2026 COA guide, if you need analysis, use dimensions rather than adding 50 accounts.

Setting Up Project Dimensions

1. Create a dimension for each active client engagement (e.g., "Project: Acme Redesign Q3")
2. Tag every COGS transaction — direct labor hours, subcontractor invoices, direct tooling — to the relevant project dimension
3. Tag revenue transactions to the same project dimension
4. Run a P&L by class/project to see revenue, COGS, and gross margin per engagement

This gives you project-level profitability without polluting the COA. The COA stays clean (5100, 5200, 5300); the dimension layer provides the per-project drill-down.

For studios comparing fixed-price versus time-and-materials profitability, our guide on fixed price vs. time and materials project margins covers how the billing model affects what you can see in project reporting.

What the Monthly Close Should Produce

A well-structured COA, combined with project dimensions, should let your monthly close produce:

• A P&L showing gross margin by revenue stream (project vs. retainer vs. product)
• A project-level profitability report showing margin per active engagement
• A balance sheet with deferred revenue clearly separated (current vs. long-term)
• A subcontractor spend summary for 1099 tracking

If your close isn't producing these outputs, the COA structure or the tagging discipline — or both — needs attention. Our month-end close calendar template shows the day-by-day sequence for getting to a clean close by day 10.

Capitalized Software Development Costs: Where They Live in the COA

If your studio builds internal products — a SaaS tool, a licensed platform, or internal infrastructure — some development costs may be capitalizable rather than expensed immediately. This is one of the most consequential accounting decisions a software studio makes.

Two standards govern this:

ASC 985-20 applies to software developed to be sold or licensed to others. Costs incurred after technological feasibility is established are capitalized; costs before that point are expensed as R&D. Per anchin.com's 2025 guidance, technological feasibility is achieved when all necessary planning, designing, coding, and testing are completed to ensure the product meets its design specifications.

ASC 350-40 applies to internal-use software — including cloud-hosted SaaS products maintained and hosted for customers. Development is broken into three stages: preliminary project, application development, and post-implementation. Only costs in the application development stage — application design and testing — are eligible for capitalization; preliminary and post-implementation costs are expensed.

Importantly, FASB tentatively agreed to significant updates to ASC 350-40 on June 18, 2024, removing the traditional three-stage model and allowing capitalization to begin once management authorizes and commits to project funding and determines the project is probable to complete. These proposed changes make it more difficult to meet the capitalization threshold, particularly for cloud-based solutions.

In the COA, capitalized development costs live in account 1300 (Capitalized Software Development) as an asset, with amortization flowing through account 1310 (Accumulated Amortization – Software). Development costs that don't meet the capitalization threshold are expensed through account 6800 (R&D – Expensed) in the period incurred.

For studios that are also venture-backed, the treatment of capitalized software affects your balance sheet and burn metrics. Our guide on burn efficiency metrics for startups covers how capitalization decisions flow through to the numbers investors watch.

How Many Accounts Does a Software Studio Actually Need?

The right number depends on stage, not preference for detail. According to dualentry.com's 2026 SaaS COA guide, a seed-stage company should have 30–40 accounts covering core assets, liabilities, equity, one or two revenue lines, and basic expense categories. At Series A ($1M–$5M ARR), expand to 50–70 with revenue breakouts and COGS detail. Series B+ companies typically need 80–100+ accounts, including departmental tracking and multi-entity sub-accounts.

For a software studio that is not venture-backed, the same logic applies: let complexity follow the business, not precede it. The table below maps those sourced benchmarks to studio revenue stages as a rough guide — treat the revenue ranges as illustrative, not as measured thresholds.

Account counts are sourced from dualentry.com's 2026 SaaS COA guide. Revenue stage labels are illustrative mappings to studio context.

Implementing or Restructuring Your COA

If you're setting up a new COA or cleaning up an existing one, accounting-wise.com recommends this sequence:

1. Prior period clean-up — Review historical transactions and ensure they're properly categorized
2. System setup — Configure your accounting software with the new COA structure
3. Data migration — Carefully transfer balances from old accounts to new ones
4. Documentation — Create clear guidelines for how transactions should be categorized
5. Training — Ensure your finance team understands the new structure and coding rules

The documentation step is the one most studios skip. Without written rules for how to classify subcontractors, tooling, and reimbursable expenses, the COA degrades within a few months as different people make different calls on the same transaction types.

For studios considering whether to handle this internally or bring in outside support, our guide on outsourced accounting for software and web studios covers what a structured accounting engagement typically includes and costs.

Frequently Asked Questions

How often should a software studio review its chart of accounts?

Review the COA at least annually — typically at year-end or before a new fiscal year. Also review when you add a new revenue stream, bring on a significant new type of subcontractor, or begin capitalizing development costs. Structural changes mid-year require careful balance migration to preserve historical comparability.

What is the difference between ASC 350-40 and ASC 985-20 for a software studio?

ASC 350-40 governs internal-use software, including cloud-hosted SaaS products. ASC 985-20 governs software built to sell or license to others. The capitalization triggers and eligible cost categories differ between the two standards. A studio may need to apply both if it builds products for clients and also maintains internal tools.

Should subcontractor 1099 costs always go in COGS?

Only if the subcontractor is engaged to deliver client work. A contractor doing internal marketing, HR, or admin work belongs in operating expenses. The test is whether the cost is directly tied to revenue delivery. Proper classification also simplifies 1099 preparation at year-end, since COGS and opex contractors are already separated.

Can I use one revenue account and just tag projects with classes?

You can, but it limits your P&L. Separate revenue accounts for fixed-price, T&M, retainer, and product revenue let you see margin by stream at the P&L level without running a custom report. Use both: revenue accounts for stream-level visibility, and project dimensions for engagement-level detail.

Laya provides this content for informational purposes only. This material does not constitute tax, legal, or accounting advice. Please consult your own tax, legal, and accounting advisors before engaging in any transaction.

If your studio's COA needs a rebuild — or your monthly close isn't producing project-level margin visibility — book an intro with Laya to see how we structure accounting for software development studios.