Why Sales and Finance Report Different Revenue

The sales system records a commitment at the moment somebody commits. The ledger records revenue when it has been earned under the policy the company reports on. Those are different events, on different dates, counted by different people for different purposes. A gap between them is the expected result, not a defect, and a month where the two agreed exactly would be the month to investigate.

So stop trying to close the gap and build a standing bridge across it instead. One schedule, rebuilt every month during the close, that starts at the sales figure and walks to the ledger figure in named categories. After a couple of months the arguing tends to stop, because it has been replaced by a list, and the list turns out to be more interesting than the argument was.

Two common fixes are worse than the problem, and both are popular.

Making sales report off the ledger. It ends the disagreement by destroying one of the two numbers. The sales figure carries forward-looking information the ledger structurally cannot: what has been committed but not yet delivered, which is the only early indication of the next two quarters anybody in the company has. Convert sales to reporting delivered revenue and they stop maintaining the pipeline properly within a quarter, because it no longer feeds anything anyone reads.

Declaring one system authoritative and telling everyone to use it. Which one should be authoritative for your company is not a question this article can answer, and it depends on how you sell and what you report under. What it can say is that whichever one you pick, the decision throws away whatever the other one was for, and companies make it in a meeting without noticing they have made it.

And a definitions appendix does not solve this one. That is worth stating plainly, because writing definitions down is the right answer to most reporting disagreements and it is an exercise worth doing on its own terms. It does not help here. Both departments can have a precise, written, agreed definition of what they are counting, both can apply theirs perfectly, and the two figures will still differ, because the definitions are describing different events rather than describing the same event differently.

The bridge

All figures below are illustrative. The categories are the transferable part.

Line	Amount
Sales system total for the month, as reported	1,482,000
Tax charged on invoices and included in the sales figure	nil
Booked in the month, not yet delivered at month end	(386,000)
Delivered this month against bookings from earlier months	271,000
Discounts and concessions agreed after the booking was recorded	(24,500)
Cancellations and deals that never started	(58,000)
Credit notes issued in the month against earlier revenue	(11,200)
Currency, where the two systems translate differently	9,300
Duplicate and test records in the sales system	(6,400)
Delivered and never invoiced	(14,800)
Revenue in the ledger with no record in the sales system	18,600
Revenue per the ledger	1,280,000

The tax row is nil in this illustration because the sales system in question records net of tax, and it stays on the bridge anyway. Keep every category as a permanent row even in the months it is nil, because a row showing nil proves the category was considered and an absent row proves nothing at all. This is the single cheapest discipline on the whole schedule and it is the one that stops the bridge quietly shrinking to the four categories somebody remembers.

The categories, and what each one actually is

Category	Why the gap exists	Which record settles it	Who owns the answer	Structural or defect
Booked, not yet delivered	The two systems are recording different events	The delivery or completion record	Operations	Structural
Delivered against earlier bookings	The same difference, running the other way	The delivery record	Operations	Structural
Tax on invoices	One system records what the customer pays, the other records what the company earns	The invoice	Finance	Structural
Post-booking discounts and concessions	The deal changed after it was written down and nobody went back	The signed change, or the credit note	The sales manager, not the salesperson	Structural, but the trend is a pricing signal
Cancellations and non-starts	The commitment stopped being one	The cancellation record, with a date	The sales manager	Structural, and the trend matters more than the month
Credit notes against earlier revenue	Something was wrong with what was delivered or what was billed	The credit note and its reason code	Operations	Defect above whatever level you agree is normal
Contracts recognised over more than one period	Policy. The ledger is following the revenue policy and the sales system is following the contract	The contract schedule and the written policy	Finance	Structural
Currency	Two systems, two conventions, sometimes two rate tables	The rate table named in the policy	Finance	Structural
Duplicates and test records	Nobody cleans the pipeline	The sales system	Whoever administers that system	Defect
Delivered and never invoiced	The work happened and no invoice was raised	The delivery record set against the invoice register	Finance and operations jointly	Defect, and the expensive one
Ledger revenue with no sales record	Renewals that bill automatically, small direct orders, work taken over the phone	The invoice register	Finance	Depends on whether it was supposed to be captured, which is a decision somebody has to make once

Split the bridge into two blocks and only measure one of them

This is the part that turns the schedule from an explanation into a tool.

The structural block will never be nil and should not be. Timing, tax presentation, policy and currency are permanent features of running two systems, and a company trying to drive them to zero is trying to make its sales team stop recording commitments.

The defect block should trend towards nil, and its trend is the only performance measure the bridge produces. Duplicates, uninvoiced deliveries and credit notes above the agreed level are all things that should be getting rarer. If they are not, the bridge is being produced and not read, which happens more often than it should because producing it feels like the work.

A bridge with nothing in the defect block is not a clean company. It is a bridge where everything has been classified as structural, usually because the person building it also owns one of the two systems.

The uninvoiced row is the one that justifies the whole exercise even in a company where nobody is arguing about revenue. The first time a company builds this bridge honestly, that row is rarely nil, and what sits in it is delivered work that nobody billed for, found by a schedule rather than by a customer. It is not unusual for that one row to pay for the reporting work that found it.

Who builds it

Not sales, and not the person who owns the ledger. The bridge is assembled by whoever builds the pack, during the close, from both systems, before the pack is issued.

The ownership rule is that each end is confirmed by the person accountable for it and neither of them owns the middle. Whoever runs the sales system confirms the top line is what their system says, without adjustment. The ledger figure is already reconciled as part of the close and needs no separate confirmation. The categories in between are finance’s work, and the point of that split is that nobody who is measured on either number gets to decide how the difference is described.

Two of the categories are the ones a person could use to move either figure, and both belong in the approval matrix rather than in the reporting process. Credit notes against prior revenue and discounts agreed after a booking was recorded should each require approval from somebody who is not measured on the number they affect. That control earns its place for its own reasons, and it is also what makes the bridge believable.

Timing matters too. Build it during the close, not afterwards. A bridge produced in response to an argument reads as a defence, whatever is in it, and the credibility does not fully recover.

When it will not close

There will be a residual. Carry it, name it, and age it. Never plug it, at any size, for the same reason nothing else in the close gets plugged.

If the residual is above the threshold two months running, stop adding categories. Adding a twelfth category to explain a residual is how a bridge becomes unreadable, and it usually means the aggregates being compared do not correspond in the first place. Pull twenty individual deals instead and trace each one from the sales record through to the ledger, by hand. That takes a morning and it either finds the systematic cause or it finds that one of the two systems is recording something nobody knew it was recording.

What we do not do

We do not adjust either system so the bridge closes. A sales record edited to agree with the ledger destroys the thing the sales record was for, and a ledger adjusted to agree with a pipeline is a much more serious problem than a bridge that will not tie.

We do not ask a sales team to report the ledger figure. If the owner wants one revenue number in the pack, the answer is the ledger figure with the bridge behind it and the committed backlog on its own line, which is what the standing pack carries anyway.

And we do not present the bridge in a meeting as evidence that a department was wrong. It exists to show that both numbers are explainable, which is a different message and the only one that keeps both systems being maintained honestly.