What is revenue leakage? The gap between promised and collected revenue

At quarter close, a services team can show a signed scope, a delivery record, an invoice, and a bank receipt. The four amounts do not match. One person calls the difference a discount. Another calls it unbilled work. Finance calls it an overdue receivable. The report shows one shortfall, but it has not yet shown which boundary failed.

Revenue leakage is a candidate reconciliation gap between a declared net expected amount and a later invoiced or collected amount. It becomes actionable only when the line has a stable key, a defined service period, one currency rule, a reason, an owner, and a disposition. Until then, the gap is a signal to investigate, not proof that revenue was lost.

The useful question is therefore not “What percentage of revenue leaked?” It is: Which eligible line failed to travel from the declared commercial boundary to invoice and collection, and what evidence explains the difference?

What does revenue leakage measure?

The word leakage suggests a hole in a pipe. In a revenue system, the pipe is a chain of boundary objects. A quote can become a contract, a contract can create an entitlement to bill, an eligible delivery can create an invoice line, and an invoice can become a receipt. Each transition can be measured, but the amounts must not be collapsed before the transition is understood.

Stripe’s practitioner guide describes revenue leakage as expected income that a business fails to earn or receive. Its examples include uncollected billing, under-pricing, unrecovered costs, billing errors, pricing discrepancies, contract non-compliance, and work that was delivered but not fully billed (Stripe, 2024). It also describes comparing potential revenue based on contracts, price lists, and inventory with actual revenue received. This is useful source context, not an accounting standard or a universal leakage taxonomy.

For a commercial review, define the objects like this:

The word expected needs a rule. In one business it may mean the signed contract value. In another, it may mean billable usage or accepted milestones under a contract. A sales quote that was never approved is not automatically expected revenue. A requested feature that was never contracted is not an invoice shortfall. The article’s formula is only interpretable after the expected-value boundary is written down.

How is leakage different from price realization?

The neighboring terms often meet in the same review, but they do not answer the same question:

The price-realization article asks what price survives the transaction waterfall. A lower pocket price can be an approved commercial choice and therefore not leakage. T-08 asks a later question: if an eligible amount existed, where did it fail to become an invoice or a receipt?

The revenue-process article owns the cross-functional handoffs that can create the gap. The revenue event-schema article owns the records needed to reconstruct those transitions. A leakage ledger can point to a missing event, but it cannot recreate one that was never retained.

Which boundary should a team reconcile?

Start with a line population, not a total revenue number. A usable reconciliation card declares at least these fields:

These fields do not form a universal accounting chart. They make the selected control boundary reproducible. The event schema can supply the event primitives, while the discount article keeps persistent concession effects outside this reconciliation.

What does a revenue-leakage ledger look like?

The following ledger is synthetic. It uses one currency, one service period, and a collection cutoff of 31 October 2026. Net expected revenue is defined after approved credits and declared scope exclusions. Positive gaps indicate a shortfall at the named boundary. The rows do not represent a customer, contract, invoice, cash account, or company result.

The total is a reconciliation, not a conclusion. The five eligible lines contain 3,750 EUR of net expected revenue, 2,900 EUR invoiced, and 2,850 EUR collected by the cutoff. The arithmetic therefore gives:

• Pre-invoice candidate gap: 3,750 - 2,900 = 850 EUR.
• Post-invoice candidate gap: 2,900 - 2,850 = 50 EUR.
• Promised-to-collected candidate gap: 3,750 - 2,850 = 900 EUR.
• Candidate gap ratio against net expected revenue: 900 / 3,750 = 24.0%.

The 24.0% is not a leakage benchmark. It is a synthetic control signal whose interpretation depends on the row states. R-02 has a missing invoice line. R-03 is not yet due at the cutoff. R-04 already includes an approved credit and therefore does not create a false loss. R-05 has delivery evidence but no invoice and deserves a recoverability review. R-06 never enters the denominator because the request was not within the declared scope.

Which gaps are not confirmed leakage?

The classification step prevents a clean-looking percentage from becoming a false accusation:

This is why the article uses candidate leakage as a working state. A candidate gap can be worth investigating without being a confirmed loss. Confirmation requires evidence of entitlement or eligible delivery, a failed billing or collection obligation, a reason that survives review, and a disposition. Recoverability is a further question. A confirmed gap may be legally or commercially unrecoverable; a recoverable candidate may still be a timing state.

Can one leakage percentage identify the cause?

No. The same 900 EUR total can arise from a missing invoice line, a not-yet-due receipt, an approved credit that was misclassified, or a duplicated expected line. Those cases have different owners and different next events. Aggregating them early destroys the information needed to act.

If a team needs rates, name the population and numerator:

pre-invoice gap rate = positive net expected-to-invoiced gap / net expected revenue
post-invoice gap rate = positive invoiced-to-collected gap / invoiced revenue
candidate promised-to-collected rate = positive net expected-to-collected gap / net expected revenue
reconciliation coverage = lines with required fields / eligible lines × 100

These formulas are author conventions for a control review. Use signed values during reconciliation so over-invoicing, refunds, credits, and over-collection do not disappear behind a max(0, gap) function. If a dashboard displays only positive shortfalls, keep the signed residual and the reason-coded rows beside it.

Do not mix periods. A service-period expectation compared with a later invoice can be valid if the line key preserves the relationship. A booking-period expectation compared with a receipt-period amount needs an explicit lag rule. A foreign-currency invoice compared with a home-currency promise needs a conversion rule. A total that survives none of these tests is not a useful leakage measure.

What is revenue leakage not?

It is not automatically a discount. An approved price concession belongs to the price and expected-value rule if it was authorized inside the declared boundary. The price boundary is a separate question from this reconciliation.

It is not automatically revenue recognition. Recognition timing follows the applicable accounting policy and evidence. This article does not determine when a company may recognize revenue.

It is not automatically fraud. A mismatch can come from scope, timing, data, contract interpretation, delivery, billing, or collection. A reason code should preserve uncertainty until the evidence supports a stronger conclusion.

It is not profitability. The gap amount says nothing by itself about cost to serve, margin, cash cost, tax, or the economics of recovery.

It is not proof that a control change increases revenue. Stripe lists process, technology, contract, training, collection, and recovery responses in its practitioner guide, but the page does not provide an observed result for this synthetic ledger. A before-and-after change would still need a defined population, observation window, comparison, and outcome.

How can a team run the reconciliation?

Use the process below on one line population before building a company-wide dashboard:

1. Freeze the question. Write whether the review is promised-to-invoiced, invoiced-to-collected, or promised-to-collected. State the service period and collection cutoff.
2. Declare eligibility. Choose the contract, usage, delivery, or approval evidence that makes a line part of net expected revenue. Exclude unapproved requests explicitly.
3. Normalize the key. Join contract, delivery, invoice, and receipt records to one line key and one currency rule. Keep duplicates and unmatched rows visible.
4. Reconcile the amounts. Calculate the signed expected-to-invoice, invoice-to-cash, and expected-to-cash gaps. Preserve the residual instead of forcing it into a known cause.
5. Code and assign. Give each positive gap a reason, owner, status, next event, and review date. Separate timing, approved credit, scope, data, under-invoice, and collection states.
6. Close or escalate. Mark the row reconciled, excluded, corrected, timing, recoverability review, or confirmed loss. Record the evidence used and the boundary under which the disposition holds.

The output is not a single impressive percentage. It is a reviewable set of line objects that tells the next owner what to verify.

What can the evidence support?

The Stripe source supports a bounded practitioner description of expected income that was not earned or received, example billing and contract failure areas, an expected-versus-received comparison, and investigation categories from order through payment (Stripe, 2024). It does not support an accounting standard, a portable leakage rate, a product claim, a recovery benchmark, or a causal conclusion.

The ledger, formulas, values, reason codes, and review sequence are author synthesis. They make the measurement boundary explicit so a team can decide what to verify next. They do not show that any particular control will recover money.