The cover illustrates a hypothetical systems integration job, not a real contract or customer screen.
A systems integrator invoices THB 300,000 in advance and collects it. Does that mean it has THB 300,000 of revenue that month? The answer still depends on what the company has delivered to the customer. Neither the invoice nor the bank deposit settles it. I will use a hypothetical contract to show which terms determine the answer.
TFRS 15 bases revenue recognition on transfer of control of the promised goods or services. Its five steps identify the contract, identify performance obligations, determine the transaction price, allocate that price, and decide when the customer receives what was promised. Cash collection, billing, and revenue recognition can therefore occur at different times. [IFRS Foundation overview of IFRS 15]
This example assumes the company uses full TFRS and the contract is within TFRS 15. It does not conclude that every SME must use the same framework. A company using the standard for non-publicly accountable entities must consider its own framework first, rather than mixing rules from different frameworks only where doing so improves profit.
What is in the systems team's contract?
"Systems Ready" is a hypothetical systems integration (SI) company that modifies a factory's existing enterprise resource planning (ERP) system and provides stand-ready support afterward. Implementation runs in months 1 to 3. Support runs for 12 months, from month 4 through month 15. The contract price is THB 1,200,000. To focus first on revenue and payment timing, the example excludes resale of software licenses, VAT, withholding tax, price-adjustment bonuses, contract modifications, and credit losses.
Assumed standalone selling prices are THB 1,000,000 for implementation and THB 500,000 for support, totaling THB 1,500,000. These prices are inputs to the example, not market quotations from me or any provider.
Work through five steps, starting with the actual promises
| Step | Question to answer | Facts assumed in the example |
|---|---|---|
| 1 Identify the contract with the customer | Do the agreement, rights, and obligations meet the standard's contract criteria? | Assume the parties approve clear rights, work, and payment terms, and the contract criteria, including collectibility, are met. |
| 2 Identify performance obligations | What does the customer receive, and which promises are distinct? | One implementation obligation combining installation and customization, followed by one stand-ready support obligation. |
| 3 Determine the transaction price | What consideration does the company expect to be entitled to? | A fixed THB 1,200,000 under the example's exclusions, without taxes collected for the state. |
| 4 Allocate the price | What share of consideration belongs to each obligation? | Use the ratio of THB 1,000,000 to THB 500,000 in standalone selling prices. |
| 5 Recognize revenue as obligations are satisfied | When does control transfer, and how is progress measured? | Implementation meets an over-time criterion under the assumed control facts; stand-ready support is recognized as it is provided evenly over the support term. |
The table applies the five steps to my assumptions; it is not standard contract wording for every job. Steps 2 and 5 can change the answer substantially, so examine what is delivered before calculating a revenue schedule.
Two service names do not always mean two obligations
To separate a promise, consider whether the customer can benefit from it alone or with readily available resources, and whether it is distinct in the context of the contract. Separate pricing is not enough. If the provider must integrate highly interdependent work into one system, the promises may form one obligation. [TFRS 15 paragraphs 27 and 29]
In this example, analysis, installation, and customization are integrated into one working system and treated as a single implementation obligation. Each milestone is not a further obligation. Support begins after the system can be used. The customer can benefit from the delivered system without buying this team's ongoing support, and support does not reintegrate the implementation into a new combined output. We therefore assume support is distinct.
A real project with different facts needs reassessment. Individual deliverables may not be useful on their own, or customization may be highly integrated. Listing "installation," "training," and "support" on a proposal does not require the accounts to treat them as three obligations.
Allocate the discount on a consistent basis
| Obligation | Standalone selling price | Share | Allocated revenue |
|---|---|---|---|
| Implementation | 1,000,000 | 2/3 | 800,000 |
| 12 months of support | 500,000 | 1/3 | 400,000 |
| Total | 1,500,000 | 100% | 1,200,000 |
Implementation receives THB 1,200,000 × 1,000,000 ÷ 1,500,000 = 800,000. Support receives THB 400,000. Even if sales calls support "free," it may receive an allocation if it is a distinct obligation under the facts. Allocation by standalone selling price is not a substitution of each installment's invoice amount for revenue.
Implementation
THB 800,000
2/3 of the contract price
Support
THB 400,000
1/3 of the contract price
Why is this implementation recognized over time?
The example uses paragraph 35(b), concerning creation or enhancement of an asset the customer controls as work proceeds. It does not use that paragraph merely because the project lasts three months or is billed in three installments. If the over-time criteria are not met, consider the point at which control transfers instead. [TFRS 15 paragraph 35]
The assumed facts are that the customer controls the existing ERP it operates. The contract gives the customer rights to customization and usable portions as they are created. The customer directs their use and receives benefits while work is underway, and could appoint another contractor to continue if this contract ends. That differs from merely having an account on the provider's server or using a SaaS service whose main asset the vendor still controls.
Once over-time recognition applies, we still need a progress measure that reflects performance. Assume expected total implementation costs of THB 600,000. The THB 150,000 incurred in month one reflects work actually performed, or 25% of expected costs. Implementation revenue is therefore 25% of THB 800,000, or THB 200,000, not the THB 300,000 advance.
In month two, another THB 300,000 of cost is incurred. Cumulative cost is THB 450,000, or 75%, and cumulative revenue is THB 600,000. After THB 200,000 already recognized, month-two revenue is THB 400,000. The remaining work is completed in month three, adding THB 200,000 for a total of THB 800,000. This case assumes no abnormal waste or materials that would overstate progress before they reflect transfer, and no change in estimated total cost.
Support is provided evenly from months 4 through 15, so the example recognizes THB 400,000 ÷ 12, or approximately THB 33,333.33 a month. If the service pattern is uneven, use a method that reflects actual service rather than straight-line recognition merely because it is easy to calculate.
The two obligations produce revenue at different times
- Plum: implementation, THB 800,000, months 1 to 3
- Green: support, THB 400,000, months 4 to 15
- Horizontal axis: months since contract start
- Vertical axis: monthly revenue, THB millions
Does a 15-month contract need a financing adjustment?
Examine the period between transfer and the agreed payment for each portion, not the total contract term alone. In this hypothetical case, the payment terms are set at inception as shown below, and all amounts are expected to be collected when due.
| Month cash is received | Amount | What the installment pays for | Longest expected gap |
|---|---|---|---|
| 1 | 300,000 | THB 200,000 for month-one implementation and THB 100,000 for part of month two | 1 month |
| 4 | 500,000 | THB 300,000 for the rest of month-two implementation and THB 200,000 for month three | 2 months |
| 4 | 100,000 | Support in months 4 to 6 | 2 months |
| 16 | 300,000 | Support in months 7 to 15 | 9 months |
Because the expected gap between transfer and payment for each portion is no more than one year at contract inception, the example uses the practical expedient in paragraph 63 and makes no financing-component adjustment. This does not mean every systems integration contract can ignore financing. If a customer later pays after the agreed date, assess credit risk and its effects under the relevant accounting framework separately from the original payment-term analysis.
Points of care for SI firms and Odoo Partners
A company's own services and resale of another party's license or service can involve different roles. Examine whether the company controls the promised item before transfer or merely arranges for someone else to provide it. Being called a "partner," receiving the money, or issuing the invoice does not by itself settle whether revenue is gross or only a net fee. The same business may play different roles for different promises. [IFRS Interpretations Committee discussion of software resale]
That is why the THB 1.2 million case leaves license resale out. A contract with bonuses, performance discounts, scope changes, or cancellation rights needs further analysis of price and recognition. Do not reuse this table by changing only the project name while keeping the revenue numbers.
For a real project, I would first put the promises, rights to work in progress, standalone selling prices, progress evidence, and rights to bill in front of the accounting team together before setting a revenue schedule. Making those five sets of documents agree is more useful than choosing the invoice date alone as the recognition date.
Official sources were checked on October 18, 2026, against the standards applicable to the relevant reporting period. The amounts and contract rights are learning assumptions. An actual conclusion depends on the contract, the control facts, and the company's reporting framework.
