Skills / Reconciliation and close

Deferred Revenue Waterfall

A deferred revenue schedule is one of the few balance sheet accounts where the roll forward itself carries information: new billings in, recognized revenue out, and whatever's left is what's owed in future service. Rebuilt by hand every month from a contract export and last month's spreadsheet, it accumulates the same three problems a prepaid schedule does: a contract whose term already ended but still carries a balance, a beginning balance that doesn't agree to what actually closed last period, and a line recognizing on the wrong cadence against its own start date and term. None of those three show up by reading the recognized revenue line in the P&L. They show up in a rollforward and a recomputation, run against every contract line, not a sample of them.

What it does

This skill builds or verifies the deferred revenue waterfall from a contract or invoice export carrying each line's billed amount, service start date, and term (or milestone and usage data where recognition isn't straight-line), recomputes expected recognition through the period end, and ties the result to two places: the prior period as it actually closed, and the GL deferred revenue balance as it stands today. A waterfall only comes out clean when the rollforward foots, the beginning balance agrees to the prior period, the ending balance and current-period recognition agree to the GL, no line has recognized past its own billed amount, and the recomputation agrees to what the schedule currently shows. Anywhere those checks disagree, the gap becomes a proposed recognition entry with the reason stated on the line.

The one rule it can't skip

It never computes recognition timing for a milestone or usage-based contract. Those two methods aren't mechanically recognized by this skill at all; recognition timing on them is a professional call, and without the client's own stated ending deferred balance for that contract, it simply can't enter the tie-out. Only straight-line contracts get recomputed day by day from their own service start and end dates. The skill checks the math on what it's told to recompute; it never decides which method a contract should follow in the first place.

How the recomputation actually runs

Every straight-line contract recomputes day by day over its own service start and end dates, split into beginning deferred balance, additions invoiced this period, revenue recognized this period, and ending deferred balance. Milestone and usage contracts skip the recomputation entirely and carry their client-stated ending balance straight to the Judgment Items tab instead. Two defensive checks run underneath all of this: a contract can never be shown recognizing more than its beginning deferred balance plus this period's additions made available to recognize, and a repeated invoice number for the same customer is treated as a likely duplicate record, not two real invoices, and excluded rather than counted twice.

What it won't do

It won't decide when a milestone was achieved or how usage should be allocated for a usage-based contract; both carry the client's own stated balance through to the tie-out untouched. It won't judge whether a stale or unmatched balance is a timing issue or a genuine recognition error; it reports the dollar difference and the preparer confirms the cause. And it won't book anything: every recognition entry lands in a batch for a Controller to approve or reject line by line, the same discipline the prepaid-amortization skill applies to prepaid catch-up entries.

Inputs and output

InputsContract or invoice export with billed amount, service start date, term, and recognition pattern per line; milestone or usage data for lines that aren't straight-line; prior-period ending balance as actually closed; GL or trial balance figures for deferred revenue and recognized revenue
OutputA waterfall workpaper with new billings, recognized revenue, and ending balance by line, a GL tie-out, and a proposed recognition journal entry for every gap
Who it's forControllers at subscription and SaaS businesses who own the deferred revenue roll forward every close, and whoever reviews the proposed recognition entries before they post

Adopt's agents carry the deferred revenue schedule forward in the format your team already keeps it in, pull the contract or order form behind each line, and draft the recognition entry coded the way your chart of accounts already expects. Nothing posts until a reviewer approves it. Sign up free, or book a pilot to run it against the deferred revenue balance that never quite agrees to the GL.