A customer pays upfront, but that payment is not automatically revenue. AASB 15 sets out when a business can record income, and incorrect timing distorts every report that follows.
Revenue recognition is the accounting process that determines when income appears in financial statements. AASB 15 recognises revenue once promised goods or services transfer to the customer.
Key Takeaways
Revenue is recognised when control transfers, not when payment arrives.
The five-step model guides revenue recognition under AASB 15.
Revenue may be recognised over time or at a point, depending on control transfer.
Connected accounting software improves revenue accuracy and audit trails.
What Is Revenue Recognition?
Revenue recognition determines when income from a customer contract appears in financial reports. The timing matters as much as the amount recorded.
Invoice, payment, and revenue recognition dates may differ. Each marks a separate event in the accounting process.
A customer may pay A$12,000 upfront for 12 months of support, but the full amount is not immediate revenue. About A$1,000 is recognised as each month of service is delivered.
Until the service begins, the payment remains a contract liability. It becomes revenue as the business fulfils its obligation.
How AASB 15 Governs Revenue Recognition in Australia

AASB 15 sets the Australian rules for recognising revenue from customer contracts. Two related questions often arise: how it maps to international standards and which transactions it covers.
1. What Is AASB 15?
The AASB 15 standard recognises revenue as promised goods or services transfer to a customer. The amount reflects the consideration the business expects to receive.
A customer contract falls within the recognition model when all five conditions below are met.
- Contract approval: The parties have approved the arrangement and intend to meet their obligations.
- Identifiable rights: Each party’s rights to the promised goods or services can be identified.
- Identifiable payment terms: The payment terms for those goods or services are clear.
- Commercial substance: The arrangement is expected to change the timing, risk, or amount of future cash flows.
- Probable collection: The customer is expected to have the ability and intention to pay the agreed consideration.
2. Transactions Covered by AASB 15
AASB 15 applies to revenue from ordinary customer contracts and determines when related amounts enter the chart of accounts . Common examples include:
- Product sales
- Subscription agreements
- Professional services
- Construction and project contracts
- Software licences
- Implementation and maintenance services
- Customer loyalty programs
- Warranties that provide additional services
- Contracts containing rebates, bonuses, refunds, or penalties
3. How AASB 15 Compares to IFRS 15 and ASC 606
AASB 15 incorporates IFRS 15, so Tier 1 for-profit entities complying with AASB 15 also comply with IFRS 15. Separate Australian provisions apply to some not-for-profit and public-sector arrangements.
ASC 606 follows a similar five-step model under US GAAP. Australian finance teams should use AASB 15 as their primary reporting reference.
The Five-Step Revenue Recognition Model
AASB 15 uses five connected steps to determine how much revenue a business records and when. The conclusion reached at each stage affects the next.
1. Identify the Contract
A contract may be written, verbal, or implied through customary business practices. It must create enforceable rights and obligations between the parties.
Related contracts may need to be combined when negotiated as one package or when their pricing and obligations depend on one another.
2. Identify the Performance Obligations
A performance obligation is a promise to transfer a distinct good or service. The customer must be able to benefit from it, and the promise must be separately identifiable.
A software contract may include a licence, implementation, migration, training, and support. These may be separate obligations unless implementation significantly modifies the product.
3. Determine the Transaction Price
The transaction price is the consideration the business expects to receive for transferring the promised goods or services. It may include:
- Fixed contract amounts
- Discounts and rebates
- Refunds
- Performance bonuses
- Service-level penalties
- Non-cash consideration
- A significant financing component
Variable consideration is limited when a significant revenue reversal remains possible. GST collected for the government is excluded from revenue under the AASB 15 measurement requirements .
4. Allocate the Transaction Price
For multiple performance obligations, the transaction price is generally allocated using relative stand-alone selling prices. This example contains three components:
| Performance obligation | Stand-alone selling price |
|---|---|
| Equipment | A$80,000 |
| Implementation | A$30,000 |
| Support | A$40,000 |
| Total | A$150,000 |
For a bundled price of A$120,000, a proportionate discount produces the allocation below. A different allocation needs evidence that the discount relates to one obligation.
| Performance obligation | Allocation |
|---|---|
| Equipment | A$64,000 |
| Implementation | A$24,000 |
| Support | A$32,000 |
| Total | A$120,000 |
5. Recognise Revenue When Obligations Are Satisfied
Revenue is recognised when, or as, control of a promised good or service transfers. Each performance obligation must be assessed separately.
One contract may therefore produce revenue at different times. Equipment may be recognised on delivery, implementation on acceptance, and support progressively over 12 months.
When Revenue Is Recognised: Over Time or at a Point
Once a performance obligation is identified, the business must decide whether to recognise revenue over time or at one point. That decision sets the reporting pattern.
1. Revenue Recognised Over Time
Revenue is recognised over time when at least one of the following conditions applies:
- Simultaneous benefit: The customer receives and consumes the benefits as the business performs.
- Customer-controlled asset: The business creates or enhances an asset the customer controls as it is created.
- No alternative use: The asset has no alternative use, and the business has an enforceable right to payment for work completed.
Recurring support, cleaning, and transaction processing often qualify. Payment timing does not decide the pattern, so a 50% invoice does not prove the obligation is 50% complete.
2. Revenue Recognised at a Point in Time
If an obligation does not qualify for over-time recognition, revenue is recorded when control transfers. Relevant indicators include:
- A present right to payment
- Transfer of legal title
- Transfer of physical possession
- Transfer of significant risks and rewards
- Customer acceptance
No single indicator decides the recognition date. Finance teams must assess the contract terms and supporting facts together.
3. Measuring Progress: Output vs Input Methods
Output methods track results transferred to the customer. Milestones should only be used when they reflect actual performance rather than billing dates.
- Units delivered
- Milestones achieved
- Work certified
Input methods track costs, labour, or machine hours. On an A$500,000 project, A$100,000 of A$400,000 expected costs equals 25% progress and A$125,000 revenue.
Percentage-of-completion remains a common term, but it does not replace AASB 15. Businesses must confirm the timing basis before choosing a progress measure.
A Worked Revenue Recognition Example With Journal Entries
This example shows how the five-step model becomes entries in the general ledger . It uses the A$120,000 allocation calculated above.
1. Initial Payment Journal Entry
The customer pays A$120,000 before any obligation is satisfied. No revenue is recorded because the provider still owes the equipment, implementation, and support.
| Account | Debit | Credit |
|---|---|---|
| Cash | A$120,000 | — |
| Contract liability | — | A$120,000 |
2. Product Delivery Journal Entry
When control of the equipment transfers, A$64,000 becomes revenue. Delivery records, title transfer, and customer acceptance should support the entry.
| Account | Debit | Credit |
|---|---|---|
| Contract liability | A$64,000 | — |
| Equipment revenue | — | A$64,000 |
3. Implementation Journal Entry
The business recognises A$24,000 when the distinct implementation service is completed and accepted. If it qualifies for over-time recognition, a suitable progress measure applies instead.
| Account | Debit | Credit |
|---|---|---|
| Contract liability | A$24,000 | — |
| Implementation revenue | — | A$24,000 |
4. Service Revenue Journal Entry
The A$32,000 support allocation is recognised across 12 months. This produces monthly revenue of A$2,666.67 as the support service is delivered.
| Account | Debit | Credit |
|---|---|---|
| Contract liability | A$2,666.67 | — |
| Support revenue | — | A$2,666.67 |
After the first month, approximately A$29,333.33 remains as a contract liability, assuming the equipment and implementation obligations are complete.
Contract Asset vs Receivable vs Contract Liability
Revenue, billing, and cash collection may occur at different times. AASB 15 uses contract balances to show where the business stands at each point.
| Balance | Meaning | Typical example |
|---|---|---|
| Accounts receivable | The right to payment is unconditional except for the passage of time | An invoice issued after delivery |
| Contract asset | Revenue is recognised, but payment remains conditional on further performance | Completed work billable after another milestone |
| Contract liability | Payment is received or due before the related obligation is satisfied | An annual subscription paid upfront |
| Accrued revenue | A broader term for revenue earned but not yet billed | May qualify as a contract asset under AASB 15 |
| Deferred revenue | A common term for payment received before revenue is earned | Normally presented as a contract liability |
A receivable depends only on the passage of time, while a contract asset still depends on further performance. Both should be reconciled with contracts, invoices, and delivery evidence.
Principal vs Agent: Should Revenue Be Reported Gross or Net?

A principal reports the full contract value as revenue, while an agent reports only its fee or commission. The distinction affects reported revenue without changing the transaction’s profit.
1. The control test
The key question is whether the business controls the good or service before it reaches the customer. Issuing invoices, collecting payments, negotiating with suppliers, signing the contract, or briefly holding title does not prove control.
2. Indicators of a principal and an agent
- Principal indicators: The business controls fulfilment, bears inventory risk, directs use, sets prices, or integrates third-party inputs.
- Agent indicators: Another party controls and supplies the item, while the business arranges the transaction for a fee without meaningful inventory risk.
3. Australian enforcement example: Data#3
Following an ASIC review, Data#3 changed certain indirect software sales from principal to agent accounting and began reporting only its net earnings.
The restatement reduced FY2023 revenue by A$1.67 billion, while profit before tax remained unchanged because the related expense was also removed. The change is detailed in the ASIC media release on Data#3.
"Reporting revenue gross when the business is really an agent doesn't just break a rule. It makes the business look bigger than it actually is."
Revenue Recognition Examples by Industry
Recognition timing depends on what the customer receives and when control transfers. Common industry treatments include:
- SaaS and subscriptions: Revenue is recognised over the service period. Setup fees are deferred unless they provide a distinct service.
- Construction and projects: Revenue may be recognised over time when the customer controls the work or the contractor has an enforceable right to payment.
- Professional services: Revenue is often recognised as work progresses. Fixed-price projects require reliable scope and cost estimates.
- Manufacturing and bundled contracts: Equipment, installation, training, and maintenance must be assessed as separate or combined obligations.
- Retail: Revenue is usually recognised at sale or delivery, with adjustments for returns, loyalty points, and gift cards.
Common Revenue Recognition Errors to Avoid
Errors often arise when accounting follows invoices or payments instead of the transfer of goods and services.
- Using the invoice date: An invoice does not prove that control has transferred.
- Recording advance payments as revenue: Payments received before performance usually create a contract liability.
- Combining distinct obligations: Products, implementation, and support may require separate allocation and timing.
- Following payment milestones: Billing terms do not necessarily reflect actual progress.
- Reporting agent transactions gross: An agent should recognise only its fee or commission.
Documentation, Disclosure, and Audit Controls
Reliable revenue recognition depends on evidence from sales, operations, and finance. Records should be available before the audit review begins.
1. Supporting contract documents
Keep signed contracts, amendments, statements of work, purchase orders, pricing approvals, and acceptance clauses together. Retain clear vendor invoice documentation when third parties are involved.
2. Approval, delivery, and control-transfer evidence
Delivery confirmations, customer acceptance, milestone approvals, timesheets, usage records, completion certificates, and activation records can support the recognition date.
Before reporting, finance teams should confirm the following:
- Reconciliations: Contract values align with allocated prices, revenue schedules, invoices, cash receipts, and contract balances.
- Judgements: Recognition timing, progress measures, variable consideration, and principal versus agent conclusions are documented.
- Disclosures: Revenue categories, contract balances, remaining obligations, and recognition methods follow the applicable AASB 15 disclosure requirements.
How Accounting Software Supports Revenue Recognition
Revenue recognition becomes harder when contracts, milestones, invoices, and journals sit in separate systems. Connected accounting software brings those records together.
- Centralised contract records: Contracts and performance obligations remain in one place instead of being scattered across emails and folders.
- Milestone and delivery tracking: Delivery records and customer acceptance can be linked directly to the relevant revenue schedule.
- Automated revenue schedules: Recurring amounts, such as the A$2,666.67 monthly support revenue above, can be calculated from the contract period.
- Journal entries and reversals: Revenue postings and corrections retain a clear audit trail without repeated manual entry.
- Reconciliation and audit trails: Contract balances, invoices, and journal entries remain connected, making discrepancies easier to investigate.
HashMicro Accounting Software connects invoices, transactions, journals, and reports. When choosing accounting software in Australia, finance teams should still review the recognition rules.
Connected records make each recognition decision easier to verify against its supporting contract, invoice, and journal data. The banner below shows how Hashy OS helps finance teams find this context and review revenue evidence more efficiently.
Conclusion
Revenue recognition under AASB 15 depends on when control of a promised good or service passes to the customer. The five-step model keeps each amount tied to actual performance.
Clear contracts, reliable schedules, and supporting evidence protect financial accuracy and audit readiness. Book a free consultation to improve your revenue reporting process.
Frequently Asked Questions About Revenue Recognition
Generally, no. The transaction price excludes amounts collected on behalf of third parties, such as GST. A GST-inclusive payment should be separated between revenue and GST payable.
A non-refundable upfront fee is not automatically recognised as revenue when charged. The business must determine whether the fee transfers a distinct good or service to the customer.
A warranty that only assures a product meets agreed specifications is not a separate performance obligation. A warranty that provides an additional service may be distinct and require part of the transaction price to be allocated separately.
A modification may be treated as a separate contract when it adds distinct goods or services priced at their stand-alone selling value. Otherwise, it is accounted for prospectively or through a cumulative catch-up adjustment.
Variable consideration is estimated using an expected-value or most-likely-amount approach. The amount included in the transaction price is constrained to reduce the risk of a significant future revenue reversal.







Limited to 100 registrants










