45When Is a Sale Truly Revenue? Delivery, Performance, Acceptance, and Recognition

Varza promise: clear enough for a first-time learner, exact enough for a professional conversation, and practical enough to support a real decision.

Why this chapter matters

This track follows value from a customer need to a commercial promise, delivery, invoice, collection, return, and long-term relationship. Sales are treated as both operational events and accounting claims, with evidence and timing controlling when numbers become reliable.

Central question: What must happen before a commercial promise becomes recognized revenue rather than an order, deposit, invoice, or unresolved claim?

Revenue is recognized when and as the entity satisfies identified performance obligations by transferring promised goods or services, measured under the applicable framework. Contract approval, rights, payment terms, transaction price, distinct promises, transfer, variable consideration, and collectability require disciplined analysis.

Varza approaches the subject from life to ledger and from ledger to decision. We begin with what actually happened, identify the rights, obligations, resources, timing, and uncertainty, and only then choose the correct term, calculation, document, or account. This order protects the learner from a common error: learning a label without understanding the economic reality that the label is supposed to describe.

Learning outcomes

• Define and distinguish revenue recognition in plain and professional language.
• Define and distinguish performance obligation in plain and professional language.
• Define and distinguish customer acceptance in plain and professional language.
• Define and distinguish contract in plain and professional language.
• Apply the concepts to a numerical case and explain the result rather than only calculate it.
• Identify evidence, workflow, controls, and Varza entities required for reliable use.
• Recognize when jurisdiction-specific or licensed professional advice is required.

The Varza mental model

A financial concept becomes decision-ready when six questions have answers: what, who, when, how much, based on what evidence, and under which assumption or rule. A seventh question—what should happen next—turns knowledge into management.

This chapter uses internationally recognized terminology, but it remains jurisdiction-neutral unless explicitly stated. Accounting standards, tax rules, contract law, consumer protection, labor requirements, and investment regulation can produce different legal outcomes in different countries. The global foundation gives the learner a stable map; local collections must add the binding rules.

Core concepts

1. Revenue recognition

Working definition. Revenue recognition is the controlled determination of when and at what amount revenue is recorded as promised goods or services are transferred to a customer.

Billing, collection, and recognition are related but distinct. The applicable framework and contract substance determine the accounting. The concept should be measured at the smallest level that still supports a real action.

Simple example. An annual prepayment is recognized over the service period rather than entirely on receipt.

Decision test. What is being measured, and what has been left outside the boundary? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

2. Performance obligation

Working definition. Performance obligation is a promise in a customer contract to transfer a distinct good or service, or a series treated as one obligation under the applicable standard.

Revenue analysis begins by identifying promises from the customer's perspective rather than by following invoice headings. The number alone is not enough; its definition determines whether comparisons are valid.

Simple example. A software contract may contain a license, implementation, and ongoing support as separate or combined obligations.

Decision test. When did the underlying right, obligation, benefit, or sacrifice arise? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

3. Customer acceptance

Working definition. Customer acceptance is evidence that a customer has acknowledged that specified delivery or performance conditions were satisfied.

Acceptance can be substantive, protective, explicit, deemed, or disputed depending on the contract and facts. It should not be assumed from silence without support. This is where operational activity and financial reporting meet.

Simple example. A milestone invoice becomes billable after the customer signs the acceptance certificate.

Decision test. Which document or observation would allow another person to verify it? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

4. Contract

Working definition. Contract is an enforceable agreement that creates rights and obligations between parties, subject to applicable law.

Operational and accounting systems should preserve the signed terms, amendments, performance evidence, consideration, dates, and responsible parties. In Varza language, the concept becomes useful when it changes a decision.

Simple example. A service contract defines scope, milestones, acceptance, price, payment terms, liability, and termination.

Decision test. How would a different assumption change the result? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

5. Revenue

Working definition. Revenue is income arising from an entity's ordinary activities, measured and recognized according to the applicable reporting framework and the substance of customer arrangements.

Revenue is not every cash receipt and not every invoice automatically. It depends on what was promised, what was transferred, and when the entity earned the right to consideration. The professional term matters because it prevents two different realities from being recorded as though they were the same.

Simple example. A customer deposit received before service may initially be a contract liability rather than revenue.

Decision test. Who can influence the result, and who only reports it? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

6. Delivery note

Working definition. Delivery note is evidence that specified goods were dispatched, delivered, or received, often capturing quantity, condition, date, location, and acknowledgment.

Delivery evidence supports custody transfer, inventory movement, billing, customer acceptance, and cut-off. A non-specialist can understand this by separating the object, the timing, and the consequence.

Simple example. The customer signs for ninety-eight units and records two damaged units.

Decision test. Does the item affect cash now, later, or not at all? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

7. Deferred revenue or contract liability

Working definition. Deferred revenue or contract liability is an obligation to transfer goods or services for which consideration has been received or become due before related revenue is recognized.

The label depends on framework and facts, but the core point is that cash or billing can precede performance. The concept should be measured at the smallest level that still supports a real action.

Simple example. An annual maintenance prepayment is recognized as the service is provided.

Decision test. What is being measured, and what has been left outside the boundary? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

8. Principal-versus-agent assessment

Working definition. Principal-versus-agent assessment is the evaluation of whether an entity controls a promised good or service before transfer or instead arranges for another party to provide it.

The conclusion affects gross versus net revenue presentation and requires analysis of control, responsibility, pricing, inventory risk, and other facts. The number alone is not enough; its definition determines whether comparisons are valid.

Simple example. A marketplace that only arranges a third-party service may recognize its fee rather than the customer's full payment.

Decision test. When did the underlying right, obligation, benefit, or sacrifice arise? A reliable answer should state the unit, date or period, scope, evidence, and uncertainty. When one of these is missing, the concept may still be useful for discussion, but it is not yet decision-ready information.

How the concepts connect

The concepts in this chapter are a system, not a vocabulary list. Revenue recognition, Performance obligation, Customer acceptance, Contract, Revenue, Delivery note, Deferred revenue or contract liability, and Principal-versus-agent assessment describe different parts of the same decision. Confusing them usually creates one of three failures: the wrong amount is measured, the right amount is assigned to the wrong period or person, or a correct report is used for a decision it was never designed to support.

A useful analysis therefore preserves both classification and relationship. Classification tells us what an item is. Relationship tells us what caused it, what it affects, and what could change it. Varza should store both. A report that shows only totals may be suitable for orientation; a controlled decision requires traceability to the underlying relationships.

Formulas and quantitative relationships

Allocated transaction price

Allocated amount to obligation = Total allocable transaction price × Relative standalone selling price of obligation ÷ Total standalone selling prices

A relative selling-price method commonly allocates consideration among performance obligations.

Boundary: Use the applicable standard's requirements, estimates, discounts, and variable-consideration guidance.

Worked case — A bundle is not one moment of revenue

A customer pays CU 24,000 for equipment, installation, and twelve months of support. Standalone selling prices are CU 20,000, CU 4,000, and CU 6,000 respectively.

Item	Amount or observation
Contract price	CU 24,000
Total standalone prices	CU 30,000
Equipment allocation	24,000 × 20/30 = CU 16,000
Installation allocation	24,000 × 4/30 = CU 3,200
Support allocation	24,000 × 6/30 = CU 4,800

Calculation and reasoning

1. Assess whether the three promises are distinct under the contract facts.
2. If the relative standalone method applies, allocate CU 16,000, CU 3,200, and CU 4,800.
3. Recognize equipment and installation amounts when their respective obligations are satisfied.
4. Recognize support over the twelve-month service pattern, not entirely on cash receipt.
5. Update for modifications, refund rights, or variable consideration under the applicable rules.

What the result means

Billing and cash can happen at signing, while revenue follows the pattern of transferred value. The allocation keeps the discounted bundle from hiding the remaining service obligation.

The case is deliberately compact. In practice, Varza would preserve the supporting documents, currency, dates, counterparty, project or cost center, approvals, and links to the resulting records. The lesson is not merely to reach a number; it is to make the path to that number reviewable.

Practical workflow

1. Define the decision, responsible person, economic unit, period, and acceptable uncertainty. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
2. Confirm an enforceable customer contract and each party's rights and terms. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
3. Identify distinct promised goods and services. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
4. Determine and allocate the transaction price, including variable or financing effects where relevant. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
5. Recognize revenue when control or service transfers and retain delivery, progress, or acceptance evidence. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
6. Reconcile the result to source evidence and investigate exceptions rather than forcing agreement. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
7. Approve the decision or record at the authority level required by value, risk, and legal consequence. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.
8. Monitor the outcome, compare it with the original assumption, and retain the learning for the next cycle. Define the owner, required evidence, status, date, and exception route. Do not allow the next step to erase the record of the previous one.

How this concept should appear in Varza

The minimum Varza data model for this chapter includes customer_contract, performance_obligation, transaction_price, allocation, transfer_evidence, acceptance, revenue_schedule, contract_asset, contract_liability. These names are not merely interface labels. Each entity should have a stable identifier, status history, responsible owner, applicable currency or unit, effective dates, evidence links, and access controls.

A useful Varza screen should answer four questions without forcing the user to reconstruct the story manually:

1. What happened or is expected to happen? Show the operational event, obligation, or decision in plain language.
2. What changed financially? Show cash, asset, liability, equity, income, expense, commitment, or risk effects.
3. Why should the user trust it? Show source documents, calculations, approvals, and revision history.
4. What requires attention now? Show exceptions, due dates, thresholds, and the next responsible action.

The Varza design principles most relevant here are:

• Prefer a traceable estimate with stated assumptions to an impressive number with hidden assumptions.
• Use automation to strengthen evidence and consistency, never to remove accountability.
• Turn information into a decision, a control, or a question; otherwise it is only decoration.

Varza AI may explain, classify, compare, simulate, and prepare a proposed action. It should not silently change a legal record, post a material transaction, close a period, release a payment, or make an investment decision on the user’s behalf. Material actions require visible evidence, permissions, validation rules, and an accountable human approval path.

Controls and professional boundaries

1. Specialist review of unusual, bundled, variable, long-term, or intermediary contracts. The control should be proportionate to value and risk, documented clearly, and tested often enough to detect failure before the consequence becomes irreversible.
2. No revenue journal triggered solely by invoice creation. The control should be proportionate to value and risk, documented clearly, and tested often enough to detect failure before the consequence becomes irreversible.
3. Contract modification and change-order control. The control should be proportionate to value and risk, documented clearly, and tested often enough to detect failure before the consequence becomes irreversible.
4. Stable definitions, versioned assumptions, and consistent units across plans, records, and reports. The control should be proportionate to value and risk, documented clearly, and tested often enough to detect failure before the consequence becomes irreversible.
5. Traceability from every material total to evidence, calculation, owner, and change history. The control should be proportionate to value and risk, documented clearly, and tested often enough to detect failure before the consequence becomes irreversible.
6. Access and approval rights aligned with responsibility and the possible consequence of error or misuse. The control should be proportionate to value and risk, documented clearly, and tested often enough to detect failure before the consequence becomes irreversible.

A control is effective only when it operates in practice. A policy that everyone can bypass is a statement of hope, not a control. Likewise, a control that blocks ordinary work without distinguishing low-risk and high-risk cases encourages hidden workarounds.

Common mistakes and better responses

Mistake 1: Recognizing revenue when a purchase order is received

Better response. Reconstruct the underlying event, state the definition being used, obtain the missing evidence, and recalculate before making a decision. Correct the process as well as the current number so the same error does not become routine.

Mistake 2: Using cash collection as the only performance test

Better response. Reconstruct the underlying event, state the definition being used, obtain the missing evidence, and recalculate before making a decision. Correct the process as well as the current number so the same error does not become routine.

Mistake 3: Ignoring unperformed implementation or support bundled with a product

Better response. Reconstruct the underlying event, state the definition being used, obtain the missing evidence, and recalculate before making a decision. Correct the process as well as the current number so the same error does not become routine.

Mistake 4: Recording gross revenue when the entity only arranges another party's service

Better response. Reconstruct the underlying event, state the definition being used, obtain the missing evidence, and recalculate before making a decision. Correct the process as well as the current number so the same error does not become routine.

Mistake 5: Using a technically correct number outside the period, entity, currency, or decision boundary for which it was calculated

Better response. Reconstruct the underlying event, state the definition being used, obtain the missing evidence, and recalculate before making a decision. Correct the process as well as the current number so the same error does not become routine.

Mistake 6: Accepting an automated result without reviewing the evidence, assumptions, exceptions, and required professional judgment

Better response. Reconstruct the underlying event, state the definition being used, obtain the missing evidence, and recalculate before making a decision. Correct the process as well as the current number so the same error does not become routine.

Decision checklist

• Can I explain revenue recognition in plain language and in professional terms?
• Can I explain performance obligation in plain language and in professional terms?
• Can I explain customer acceptance in plain language and in professional terms?
• Can I explain contract in plain language and in professional terms?
• Have I stated the entity, currency or unit, date or period, and decision boundary?
• Can another person reproduce the number from retained evidence?
• Have I separated actuals, estimates, commitments, and scenarios?
• Have I tested timing, liquidity, risk, and at least one adverse outcome?
• Is the required approval proportional to the possible loss or legal consequence?
• Does the final output lead to a specific action, owner, and review date?

Practice lab

1. Explain it. Describe Revenue recognition to a person who has never studied finance. Then add the professional definition and identify one boundary your simple explanation omitted.
2. Classify it. Create five examples from your household or a small business and classify each using Performance obligation. State any assumptions.
3. Calculate it. Rebuild the worked case with amounts 20% higher. Identify which conclusions change and which remain structurally true.
4. Challenge it. Describe a situation in which Customer acceptance could be measured correctly but still lead to a poor decision because timing, risk, or incentives were ignored.
5. Design it. Sketch a Varza screen or report for this chapter. Include fields, evidence links, status, owner, exceptions, and one AI-assisted action.

Answer guidance

A strong answer uses consistent definitions, reveals assumptions, distinguishes fact from estimate, and connects the result to an action. More than one conclusion may be reasonable when the learner clearly states the decision objective and uncertainty. The worked-case recalculation should preserve the method even when the numbers change.

Varza AI knowledge capsule

This capsule is intentionally explicit so that a retrieval system can distinguish canonical teaching points from examples and commentary.

{
  "chapter_id": "VARZA-F100-045",
  "canonical_topics": [
    "Revenue recognition",
    "Performance obligation",
    "Customer acceptance",
    "Contract",
    "Revenue",
    "Delivery note",
    "Deferred revenue or contract liability",
    "Principal-versus-agent assessment"
  ],
  "facts": [
    "Revenue recognition: the controlled determination of when and at what amount revenue is recorded as promised goods or services are transferred to a customer.",
    "Performance obligation: a promise in a customer contract to transfer a distinct good or service, or a series treated as one obligation under the applicable standard.",
    "Customer acceptance: evidence that a customer has acknowledged that specified delivery or performance conditions were satisfied.",
    "Contract: an enforceable agreement that creates rights and obligations between parties, subject to applicable law.",
    "Revenue: income arising from an entity's ordinary activities, measured and recognized according to the applicable reporting framework and the substance of customer arrangements.",
    "Delivery note: evidence that specified goods were dispatched, delivered, or received, often capturing quantity, condition, date, location, and acknowledgment.",
    "Deferred revenue or contract liability: an obligation to transfer goods or services for which consideration has been received or become due before related revenue is recognized.",
    "Principal-versus-agent assessment: the evaluation of whether an entity controls a promised good or service before transfer or instead arranges for another party to provide it."
  ],
  "formula_names": [
    "Allocated transaction price"
  ],
  "jurisdiction_scope": "global-foundation",
  "required_answer_qualifiers": [
    "entity",
    "date_or_period",
    "currency_or_unit",
    "source_or_assumption",
    "jurisdiction_when_relevant"
  ],
  "human_approval_required_for": [
    "posting_material_transactions",
    "closing_periods",
    "changing_master_data",
    "releasing_payments",
    "submitting_filings",
    "individual_investment_execution"
  ],
  "source_ids": [
    "S101",
    "S114",
    "S117",
    "S118"
  ],
  "edition": "2026.1",
  "review_date": "2026-08-31"
}

Suggested questions for Varza AI

• Explain this chapter using an example from a household, a shop, and a service business.
• Ask me five diagnostic questions before applying this concept to my situation.
• Show the difference between cash effect, accounting effect, and decision effect.
• Recalculate the worked case using my currency and assumptions, but preserve the original definitions.
• Identify which parts require local accounting, tax, legal, labor, or investment rules.

Sources and standards horizon

This chapter is original Varza educational content. It paraphrases and synthesizes concepts; it does not reproduce a standard or third-party article. The following sources were used to establish terminology, scope, and current professional context:

• S101 — IFRS Foundation, Conceptual Framework for Financial Reporting. 2018; accessed 2026-08-31. Objectives, qualitative characteristics and elements of financial reporting. Source: https://www.ifrs.org/issued-standards/list-of-standards/conceptual-framework/
• S114 — IFRS Foundation, IFRS 15 Revenue from Contracts with Customers. 2026 standards set. Principles for recognizing revenue from customer contracts. Source: https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/
• S117 — IFRS Foundation, IFRS for SMEs Accounting Standard. third edition 2025; effective 2027. Simplified global reporting framework for eligible small and medium-sized entities. Source: https://www.ifrs.org/issued-standards/ifrs-for-smes/
• S118 — IFRS Foundation, IFRS Accounting Standards—Required 2026. 2026-01-29. Standards and amendments effective from 1 January 2026. Source: https://www.ifrs.org/news-and-events/news/2026/01/now-available-ifrs-accounting-standards-required-2026-two-editions/

Standards horizon. Reviewed through 2026-08-31. IFRS 18 and the third edition of the IFRS for SMEs Accounting Standard are included as transition knowledge where relevant; both have mandatory effective dates beginning in 2027, with early application permitted under their respective requirements.

Jurisdiction note. Global educational foundation; local law, tax, reporting, consumer-protection, licensing, and professional requirements must be checked separately.

Professional-use note. This learning material does not replace advice from a qualified accountant, lawyer, tax adviser, licensed investment professional, or other regulated specialist who has reviewed the user’s facts and jurisdiction.