In the invoice-based measure used here, revenue is the sales total over a stated period, before costs. Calculate it by adding the invoice totals in scope.
Three illustrative invoices of $30, $20, and $50 produce $100 of revenue. That is the sum in the illustration above. It is not yet $100 of profit; the costs would like a word.
Start with the documents in scope
A useful revenue figure names the period, currency, and sales documents it includes. “Revenue: 100” is unfinished. “USD 100 from these three invoices during this period” is a calculation another person can reproduce.
The core measure takes invoice total as its input and sets aggregation to sum. The invoice total is an attribute of one invoice. Revenue is the measure across the invoices selected by the question.
Words such as sales, turnover, takings, and spend can point at this concept in context. From the seller's side it is revenue; grouped by the buyer, the same money is that buyer's spend. State whose perspective the report uses.
A sales total is not a bank receipt
An invoice requests payment; it does not prove that payment arrived. The invoice-based sales total in this model therefore does not establish cash collected. The invoice story follows that distinction, while payment obligations follows the allocations behind an unpaid balance. For a question about collected cash, use payment evidence and an explicit definition of that separate measure.
Revenue and profit need different labels
Illustrative calculation: $100 revenue − $65 costs = $35 profit.
This invoice-based revenue measure answers how much was recorded on the sales documents in scope. Profit introduces costs. A dataset that does not record costs cannot establish profit from its invoice totals alone.
Likewise, a catalogue price is what is asked for a unit, not evidence that anyone bought one. Summing a price list does not produce revenue. Use the amounts on the actual sales documents.
Keep currencies and periods compatible
Adding 50 USD to 50 EUR does not create a meaningful “100” in either currency. Convert using an explicit method and exchange-rate date, or report separate totals. A currency symbol without a currency definition is an unreliable shortcut.
Periods matter too. A year's revenue and a month's revenue are not directly comparable as if their windows matched. Refunds, taxes, discounts, and recognition policy need explicit handling when a dataset includes them; this basic concept does not silently supply an accounting policy.
How Chinook specialises the measure
Music sales extends revenue for the Chinook sample music store. It sums Invoice.Total. The meaning file interprets the unnamed sample currency as USD and says so. The store's prices of 0.99 and 1.99 do not establish a currency by themselves.
Summing invoice-line unit price times quantity over the same invoices gives the same amount according to the sample's meaning file. Catalogue list price is a separate attribute. A price that exists in the catalogue but never appears on an invoice is not a sale.
The measure can be grouped by billing country or invoice date. Grouping partitions the sum; it does not turn revenue into a ratio.
When revenue becomes a per-capita measure
Divide revenue by the population of the same place and the unit changes. USD becomes USD per person, or USD per million people after scaling. The resulting ratio is a separate per-capita measure and should not be summed across countries.
The Chinook worked example connects the complete calculation. The billing-country guide explains which geography belongs to the sale, and the country guide explains how its name matches a shared country value.
