Software companies should recognize revenue when they deliver the promised software or service, not when they receive cash or send an invoice. For most SaaS contracts, that means spreading revenue over the contract term as customers use the product.
That sounds simple, but software contracts are rarely simple. One deal may include subscriptions, setup work, support, training, licenses, or third-party tools. Each part can change when revenue should be recognized.
Early or late revenue booking distorts margins, runway, board reports, and compliance. Strong bookkeeping and disciplined accounting and compliance support help teams avoid that.
TL;DR: Software companies should recognize revenue when each promised product or service is actually delivered, not when cash comes in or an invoice is sent. For most SaaS contracts, that means spreading revenue over the contract term, while setup work, licenses, support, and third-party tools may each need different treatment under Ind AS 115. Getting this right leads to cleaner reporting, better forecasts, and fewer surprises in audits or due diligence.
Why trust this guide: EaseUp brings 15+ years of experience and has helped 500+ businesses across sectors including IT & Software (SaaS), so the examples and checkpoints in this post are grounded in real finance and compliance work.
Disclaimer: This article provides general guidance based on Ind AS 115. Actual revenue recognition outcomes depend on the specific terms of each contract and may require professional judgment.
Software and SaaS companies rarely sell just one simple thing. A single contract may include a subscription, setup work, custom work, training, support, upgrades, or third-party tools. Each part can change when revenue should be recognized.
When the timing is wrong, common business problems follow:
Monthly revenue looks inflated or delayed.
Deferred revenue balances become unreliable.
Gross margin by product line becomes misleading.
Cash flow planning and runway forecasts lose accuracy.
Due diligence, audits, and board reporting become harder than they should be.
Ind AS 115 does not let companies book revenue just because they raised an invoice. Start by listing each promise in the contract. Then decide which promises stand alone. Assign value to each one. Book revenue when the company delivers that promise.
Read the contract line by line.
Split out each distinct promise made to the customer.
Recognize revenue only when that promise is actually delivered.
For most software companies, every contract should be reviewed through this lens:
Identify the contract with the customer. The agreement should be approved, commercially valid, and enforceable.
Identify the performance obligations. Separate the promises made to the customer, such as subscription access, implementation, support, or training.
Determine the transaction price. Include fixed consideration, variable consideration, discounts, credits, and refund exposure where relevant.
Allocate the transaction price. If there are multiple distinct obligations, allocate value to each based on standalone selling prices.
Recognize revenue when the obligation is satisfied. This may happen at a point in time or over time depending on the nature of the promise.
The framework looks simple on paper. In real life, the hard part is the contract. Terms may bundle services, add custom work, use different pricing models, or blur whether the company is acting for itself or on behalf of someone else.
Practitioner note: In EaseUp’s work with startups, tech companies, and SaaS businesses, the hardest revenue problems rarely come from the standard itself. They come from handoff gaps between the sales conversation, the signed contract, and the month-end close. When teams miss scope changes, acceptance milestones, support promises, or third-party terms, the accounting goes wrong later.
Revenue stream | Recognition basis | Common risk |
|---|---|---|
SaaS subscription | Over the subscription term | Booking annual billings as day-one revenue |
Setup/custom work | Over time if part of one combined promise | Treating setup fees as instant revenue |
Software license | Point in time or over time based on rights | Misclassifying right-to-use vs right-to-access |
Time & material services | As services are performed | Weak support for hours and milestones |
AMC / support | Over support period or service pattern | Ignoring uneven effort or obligations |
Third-party resale | Net if agent; gross if principal | Inflated topline revenue |
This guide is practical, but it does not replace a contract-by-contract review. One angle many software articles miss is the handoff between sales, delivery, and finance. Revenue errors often start when deal terms, scope changes, acceptance triggers, support promises, or reseller terms never make it into a clean monthly revenue schedule.
In a typical SaaS model, the customer pays to use the platform for a set period. Because the customer gets the benefit over time, revenue is usually recognized over the life of the contract.
Example: if a customer pays for an annual subscription upfront, the cash may be received on day one, but the revenue is usually recognized month by month over the contract period.
The most common mistake is confusing billing with revenue. Upfront billing improves cash flow, but it does not automatically create day-one revenue.
Upfront billing improves cash flow, not earned revenue.
Annual contracts are usually recognized over the service period.
The undelivered portion usually sits in deferred revenue.
Setup work creates mistakes for many software companies. If setup stands alone, the company can recognize revenue as it does the work. If the setup deeply changes the software and ties into the full customer promise, the company should group it with the main obligation and recognize revenue over time.
The key question is simple: can the customer use the software in a useful way without that setup work? If not, it may be wrong to treat them as separate promises.
In time-and-material contracts, companies usually recognize revenue as they do the work. They need clear proof. Timesheets, milestone records, approvals, and project tracking should show what the team delivered and when.
Weak documentation creates strong audit problems.
Maintenance and support contracts still need judgment. If the service stays steady across the full term, the company can recognize revenue evenly. If work varies by milestone, timing, or effort, the company should match revenue to that work pattern.
Use a straight-line pattern when support is steady across the full term.
Use more judgment when work is milestone-based or uneven by month.
Match revenue timing to the actual service pattern, not convenience.
In short, the accounting should follow the actual transfer of service, not convenience.
How software license revenue is recognized depends on what the customer actually gets:
Right to use: revenue is generally recognized when the license is made available, if the customer can use the intellectual property as it exists at that point.
Right to access: revenue is generally recognized over time when the customer continues to receive access to evolving software or hosted functionality.
This difference matters because many contracts use the word “license” loosely. In practice, the deal may work more like a service or subscription.
When a software company includes a third-party product or service in a client contract, it must decide its role in the deal. Ask one question first: does the company control that product or service before the customer gets it? Or does it only arrange the sale?
If the company controls the goods or services before transfer and carries primary responsibility, gross revenue may be appropriate.
If the company is arranging the sale between another vendor and the customer, only the net amount or margin may qualify as revenue.
Getting this wrong can artificially inflate topline revenue and distort margin reporting.
Advance payments are common in software contracts, especially with annual billing. But cash receipt does not equal earned revenue. If the company has not delivered the service yet, it should keep that amount as a liability until it meets the obligation.
This is a key point for founder-led finance teams: cash received is not the same as revenue earned.
If post-sales support sits inside the contract, teams need to review it carefully. When support stands as a separate promise, companies should spread revenue over the support period. Teams should also estimate delivery costs carefully so they do not overstate profit in the month they sign the contract.
Check whether support is a separate promise in the contract.
Spread revenue over the support period when that reflects the work delivered.
Estimate delivery costs carefully so profit is not overstated early.
If a contract becomes loss-making, companies may need to evaluate whether a provision is required under applicable standards such as Ind AS 37 relating to onerous contracts. This often comes up in underpriced fixed-fee implementation work, multi-year deals with rising delivery costs, and contracts signed during fast growth.
A customer pays upfront for 12 months of platform access. The company gets the cash right away, but delivers the service over 12 months. In most cases, revenue should be recognized over the contract term, not on the invoice date.
A customer buys a license, but the software does not work for them without major custom work and setup work. In that case, those promises may not be separate in practice. Revenue may need to be recognized over time as the combined work is delivered.
A company includes an outside software product in its client invoice. If it is only arranging the sale and does not control the product before transfer, revenue may be limited to the margin, not the full invoice amount.
Recognizing revenue when cash is received instead of when services are delivered.
Treating non-refundable setup fees as immediate revenue without assessing whether they relate to a future obligation.
Failing to separate or correctly combine multiple promises in one contract.
Ignoring contract modifications, credits, rebates, and refund exposure.
Recording third-party pass-through billing as gross revenue without principal-agent analysis.
Running month-end close without clear revenue schedules, contract summaries, and deferred revenue tracking.
Most articles stop at the accounting rule. The harder part is the operating handoff between sales, delivery, and finance. If that handoff is weak, month-end reporting breaks fast. Every software company should maintain the following:
A signed contract or approved order form for every customer.
A documented list of performance obligations for each major contract type.
A clear policy for subscription, implementation, license, support, and reseller revenue.
A deferred revenue schedule updated every month.
Support for standalone selling prices where bundles exist.
A review process for contract modifications and renewals.
Alignment between sales, delivery, finance, and leadership teams.
Experience note: In EaseUp’s startup and fundraising work, teams usually review revenue recognition alongside financial statements, forecasts, compliance, and the management narrative. A clean policy does more than support accounting. It strengthens diligence readiness, improves reporting quality, and helps management explain the numbers with confidence.
If you are tightening your close process or building finance systems for growth, start with the Accounting Guide for Startups. It is a useful next step for founders and finance teams that want cleaner reporting, better controls, and fewer surprises at diligence time.
If your contracts are getting more complex, this is usually the point where companies move beyond basic accounting and bring in Virtual CFO services to design policy, review contracts, strengthen monthly reporting, and improve decision-making.
Revenue recognition is not just an accounting task for software companies. It affects how clearly you see growth, margins, runway, pricing results, and investor readiness. As contracts become more bundled and customized, a clear policy becomes more important.
If your team is dealing with SaaS subscriptions, implementation fees, support obligations, reseller contracts, or complex founder reporting, now is the right time to tighten the process. You can book a meeting for a practical review of your revenue workflows, or contact our team if you want help strengthening your finance function before the next audit, board review, or fundraise.
Revenue recognition is the process of recording income when the promised software or service is delivered to the customer. Under Ind AS 115, the timing depends on when control transfers, not just when cash is collected or an invoice is raised.
Usually no. In most SaaS models, customers receive access over the contract period, so revenue is generally recognized over time rather than entirely on the billing date.
No. If setup is a distinct service, it may be recognized separately as delivered. If it is closely tied to the software and part of one combined promise, it may need to be recognized over time along with the main contract.
Deferred revenue is money collected before the company has fulfilled its obligation. Recognized revenue is the portion that has been earned after the promised software or service has been delivered.
The treatment depends on whether the company is acting as a principal or an agent. If it controls the product or service before transfer, gross treatment may apply. If it is only arranging the sale, revenue is often limited to the net margin.
Your trusted partner for all your Financial needs.
Finance Management
Strategic Services