ASC 606, moved
out of the spreadsheet
and into the system.

01

The five steps, turned into rules

ASC 606 gives you five steps. Automating it means turning each step from a monthly judgement call into a rule the system applies on its own. Step one: find the contract. Decide when two contracts count as one. They usually do if they were signed at about the same time, with the same customer, negotiated as a package, or if the price of one depends on how you perform on the other. Step two: list what you promised. Each promise is separate if the customer can get value from it on its own, and if it is genuinely a distinct thing within that contract. In a software deal, that means deciding — and defending — whether the implementation work is separate from the platform, whether training is separate from implementation, and whether a hosted licence and its support are one promise or two.

Step three: work out the total price. Include the parts that move up and down. Include any interest-like element if the customer is paying much later than they receive. Step four: split that price across the promises. You split it in proportion to what each item would sell for on its own. Step five: count the revenue as you deliver each promise. Some promises are delivered over time. Some at a single moment. If it is over time, you need one stated way of measuring progress that you apply the same way every time, rather than picking a method contract by contract. Each of these decisions becomes a written policy an auditor can read. Then it is built into the system, so that the setup and the policy say the same thing. When they stop agreeing, that is a problem — and it is far easier to spot when both exist.

02

What each item is worth on its own, and where the discount lands

Deciding what each item would sell for on its own is where the judgement piles up. It is also the thing auditors push on hardest, because everything downstream moves when it moves. If you do sell an item on its own often enough, the price you charge is the answer. But that answer is a spread of prices, not a single number. So the method has to say which deals you looked at. How you grouped them — by customer segment, by country, by contract length, by volume, by sales channel. Which number you take from the spread, usually the middle one, or a range with a written rule for deals inside it and outside it. And how often you check the whole thing again. A range set two years ago and never revisited is not evidence. It is a habit.

Often you never sell the item on its own at all. Implementation work bundled into a platform deal is the normal example. Then you have to estimate the price. You can look at what the market would bear, or take your cost and add a margin. You can also take the total price and subtract the value of everything else, but only where the rule allows it — and it only allows it when the price of that item really does swing wildly. Reaching for that shortcut because it is convenient is the most common weakness we find.

Once you have those numbers, the split follows mechanically. And that is where the discount surfaces. A discount on the whole deal gets spread across every promise, in proportion to what each one is worth on its own. The only exception is when there is clear evidence the discount belongs to one item alone. Which means a discount the sales team thinks they gave on the licence turns up, in the accounts, as revenue sitting against support and not yet earned. That split is worked out once and stored against the contract. It gets recalculated only when the contract changes. It does not get rebuilt from scratch every period by a formula nobody has re-read.

03

Fees that move, and contract changes decided once

Fees that move up and down are more common than companies admit. Usage charges. Rebates that kick in at a volume. Discounts applied backwards once a threshold is hit. Credits when you miss a service level. Penalties. Rights of return. And any price you routinely knock off in practice, whether or not the contract mentions it. You estimate them two ways. Either take the average of the possible outcomes, or take the single most likely one, depending on which fits. Then you hold some back. You only count the amount you are confident you will not have to reverse later. The estimate gets reviewed every reporting period. That review is recorded in the system, with a name against it and a reason. It is not a conversation that happened.

Contract changes are the work nobody budgets for and everybody needs. The rule gives you three ways to treat one, and the whole difficulty is applying them consistently. If the customer buys extra things, and pays roughly what those things sell for on their own, it is a new contract. It sits alongside the old one and leaves it alone. If the change alters what is still to be delivered, and the price is not what those things sell for on their own, you look forward. You end the old contract, add the money not yet counted to the new money, and split that total across whatever is left to deliver. If the change affects something you are part-way through delivering and cannot separate out, you correct the past. You adjust the revenue you have already counted, in the period the change happens. Mid-term upgrades, contracts lined up to end on the same date, ramp-ups and early renewals all land in one of those three. We build the decision tree once, put it into the system, and let the system apply it. The same change, presented twice, produces the same accounting twice. Judgement still lives at the edges. It is now made once and written down, rather than re-argued every quarter under close pressure.

04

The schedule, and a trail that goes all the way back

The system generates the revenue schedules, the schedule of revenue you have billed but not yet earned, the split between what customers owe you and what you owe them, and the movement report the auditor asks for on the first morning. Generated from the contract records, not assembled from them by a person. That schedule of unearned revenue is the honest test of the whole build. It has to agree with the ledger. It has to agree with the billing. And it has to explain its own movements — opening balance, new amounts added, amounts released to revenue, contract changes, exchange rate effects, closing balance — with no fudge line to make it balance.

Underneath it sits the thing that matters most, and it is not a report. It is the trail. A revenue line traces back to the promise it belongs to. The promise traces to the split that sized it. The split traces to the pricing evidence behind it. That traces to the contract, and to any change made to the contract. And the contract traces to the order line that started it all. The trail runs the other way too. Give the system an order line, and it will show you every revenue line, every unearned balance and every future schedule that order line will produce. Being able to walk it in both directions is what turns a due-diligence question from a research project into a search. Everything else on this page is bookkeeping.