Revenue recognition: automating the schedule, not the judgment

The schedule is arithmetic, and the judgment is not

Automating revenue recognition for a subscription business is two projects sold as one, and only the first is a software project. Once somebody has decided what a contract promises, over what period and for what amount, turning that into period-by-period entries and the deferred balance that goes with them is arithmetic: repetitive, checkable, and already built into products most companies in this position already pay for. The second project is the decision that populates the schedule, and that is a set of accounting judgments the accounts themselves have to disclose as judgments. This page rules on the first and refuses the second. It does not say when a subscription’s revenue should be recognised, how a price should be divided between the things a contract promises, or what any standard requires of a particular arrangement. Those questions belong to the people who sign the accounts and to the auditor who tests them, and a studio offering a view on them would be selling advice it has no standing to give. The question a studio can answer is narrower and more useful: which parts of this process a machine can run unattended, which parts it can only record, and what the second group costs when it is treated as the first. Foxnut Studios builds systems that end up inside an audit, which is a reason to be plain about the handover method behind an auditable system before agreeing to build one.

The reason the question is worth asking at all is that a subscription book generates schedule lines faster than it generates customers. One annual contract on monthly recognition is twelve rows, a mid-term upgrade turns a settled schedule into an unsettled one, and none of that work is visible until a period has to close. What follows is an argument about where in that pipeline a machine earns its place, and about the one event that decides it.

Billing and recognition are two different calendars

The single most useful thing to establish before anyone specifies a system is that invoicing and recognition are separate calendars that happen to share a contract. An invoice is a demand for cash on the terms the contract sets. Recognition is the reporting of revenue as the entity satisfies what it promised. They coincide only by accident, and in a subscription business they are designed not to coincide: an annual invoice raised up front is one billing event and twelve recognition events, and usage-based pricing inverts it, because the amount is not knowable until the period it relates to has already run.

Usage-based billing is worth naming precisely because it is the arrangement that most often breaks an automation that was sized for subscriptions. A fixed subscription can be scheduled forward from the day it is signed. A consumption charge cannot: the meter has to close before the amount exists, so the schedule for that portion is a placeholder until a measurement arrives, and the measurement comes from a metering system rather than from the contract. Where a contract carries both, the same customer produces one stream a machine can project and another it can only receive.

That split is what makes the billing system a poor master record for recognition. It knows what was invoiced. It does not necessarily know what was promised, over what period, with which options, or what changed in March. Every system built on the assumption that those are the same fact fails at the same point, and the point has a name.

Four arrangements, and what each one changes

The four arrangements below are not four levels of maturity. They differ in where the schedule is decided and in what happens to it when the contract changes, and those are separate questions from how much of the keying is automated.

The third row is the one worth reading twice. In every arrangement the steady state is easy and the change is hard, and the arrangements differ mainly in whether a change is a first-class event or an edit somebody makes.

When a spreadsheet still wins

It wins where the book is small, the terms are uniform and nothing is amended mid-term. At that size the schedule is one formula copied down, the whole close cost is an afternoon, and a system would be recomputing an answer nobody was getting wrong. The failure mode is not slowness: it is that the logic lives in one person’s file and their memory of why column G has an override in it. The upgrade worth making at that size is a written statement of how a contract becomes a schedule, not software.

When the accounting system’s own deferral module wins

It wins in most cases above that size, and it is under-configured far more often than it is outgrown. The capability is licensed, documented and old enough to have been through a product generation already: one major vendor deprecated its earlier general revenue recognition module in January 2024 and points new users at a subscription-billing product built from three modules covering recurring contract billing, revenue and expense deferrals, and multi-element allocation. That same documentation is candid about the hard case, describing reallocation when a line is added to an order that has already been invoiced and the correcting entry the reallocation forces. The failure mode is configuration set at implementation against a product line that has since changed shape, with nobody owning the mapping from a new commercial term to a schedule.

When a dedicated subscription-management product wins

It wins where the contract lifecycle, rather than the arithmetic, is the actual problem: renewals, co-terming, mid-term upgrades, pauses, credits, and a sales motion that invents a new shape every quarter. The job those products do that a general ledger module does not is treating a change as a modelled event with a before and an after, which is exactly the thing the arithmetic needs and the spreadsheet cannot give. The failure mode is buying it for the schedule, then finding that the value was in the contract model and that nobody scoped the work of getting existing contracts into it.

When building something wins

It wins where the metering is the product. If what a customer owes depends on a measurement only this company’s system can make, then the meter, its dispute handling and its restatement path have to be built, because no packaged product knows the unit. What follows from that is narrower than it sounds: the thing being built is a measurement system that feeds a schedule engine, not a schedule engine. Outside metering, a build here is a deferral calculator with a support burden, competing against something the company already licenses and an auditor will be more comfortable with.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Revenue recognition splits across them more sharply than anything else in this pillar: three rows say the mechanism is a commodity, and three say the decision behind it is not.

Rows two, four and six agree that the mechanism is a commodity: the process is expected to run at population scale, revision is designed in, and the engine that does the arithmetic ships in products already licensed. Rows one, three and five agree on something else entirely. The variance is not in the calculation, it is in the terms that feed it; the recurring cost is re-estimation rather than computation; and the account carries a permanent presumption of fraud risk plus a requirement to disclose the judgments made. A process with that profile does not reward building the calculator, and it punishes automating the part that was never arithmetic.

The modification is the whole problem

Everything above converges on one event. A subscription schedule is stable until the contract changes, and then it is not an appended line, it is a re-evaluation of what remains.

Two facts about modifications decide how much of this can be automated, and neither is a matter of opinion. The first is that a modification does not have a single arithmetic consequence: the standard routes it down more than one path depending on facts about the contract, which means a system cannot derive the treatment from the size or the timing of the change. It has to be told which route applies, by someone with standing to decide. That is a workflow requirement, not a modelling problem, and no amount of pattern-matching over past contracts removes it.

The second is worse for the system and better for the argument. A modification exists once the parties approve it, and approval may be in writing, by oral agreement, or implied by customary business practices. A sales manager telling a customer on a call that the extra seats start now, and both sides behaving accordingly, is an event with consequences and no row in any database. Automation cannot recompute from an amendment nobody recorded, and it will confidently produce a schedule that is now wrong without any signal that it is wrong. This is the failure mode to design against, and the design is administrative: an amendment has to be a recorded event with an owner before it can be an input.

Everything else in this process degrades gracefully. A schedule that is slightly wrong is corrected next period, because reassessment is designed in. An unrecorded modification does not degrade at all. It just stays wrong until an auditor samples it.

What this comparison usually gets wrong

The first error is scoping the schedule engine as the build. It is the part that already exists, in more than one product, in a market mature enough to have already replaced its first generation. A business case whose headline saving is generating deferral entries is proposing to buy something twice.

The second is treating the contract as data the system already has. In most companies the billing system knows the invoice, the customer relationship system knows the sale, and the terms that actually decide a schedule live in a signed document nobody parses. The work worth funding is upstream of the schedule: making the commercial terms machine-readable when the deal is done, and giving an amendment somewhere to be recorded. That work is unglamorous, it is not really an automation project, and skipping it is why a great many revenue automation projects deliver a fast, well-instrumented wrong answer.

The third is confusing revision with error. Reassessment every reporting period is a requirement of the standard, not a symptom of a bad estimate, so a system whose design assumes a schedule is written once has misunderstood the process and will treat every normal update as an exception. Consumption-based pricing intensifies this rather than creating it.

The fourth is expecting a model to make the judgment and an audit to accept it. The presumption of fraud risk on revenue is standing and does not soften for automated processes, and the reporting standard requires the entity to explain the judgments it made. A judgment produced by a system that cannot state its basis is a judgment nobody can defend, and it will be tested by the people whose job is to test exactly this account. The same point applies with less force to the ledger work that surrounds it: the month-end close and intercompany elimination processes have their own controls and their own pages, and this one begins after the terms are known and ends when the entries are posted.

The verdict

Buy the schedule, keep a person on the judgment, and spend the budget upstream of both.

On the evidence in the profile, the arithmetic half of this process is a commodity and building it is a mistake. The standard expects it to run at population scale, revision is a designed feature rather than a defect, and the engine ships inside products that most companies in this position already license, in a market mature enough that a major vendor deprecated its first attempt in favour of a better contract model. There is no reading of rows two, four and six that produces a build, and constructing one to look balanced would be a worse failure than the recommendation being commercially inconvenient.

The other half does not automate, and the reason is not caution. Revenue is the only account carrying a standing presumption of fraud risk, it was among the leading deficiency areas in the most recent inspection cycle, standalone selling price is the single most common estimate-related finding, and the reporting standard requires the judgments made to be disclosed as judgments. A system may compute, record, evidence and reproduce those decisions. It may not make them unattended, and this page takes no view on what the decisions should be, because that is accounting advice and it belongs to the people who sign and audit the accounts - a discipline not every consultant selling revenue-recognition automation seems to observe.

What is left is the part worth building, and it is not what the request usually describes. It is the recording layer: commercial terms captured in a structured form at the point of sale rather than in a document, amendments raised as events with an owner and a timestamp, metering that can be restated when a customer disputes it, and a schedule engine that is configured rather than written. Done in that order, the automation is largely configuration and the interesting work is a contract-data problem. Done in the usual order, the company owns a calculator that runs on figures nobody can trace, and the first person to notice will be an auditor.

For a team weighing this, two cheap exercises settle it faster than an evaluation. Take last quarter’s contract amendments and try to establish, for each one, the date it was agreed, who agreed it and where that is recorded; the ones that fail are the ones a system would have silently mis-scheduled. Then open the deferral or subscription-billing module in the accounting system already installed and check whether it is switched on. The first exercise finds the actual exposure. The second usually finds that the software was licensed years ago and never configured. The recording layer described above is the part of this we will actually build - tell us about your contract data and we will say whether it is worth doing.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

• The billing system already produces recurring invoices and the accounting package already carries a deferral or subscription-billing module, and the brief is to build something that turns a contract into a set of period entries. That software, and the studio says so. The schedule engine is a shipped, documented and widely implemented feature: one major vendor deprecated its older general revenue recognition module in January 2024 and directs new users to a subscription-billing product whose three modules are recurring contract billing, revenue and expense deferrals, and multi-element revenue allocation, with the allocation module described as being there to comply with the international and United States revenue standards. Paying to rebuild that is the most common thing found underneath a revenue recognition automation request, and configuring the licensed one is a project of a different size.
• The design has the system decide, without a review step, how a mid-term contract change should be treated, on the reasoning that the change is just another input and the rules can be encoded once. A human control point, or a simpler deterministic rule. A modification does not have one arithmetic consequence: the standard routes it down more than one path depending on facts about the contract, so the system cannot infer the path from the size of the change and has to be told which one applies. The same standard then requires the entity to disclose the judgements it made and the changes to them, which means a decision taken silently inside a job is a decision the accounts cannot describe. Encode the arithmetic, keep a named person on the routing, and record who routed it and on what basis.
• Every contract is individually negotiated, with bespoke terms, bespoke start conditions and side letters, and the automation is expected to learn the pattern from the population. A redesigned process, not an automated one. There is no pattern to learn when the exceptions are the population: the standard's own labour-saving device is a portfolio approach, available where a group of contracts is similar enough that treating them together would not change the outcome, and a book of one-off agreements is precisely the case it does not fit. The intervention that pays here is contractual rather than technical - a small number of standard shapes that sales may sell without a review, and an explicit exception route for anything outside them. Automate afterwards, against the shapes.
• The case rests on the hours the schedule takes to maintain, and today it is a handful of contracts on one billing cycle that nobody amends mid-term, kept in a spreadsheet the controller rebuilds in an afternoon. The person already doing it, unchanged. The work in this process scales with the number of live schedule lines that change, not with the number of customers or the size of the revenue, and a stable book on a single cycle produces a schedule that is one formula copied down. The condition worth watching is not a headcount or a contract count: it is the point at which modifications arrive continuously rather than at renewal, because that is when a schedule stops being a calculation and becomes a queue. Automating before then buys a system that recomputes an answer nobody was getting wrong.
• The commercial terms that decide the schedule live in signed documents and email threads, the billing system knows only what was invoiced, and nobody can say from the systems what a given contract actually promised. The organisation itself, doing the documentation first. This is the failure the standard itself makes unavoidable rather than a shortcoming of any product: a modification exists once the parties approve it, and approval may be in writing, by oral agreement, or implied by customary business practices, so the event that invalidates a schedule can leave no trace in any system the automation reads. A machine cannot recompute from an amendment nobody recorded. The prior work is making the terms that drive the schedule machine-readable at the point of sale and making an amendment a recorded event with an owner, and it is administrative rather than technical.

Sources

1. Public Company Accounting Oversight Board, AS 2110, 'Identifying and Assessing Risks of Material Misstatement' - paragraph .68, the presumption of a fraud risk involving improper revenue recognition, read alongside paragraphs .65 to .69 on fraud risk factors and management override Retrieved 11 August 2026
2. Public Company Accounting Oversight Board, 'Spotlight: Staff Update on 2024 Inspection Activities', March 2025 - the section on revenue and revenue related accounts and its deficiency examples, the observation that the most common estimate-related deficiencies concern standalone selling price, and Figure 21 on common financial statement deficiency areas excluding internal control over financial reporting, whose percentages are comment-form deficiencies as a share of the times an area was selected for review. Read as text extracted from the Board-hosted PDF Retrieved 11 August 2026
3. IFRS 15 'Revenue from Contracts with Customers' as adopted in the European Union - paragraph 4 on the portfolio practical expedient, paragraphs 18 and 19 on what a contract modification is and how it may be approved, paragraphs 20 and 21 on the routes a modification takes, paragraphs 56 to 59 on constraining and reassessing estimates of variable consideration, paragraphs 77 to 79 on stand-alone selling prices and their estimation, paragraphs 120 and 121 on remaining performance obligations and the one-year expedient, and paragraph 123 on disclosing judgements. Read from the consolidated text of Commission Regulation (EC) No 1126/2008 on EUR-Lex, CELEX 02008R1126-20230101 Retrieved 11 August 2026
4. Financial Accounting Standards Board, 'Post-Implementation Review: Revenue from Contracts with Customers (Topic 606)', 2024 - the benefits and costs summary, the Appendix A finding that the primary ongoing cost stakeholders raised was updating variable consideration estimates each reporting period, the observation on tracking information manually where information technology systems were inadequate, and the list of areas stakeholders found challenging to apply. Read as text extracted from the Board-hosted PDF Retrieved 11 August 2026
5. European Securities and Markets Authority, 'Report on the 2025 Corporate reporting enforcement and regulatory activities', published 2026 - the section on revenue from contracts with customers covering 91 issuers, including the share holding long-term contracts, the share including variable consideration in a transaction price, the share disclosing backlog information, the share providing full reconciliations of opening and closing backlog balances, and the enforcement actions taken. Read as text extracted from the Authority-hosted PDF Retrieved 11 August 2026
6. Microsoft, 'Revenue recognition overview' and 'Revenue recognition setup', Dynamics 365 Finance product documentation, both carrying the note that the functionality was deprecated in January 2024 and that new users should use subscription billing - the reallocation behaviour when a line is added to an already-invoiced order and the correcting entry it requires; and 'Subscription billing overview', which describes the three modules and states that multi-element revenue allocation is there to comply with IFRS 15 and ASC 606 Retrieved 11 August 2026

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.