Invoice

Origin & evolution

The invoice predates writing in any modern sense. The earliest surviving examples are Mesopotamian clay tablets in cuneiform, roughly 5,000 years old, recording quantities, parties, and prices of traded goods. Temple administrators kept them to track produce, which means the first invoices were instruments of accountability before they were instruments of trade.

The document's job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → stayed stable for millennia while its medium changed, from clay to papyrus to paper to structured electronic formats. The deeper change is recent and concerns not the document but the revenue behind it. In 2014 the FASB and IASB jointly issued ASC 606 and IFRS 15, converging the rules for recognising revenue from customer contracts. Their five-step model separates the act of billing from the act of earning. An invoice can demand a year's payment today while the revenue it represents is recognised month by month as the service is delivered.

That separation is what makes invoicing hard in subscription🔂SubscriptionSales & RevenueA recurring subscriptionView reference → software. The invoice tracks cash owed; revenue recognition tracks value delivered; tax tracks jurisdiction; and dunning tracks what happens when an invoice goes unpaid. Each runs on its own clock, and a billing system has to keep all four reconciled against a single document.

How it works in practice

A subscription company bills a customer 12,000 pounds for an annual plan on 1 January. The invoice states the line item, the period covered, the tax, and a due date of 31 January. Cash collection and revenue recognition now diverge: finance recognises 1,000 pounds of revenue each month under ASC 606, regardless of when the 12,000 is paid.

The customer's card fails on renewal the next year. The invoice enters dunning, an automated sequence of retries and reminders that runs for, say, 21 days before the subscription is suspended. Most involuntary churn hides here, in failed payments rather than cancelled intent, which is why the unpaid invoice is a product signal and not only a finance problem. A mid-cycle upgrade adds a further wrinkle: the system must issue a prorated invoice for the partial period, and a careless proration is the edge case that generates a support ticket🆘Support TicketCustomer SuccessCustomer support request or issueView reference → and a refund.

Tzuo and Weisert's *Subscribed* argues that subscription businesses must orient around the ongoing customer relationship🫶Customer RelationshipBusiness ModelA type of customer relationshipView reference → rather than the discrete transaction, and by that logic an unpaid invoice is not primarily a collections problem but evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → of a breakdown in that relationship — a view that reinforces treating failed payments as a product signal rather than a back-office exception.

Invoice vs. its neighbours

• Quote is a proposed price offered before a deal closes; the invoice is the demand for payment after delivery. A quote is non-binding and reversible; an invoice is a recorded liability. The graph keeps them distinct so a deal's offered terms can differ from what was ultimately billed.
• Receipt confirms that payment was made; the invoice requests it. One precedes payment, the other follows it, and conflating them loses the period when money is owed but not yet collected, which is exactly the period dunning manages.
• Subscription is the standing agreement; the invoice is one billing event it produces. The edge subscription_billed_via_invoiceSubscriptionbilled viaInvoicehierarchy holds the recurring one-to-many relationship between the contract and its many demands for payment.
• Revenue stream💵Revenue StreamBusiness ModelA source of revenueView reference → is the recognised flow over time; the invoice is a cash demand at a point in time. ASC 606 is the reason these are not the same number, and the reason a growing invoice total can sit alongside flat recognised revenue.

Murray's SaaS financial modeling work makes the same distinction operational: his standard model tracks cash receipts, deferred revenue, and recognised revenue as three separate lines, precisely because a fast-growing SaaS business can show a rising invoice run-rate while recognised revenue lags and deferred balances accumulate — the three numbers only converge at steady state.

In the graph

In the Unified Product Graph, an invoice sits in the monetisation region as the concrete billing artefact a subscription generates, linked by subscription_billed_via_invoiceSubscriptionbilled viaInvoicehierarchy. Holding the invoice as its own entity rather than a property of the subscription matters because the document carries facts the contract does not: a due date, a tax treatment, a payment state, a dunning history. Separating billing from earning in the graph lets a product team trace failed payments and proration errors back to the features⭐FeatureProduct SpecificationA product capability or featureView reference → and tiers that produced them, which is where most recurring-revenue leakage actually begins.