Revenue Recognition

Cash arriving and a service actually being delivered are two different facts about the same contract. A dashboard that only tracks the first one can make a flat quarter look like a boom followed by a bust.

September 4, 2026 6 min read

A $120,000 annual contract is paid in full on January 3rd. The revenue dashboard lights up: January looks like the best month the company has ever had. February, with no new payment of that size, looks dead by comparison. The company kept the product running for the same customers both months, the same team did the same work, nothing about what the business actually delivered changed. The swing lived entirely in when the cash happened to arrive, not in anything that happened in the business during either month.

Cash arriving and a service being delivered are different facts

These are three separate events, not one event described three ways: cash lands in the bank on a specific date, an invoice gets posted to record the billing, and the service the contract promises gets delivered, continuously, across the year the contract covers. Crediting the full $120,000 to January conflates the first event with something it was never a fact about. The customer paid for twelve months of access to a running product. What was actually delivered in January was one month of that, the same amount as every other month in the contract, regardless of which month happened to hold the payment.

The distortion isn't a rounding error, it can flip the entire read on how a business is doing. A company that collects one large annual payment every January and nothing comparable the rest of the year will show a violent boom-and-bust pattern on a dashboard that books revenue on cash arrival, even if the underlying business is perfectly stable, the same handful of customers, renewing on the same terms, receiving the same service every month of the year. Whoever's reading that dashboard isn't just missing some precision. They're looking at a shape that isn't there.

Where this gets its name

Accounting has a formal answer to exactly this problem, and specific standards that govern it today. The FASB and the IASB developed converged rules together, issued in 2014 and phased in for public companies starting in 2018: ASC 606 under US GAAP and IFRS 15 internationally, two distinct standards built from the same core framework, not one rule with two names. Both share the same underlying idea: a company recognizes revenue as it satisfies the performance obligations it promised a customer, not when the cash for those obligations happens to arrive. For a subscription like the one above, where the obligation is to keep a service continuously available for a year, revenue can be recognized evenly across that year, one twelfth per month, specifically because an even split is what actually depicts a continuously delivered obligation. That's a real, worked-out rule, not an accounting trick to smooth a graph.

The idea that revenue and cash timing are different questions is older than either standard. In 1940, William Paton and A.C. Littleton published An Introduction to Corporate Accounting Standards (American Accounting Association, Monograph No. 3), one of the most influential early statements of what accountants call the matching principle: that a period's costs should be recognized against the revenue those costs helped produce, not against whichever period the cash for them happened to move in. Matching is about costs specifically, not revenue timing itself, but it's built on the same underlying insight ASC 606 and IFRS 15 formalize for revenue: a period's numbers are supposed to reflect what actually happened during it, and cash timing alone doesn't tell you that.

The honest limit: there's no single default pattern

This isn't a case for treating "one twelfth per month" as the automatic answer for any twelve-month contract. Straight-line recognition is the right pattern specifically when it faithfully represents how the obligation is actually being satisfied, a subscription where the customer has continuous access the whole time is the clean case for it. A contract built around discrete milestones, a project delivered in phases, work whose pace genuinely varies month to month, needs a different pattern, because an even split would misrepresent when the value was actually transferred just as much as booking it all in the first month would. Getting recognition right requires understanding the actual shape of what was promised and delivered. It isn't a formula that applies the same way to every contract just because the contract runs twelve months.

What doesn't require that judgment is the fact underneath it: that a contract is in force, that cash for it actually arrived, that an invoice was posted on a specific date. Each of those is checkable, single-valued, and doesn't depend on anyone's accounting policy. Deciding how the value behind those facts should be spread across the periods it covers is a separate, harder question, one that depends on the real shape of the obligation, not just its length.

Where this fits at Brief

Brief's own description of its agents draws a version of this same line explicitly: Revenue Agent is grouped with the agents that deal in observed fact, alongside Pipeline and Velocity, writing directly because there's no judgment involved in whether a subscription exists or not. This post isn't claiming Revenue Agent performs revenue recognition itself, deciding how a contract's value should be spread across the periods it covers, that's a separate, harder step layered on top of the underlying fact. What the observed-fact framing buys is the ground floor: a record of what actually happened, cash arrived, a contract exists, that any recognition judgment, whoever makes it, would have to start from.

Look at last month's revenue number again. How much of it reflects the service your team actually delivered that specific month, and how much of it is just the month a payment happened to land in?

Frequently asked questions

What is revenue recognition? The accounting question of which period a contract's revenue actually belongs to, based on when the company satisfies what it promised the customer, not simply when cash for the contract arrives. Under the current standards, ASC 606 in the US and IFRS 15 internationally, converged rules issued by the FASB and IASB, revenue is recognized as an entity satisfies its performance obligations.

Isn't this just the matching principle? Not exactly, though the two ideas are close relatives. The matching principle, formalized by Paton and Littleton in 1940, is specifically about aligning a period's costs with the revenue those costs helped produce. Revenue recognition is the separate question of which period the revenue itself belongs to in the first place. Today's operative rules for that question are ASC 606 and IFRS 15, not the older matching-principle literature.

Does a twelve-month contract always get recognized one twelfth per month? No. Straight-line recognition fits an obligation that's genuinely delivered evenly across the period, like continuous access to a running service. A contract built around distinct milestones or uneven delivery needs a pattern that actually reflects when the value transferred, which sometimes means an even split is wrong even for a twelve-month deal.

Does Revenue Agent handle revenue recognition automatically? This post makes no claim either way. What Brief documents Revenue Agent doing is narrower and doesn't need that answer: keeping one fact current, whether a subscription exists, the kind of fact that has exactly one right value and no accounting policy attached to it.