Several Revenue Streams Make the Total Look Stronger Than the Business Underneath
Several Revenue Streams Make the Total Look Stronger Than the Business Underneath
The revenue total on the slide is correct. It ties to the ledger, it uses the same basis as the prior period, and it is higher than it was. None of that is the difficulty. The difficulty is that a total is the one number in the deck with no business model attached to it. Set the streams beside each other and the number acquires an operating story — one that may support the growth line, qualify it, or quietly contradict it.
There are two familiar ways to get this wrong. The first is to disaggregate opportunistically: keep the stream that grew, drop the one that did not, or compare a run-rate against recognized revenue because the resulting picture is easier to narrate. The second is to disaggregate exhaustively: eight lines, four metrics each, and still no answer to the question the reader brought. The useful ground is in between, and the order matters. Reconcile first. Then choose the differences worth showing. Then say only what the cost records can carry.
Reconcile the whole before interpreting its parts
A component view earns its place by describing the same business as the aggregate. That is an arithmetic claim before it is a narrative one: the components add to the reported total, for the same period, on the same currency basis, using the same definition of revenue. When they do not, you have not disaggregated the total — you have replaced it with a different, more flattering business and given the reader a table that looks auditable.
Three checks catch most of the trouble. Foot: do the parts sum to the reported whole, in the same period, with no reconciling item buried in a footnote. Basis: is every component measured the same way — all recognized revenue, or all run-rate, never a column of each side by side. Label: has any activity been reclassified between periods, and is that reclassification named where the reader can see it. An unlabelled reclassification is indistinguishable from growth or decline, and readers will assume the more exciting of the two.
The SEC's Financial Reporting Manual, Topic 9 — staff guidance whose page carries a December 11, 2017 date, with older subsection updates — discusses results of operations and liquidity in terms of significant revenue and cost components rather than a total that conceals unlike changes. Read that narrowly. It is dated staff guidance written for the review of public-company filings; it is not current law, not a duty imposed on private companies, and not an accounting policy. What it supports here is one instinct: when the parts move differently, the reader needs the parts. Everything below is our own construction.
Here is the exercise, in arbitrary monetary units. Period 1: software 80, services 20. Period 2: software 70, services 70. Directly attributed costs are stipulated at 24 and 16 in Period 1, then 21 and 56 in Period 2.
| Line | Software P1 | Software P2 | Services P1 | Services P2 | Total P1 | Total P2 |
|---|---|---|---|---|---|---|
| Recognized revenue | 80 | 70 | 20 | 70 | 100 | 140 |
| Directly attributed costs | 24 | 21 | 16 | 56 | 40 | 77 |
| Residual before shared costs | 56 | 49 | 4 | 14 | 60 | 63 |
The figures are invented, the units are arbitrary, and the cost boundaries have not had an accountant's review. What the table is for is the relationship between the rows.
Choose the differences that change the story
The total-only view of the same exercise is two numbers: 100, then 140. The reconciled view above contains four facts that the total does not.
Software revenue fell by 10. Services revenue rose by 50. The residual before shared costs — revenue less directly attributed costs — rose by 3, from 60 to 63. And the blended residual margin fell from 60 percent to 45 percent.
The last two are worth separating, because they are usually collapsed into one gloomy sentence. Software's residual before shared costs is 70 percent of its revenue in both periods (56 of 80, then 49 of 70). Services' is 20 percent in both (4 of 20, then 14 of 70). Neither stream's direct economics moved in this exercise. The blended ratio fell because the mix shifted toward the lower-margin activity. That is a composition effect, and it is a different piece of news from "our margins are eroding." A deck that reports only the blended number cannot tell the two apart.
Constant ratios are also a question, not a compliment. In a real set of books, a cost that tracks revenue at exactly the same percentage period after period invites a second look: is that genuinely direct attribution, or a formula applied by whoever maintains the schedule? In this exercise the proportionality is stipulated, so we take it as given. In your own deck, it is worth asking the finance owner why the ratio is so steady. Real cost curves are lumpy. People get hired ahead of revenue, or a delivery team hits its capacity and the next project waits.
Then there is the difference the table cannot supply: what each activity actually requires. Seventy units of software revenue and seventy units of services revenue occupy the same width on a bar chart and are not the same thing to produce. One may rest on an installed base and a renewal calendar; the other may rest on repeated delivery labor, implementation capacity, or a handful of customer relationships. The exercise stipulates none of that. You know it about your own business, and the table is only useful if you bring it.
A selection rule helps here: a difference belongs in the story if it changes what the reader expects next period, or changes how they read the number they already have. "Software declined while services grew" passes both tests. A segment catalogue does not, however complete it looks.
Recurrence deserves its own line, because it is the difference most often smuggled in by a label. Nothing on this table says whether the services revenue repeats. The labels are what smuggle it in: "software" reads as recurring and "services" reads as one-time, whether or not either is true. If the 70 in services is an implementation that ends, then 70 is not a new baseline, and the reader who assumed otherwise will build a forecast on it. If part of the services line is a maintenance or subscription stream that will bill again next period, the mix change means something different. The table cannot settle it; the contract terms can.
Explain economic relationships without invented allocation
Three kinds of cost are in play, and only one of them is on the table. Directly attributed costs attach to an activity on a documented basis. Allocated costs are shared costs pushed out to activities using some method. Shared unallocated costs sit above both and belong to the business as a whole.
The residual of 63 in Period 2 is the first kind only. It is not profit. It is what remains to cover everything the exercise has not supplied — and the gap between "residual before shared costs" and "net profit" is exactly where confident-sounding sentences go to die.
The comparison that is available is the change in coverage. Revenue rose by 40. The amount available before shared costs rose by 3, from 60 to 63. Coverage grew about 5 percent while the top line grew 40 percent. Whether that is enough depends on shared costs the exercise does not contain: if they held roughly flat, the added coverage is real but small; if they grew with the business, it may be close to nothing. Put the threshold plainly rather than guessing. Period 2 can absorb up to 63 of shared costs before the residual is exhausted, against 60 in Period 1. Headroom grew by three units.
Now the claims that people most want to make, and that the table cannot support. That services is now carrying the company. That software is subsidising services while services drains software. That the growth is low quality. Each of these is a statement about resources, cash, or dependency, and each needs its own evidence rather than a revenue share.
What would count? A documented allocation basis showing shared engineering time actually consumed by each activity. Contract or billing terms showing when each stream converts to cash — a business can look healthier on the top line and worse in the bank. A capacity constraint that binds both activities, which would be the strongest evidence of a genuine trade-off. Or a cost record built at the activity level in the first place, rather than reconstructed for a slide.
What does not count is the mix itself. Software's share of revenue fell from 80 percent to 50 percent. That is arithmetic. It is not evidence that services consumes more of anything shared, and it is not evidence that it consumes less.
There is a temptation here worth naming, because it is common and it is understandable: allocate the shared costs across the two streams so the deck can show a per-stream profit. If the allocation method is defensible and disclosed, fine — but keep the unallocated total visible beside it, and expect the finance owner to test it. If the method is invented to make the slide look complete, you have purchased a precise number at the cost of a true one. A better line on the slide is the honest one: shared costs are not allocated here, so neither stream's profitability is being asserted.
Compare the aggregate and component presentations
The total-only view shows a direction. It is efficient, it survives a five-second read, and it answers the question "is revenue growing" correctly. What it does not show: that the larger stream shrank while the smaller one grew more than threefold, that each stream's direct economics were steady, that the coverage below the top line grew far more slowly than revenue, or that the mix moved toward the activity with the thinner direct margin.
The reconciled component view shows all four and adds one important blank. It does not resolve missing cost records. It does not make a run-rate comparable to recognized revenue. It does not produce profit, and it does not make two unlike measures alike by putting them in the same row. Adding a chart to a number you cannot yet explain produces a decorated number.
Which form the component view takes is its own decision, and the deciding question is what the reader has to compare. Stacked bars make a composition shift visible at a glance — the software block shrinking while the services block swells does more work than a sentence. But stacked bars are poor at carrying a second measure, and this exercise has one: the residual before shared costs and its modest change. A small table, or bars for revenue with a residual row beneath, keeps both visible. If the only message were composition, the chart alone would be enough.
Keep the total. The component view is a companion, not a replacement, and the reader should be able to add the parts back to 140 on the page. A disaggregated view that cannot be reconciled to the headline is a second story competing with the first.
What the deck can say, and what it cannot yet
Three sentences, in descending order of support.
Revenue grew 40 percent, from 100 to 140, on a reconciled basis with the same period, currency and recognition definitions for both streams. That one is arithmetic.
Growth came from services, which rose from 20 to 70, while software revenue declined from 80 to 70. The amount available before shared costs rose from 60 to 63, and the blended residual margin fell from 60 percent to 45 percent entirely because of the mix shift. That one is arithmetic plus one honest reading of composition.
The mix change improved the business. That one is not available. It needs shared costs, delivery capacity, cash terms and customer dependency that the exercise does not supply, and the total never had to disclose. Composition can tell you the business changed. It cannot tell you whether the change is good. Hold the sentence until the records arrive, and put the question on the slide in its place.
Frequently asked questions
What three checks help confirm a component view still describes the same business as the reported total?
Foot: the parts sum to the reported whole in the same period, with no reconciling item buried in a footnote. Basis: every component is measured the same way—all recognized revenue or all run-rate, never a column of each side by side. Label: any reclassification between periods is named where the reader can see it, because an unlabelled reclassification is indistinguishable from growth or decline.
In the invented two-period example, what four facts does the reconciled view show that the total-only view does not?
Software revenue fell by 10, services revenue rose by 50, the residual before shared costs rose by 3 from 60 to 63, and the blended residual margin fell from 60 percent to 45 percent. The example also shows each stream's direct ratio stayed steady at 70 percent for software and 20 percent for services, so the blended fall comes from the mix shift.
Why can't the table support claims such as services is now carrying the company or software is subsidising services?
Those are statements about resources, cash, or dependency. The table contains recognized revenue and directly attributed costs only; it does not include shared costs, an allocation basis, capacity constraints, or cash terms. Evidence that would count includes a documented allocation basis showing shared engineering time consumed, contract or billing terms showing when each stream converts to cash, a capacity constraint binding both activities, or activity-level cost records.
What should be done if shared costs are allocated to show per-stream profit?
If the allocation method is defensible and disclosed, it can be used, but keep the unallocated total visible beside it and expect the finance owner to test it. If the method is invented to make the slide look complete, it purchases a precise number at the cost of a true one. A better line is that shared costs are not allocated here, so neither stream's profitability is being asserted.
What selection rule helps decide which differences between streams belong in the story?
A difference belongs if it changes what the reader expects next period, or changes how they read the number they already have. Software declined while services grew passes both tests. A segment catalogue does not, however complete it looks. Recurrence deserves its own line because labels like software and services can smuggle in assumptions; contract terms settle whether the revenue repeats.