Bookings, billings, revenue and cash are four numbers

A software company signs a ₹24 lakh annual contract in April, billed up front. The bank balance jumps. Somebody reports a record month. The following month the bank balance is flat and nobody can explain why revenue apparently collapsed.

Nothing collapsed. April earned ₹2 lakh of that contract and collected ₹24 lakh. The other ₹22 lakh is a liability: money taken for service not yet delivered. It will become revenue over the following eleven months and it was never April's to report.

Companies selling annual subscriptions run into this in their first year and keep running into it, because the four numbers involved all get called revenue in conversation. This template separates them, from one list of contracts, and checks that they reconcile.

Bookings

What a customer committed to, at the point of signing. A three-year contract is one booking at its full value. It is the largest of the four, the least useful on its own, and a sales measure rather than a financial one.

Billings

What you invoiced, whatever period it covers. This is what drives cash, a collection cycle later.

Revenue

What you earned by delivering. The only one of the four that belongs in the P&L, and the only one your auditor has an opinion about.

Deferred revenue

Billed and not yet earned. It sits on the balance sheet as a liability and unwinds into revenue as you deliver.

The identity that holds every month: opening deferred, plus what you billed, less what you earned, equals closing deferred. If that does not tie, something in the contract list is wrong, and the file says so.

Ten contracts across a financial year: annual subscriptions billed up front and monthly, two implementation fees, one training engagement and one two-year deal. Every figure is invented.

Six numbers, one year, and a spread from ₹24 lakh to ₹1.78 crore. Each one is correct and each answers a different question. A founder who reports the wrong one in a board meeting is not being careless, they are using a word that means four things.

The gap between closing ARR of ₹1.69 crore and recognised revenue of ₹1.11 crore is ₹58 lakh, and it is the single most common question in early-stage software diligence. It is growth and timing, because most of that ARR was signed during the year rather than at the start, with non-recurring fees pushing back the other way.

Each contract is marked recurring or not, and that single column decides what counts towards ARR.

Implementation, training, customisation and migration fees are genuine revenue. They appear in the P&L, they are in the billings, they help pay the team. They are not annual recurring revenue, because they happen once.

Counting them in ARR is the most routine adjustment a diligence team makes, and it is entirely avoidable. In the example, ₹9.3 lakh of the year's revenue is non-recurring, and none of it reaches the ARR row.

Founders tend to read deferred revenue as a worry, because it is a liability. Usually it is the opposite.

• ·A large and growing deferred balance means customers are paying for a year up front. They funded your working capital at no cost and committed to twelve months rather than one. That is a strength, and it is what makes annual billing worth a discount.
• ·A falling deferred balance while ARR rises means customers are moving from annual to monthly billing. Revenue is unaffected, cash is worse, and nothing in the ARR line will show it for another year. This is the pattern worth catching.
• ·A negative balance means you recognised more than you billed, which is unbilled revenue rather than deferred. The file flags it, and it usually means either the billing basis in the contract list is wrong or you invoice in arrears.

It is worth reporting the deferred balance in the monthly pack alongside revenue and ARR. Three numbers, and together they describe delivery, run rate and how much of next year your customers have already committed to.

Setting this up the first time takes an afternoon, and most of that is not data entry. It is four decisions that need an answer you will stick to, because changing any of them later makes the history meaningless.

1. 01What counts as recurring. The defensible line is contracted subscription fees that repeat without a new sale. Implementation, training, customisation, migration and anything sold once go on the other side, however reliably they recur in practice.
2. 02When a contract starts. The service start date rather than the signature date or the invoice date. These can be weeks apart, and using the wrong one shifts a month of revenue.
3. 03How to treat an upgrade mid-term. The cleaner approach is a second row for the increment, running from the upgrade date, which keeps the original contract intact and makes expansion visible. Amending the original row is faster and loses that information.
4. 04What happens on an early termination. Shorten the end date, which stops future recognition, and deal with any unwound deferred balance as its own adjustment rather than by deleting the row.

Write the four answers at the top of the Read me sheet, in your own words. The value of this file is a series that means the same thing in month eighteen as it did in month one, and the only thing that protects that is having written the definitions down before anyone was under pressure to hit a number.

1. 01Add any contract signed during the month as a new row. Dates, value, recurring or not, and the billing basis.
2. 02Amend a row where a contract changed: an upgrade, a downgrade, or an early termination shortening the end date.
3. 03Check the tie row on the Bridge sheet before reading anything else.
4. 04Take the month's revenue figure into the management accounts, and the closing deferred balance into the balance sheet.
5. 05Compare the ARR row against what your billing system reports. The two disagreeing is normally a definition problem, and it is better found here than in diligence.

Ten minutes once the contract list exists. The work is setting it up honestly the first time, and most of that is deciding what counts as recurring and writing the answer down.

• ·It is not a revenue recognition policy. How revenue should be recognised under the standards that apply to you, particularly where one contract bundles a licence with services or has performance obligations that complete at different times, is a question for your auditor. This is a management schedule built on a straight-line assumption.
• ·It recognises in whole months from the month a contract starts, with no pro-rata for a contract beginning on the 20th. Close enough for a management view and not for statutory accounts.
• ·It assumes monthly billing is in advance, so monthly contracts create no deferred balance. Billing in arrears produces unbilled revenue instead, which is the mirror image and is not modelled.
• ·It covers one financial year. Contracts running past March show only the part inside it, which is correct and is why the totals will not equal your contract values.
• ·It is not a billing system, and it does not produce invoices or track collections. The 13-week cash flow template handles the cash side.

What it does is separate four numbers that get used interchangeably, from one list you maintain anyway, and prove they reconcile. For a company selling annual contracts, that is usually the difference between a monthly pack people trust and one they argue about.