What's the difference between recognizing revenue over time vs. at a point in time?

The three criteria, precisely

RevenueHub's own explainer on over-time recognition quotes ASC 606-10-25-27's three criteria directly: the customer simultaneously receives and consumes the benefits as the entity performs; the entity's performance creates or enhances an asset that the customer controls as it's created or enhanced; or the entity's performance doesn't create an asset with an alternative use to the entity, and the entity has an enforceable right to payment for performance completed to date. Meeting any single one of the three is enough — they aren't cumulative requirements.

What happens when none of the three apply

If a performance obligation clears none of the three over-time criteria, it's recognized at a point in time — the single moment control of the good or service transfers to the customer, not when payment is received and not necessarily when the invoice is issued. A straightforward product sale, shipped and delivered, is the clearest example: nothing about that transaction meets simultaneous consumption, customer-controlled asset creation, or a no-alternative-use asset — control simply transfers on delivery.

Why this determination changes the whole recognition pattern, not just timing

This isn't a minor timing nuance — it determines whether revenue shows up as a single event or a stream. A custom-built asset with no resale value to anyone but this customer, and a contractual right to payment for work completed, meets criterion three and recognizes over the build period even before delivery. The same asset, if it had a ready resale market (an alternative use) and no enforceable interim payment right, would recognize entirely at the point of delivery instead — same underlying work, structurally different revenue pattern, because of how the contract and the asset's nature interact with these three tests.