AI Agents
AI agents for revenue recognition: what the agent drafts, and what the auditor owns
Usage-based and AI-consumption pricing turned revenue into variable consideration, and ASC 606 made that a judgment call every period. An agent can assemble the contract, pull the usage, and draft the schedule. It cannot own the estimate, the constraint, or the sign-off. The line between the two is the whole discipline.
The same shift that put a meter on your software put a judgment call in your close. When you sold a flat annual subscription, revenue recognition was close to arithmetic: twelve equal slices, posted monthly. The moment you moved to usage-based or AI-consumption pricing, that revenue became variable consideration, and under ASC 606 variable consideration is an estimate you have to defend every period.
Sit with the irony for a moment. The AI boom that made your revenue harder to recognise is the same one now selling you an agent to recognise it. Both things can be useful. Neither changes who signs the number.
My position, before the mechanics: an agent can own the gathering, the drafting, and the flagging, which is most of the hours. It cannot own the estimate, the constraint, or the control sign-off, which is most of the risk.
Automate the first and keep the second human, and you get a faster close that still passes audit. Blur the line and you have built a confident machine for producing misstatements.
Why usage-based pricing broke the easy version
Revenue recognition under ASC 606 runs on a five-step model: identify the contract, identify the performance obligations, determine the transaction price, allocate that price to the obligations, and recognise revenue as each obligation is satisfied.
Flat subscriptions make steps three and five trivial. The price is fixed and the service is delivered evenly, so you recognise ratably and move on.
Usage-based pricing breaks that at step three. A consumption fee is variable consideration, and the standard does not let you wait for the invoice and call it done. You estimate the variable amount using either the expected-value method or the most-likely-amount method, and then you apply the constraint: you may only include an estimate to the extent it is highly probable a significant reversal will not occur later.
So every period, for every usage-based contract, someone is making three calls. Which estimation method fits this contract. How much of the estimate survives the constraint. And whether last period’s estimate needs a true-up now that the actuals are in.
None of those is arithmetic. All of them are the kind of judgment an auditor asks you to show your work on.
There are shortcuts in the standard, and they matter for scoping an agent. The as-invoiced practical expedient lets you recognise the amount you have the right to invoice when billing corresponds directly to the value delivered, which removes the upfront estimate for simple per-unit arrears billing.
The usage-based royalty exception recognises revenue as usage occurs, but only for a licence of intellectual property, so a hosted API or compute service does not qualify and the estimate-and-constrain machinery stays in force.
Knowing which contract qualifies for which treatment is itself a judgment, and it is the first one people want to hand to the agent. Do not.
What an agent can own
Most of the time a revenue team spends is not spent judging. The hours go to gathering, matching, and drafting, which is exactly the work an agent is good at.
An agent grounded in your contract and billing data can read a signed contract and extract the performance obligations, the pricing terms, the committed minimum, and the overage rate. Document AI in Data 360 turns the PDF into structured fields, and the agent assembles them into the shape the recognition engine needs. That alone removes hours of someone retyping a contract into a schedule.
It can pull the period’s usage from the billing system, match it to the right contract line, and separate the committed base from the overage. The committed minimum is fixed consideration; the overage is the variable part that needs estimation and the constraint. An agent can do the separation deterministically and hand the accountant a clean split instead of a spreadsheet to untangle.
It can draft the recognition schedule and the journal entry, and present them as a proposal with its reasoning attached:
{
"contract": "MSA-2026-0442",
"period": "2026-09",
"committed_base": { "amount": 10000, "treatment": "ratable", "confidence": "high" },
"overage_usage_units": 184200,
"overage_estimate_method": "most_likely_amount",
"overage_estimate": 4420,
"constraint_applied": true,
"amount_after_constraint": 3800,
"prior_period_trueup": -610,
"proposed_recognition": 13190,
"flags": [
"Overage ran 3.1x the trailing-6-month average; estimate may need review.",
"Contract 'minimum commitment' clause ambiguous on carry-forward of unused units."
],
"status": "DRAFT, requires controller approval before posting"
}And it can reconcile. The agent compares billed to recognised across every contract, finds the ones where the two diverge beyond a threshold, and flags them for a human. That reconciliation is the part of the close that eats a weekend, and it is pure pattern-matching an agent handles well.
Note what every one of those outputs has in common. Each is a draft, it carries its reasoning, and it ends at a human. The agent assembled the facts and proposed a treatment. It did not decide anything that an auditor would hold a person accountable for.
What stays human, and why the standard makes it so
Draw the line at judgment, and the standard tells you where judgment lives.
The estimate is a human call. Choosing expected value over most-likely-amount, and defending the number, is an accounting judgment that depends on the contract, the history, and the entity’s policy. An agent can suggest a method and compute both. It cannot own the choice, because the choice is what the auditor tests.
The constraint is a human call. “Highly probable that a significant reversal will not occur” is a probability judgment about the future, and the whole point of the constraint is conservatism a person is accountable for. An agent that applies a constraint threshold is applying a rule someone set; the someone is still on the hook.
Allocation across performance obligations is a human call when standalone selling prices are not observable, because estimating them is judgment. And the sign-off is the control. Someone with authority attests that the number is right, and that attestation is what makes the financial statement a financial statement rather than a model’s best guess.
This caution is not timidity. It mirrors how SOX controls and internal audit already treat any system-generated number. The agent’s output is an input to a control, never the control itself.
A controller reviewing and approving the agent’s draft is performing the control; the agent is performing the preparation. Keep that distinction crisp and your auditor has something to test. Lose it, and you have an unreviewed estimate posting to the ledger, which is the finding nobody wants.
Where this runs on Salesforce
If your quote-to-cash already lives on the platform, the recognition work can too. Salesforce’s revenue product, now branded Agentforce Revenue Management, is a revenue-lifecycle platform built natively on Salesforce that covers subscriptions, usage-based services, and one-time products, with revenue recognition among its features.
That native footing is the advantage. The contract, the usage, the billing schedule, and the recognition all sit in one system, so the agent is not stitching four tools together to see a contract end to end. If you are still on CPQ, the migration to Revenue Cloud is the prerequisite conversation, and it is worth having before you layer an agent on top of a split stack.
The agent itself is a standard Agentforce build. It runs as a scoped Salesforce user with read access to contracts, usage, and billing, and never with the permission to post a final entry on its own. Its actions are governed Flows that draft, reconcile, and route for approval. Every draft, every flag, and every approval lands in the same audit trail as the rest of the org, which is the evidence your auditor will ask to see.
The design pattern is the one from human-in-the-loop agents: the agent proposes, a person disposes, and the disposition is logged. For revenue, that pattern is not a nicety. It is the control.
How to deploy it without failing the audit
Start where the judgment is thinnest and the volume is highest.
The best first use case is reconciliation and exception flagging, not recognition itself. Point the agent at billed-versus-recognised across every contract and let it surface the divergences. It touches no estimate, posts nothing, and still removes the most tedious hours in the close. You build trust on work where a wrong answer is a flag to investigate, not a misstatement to restate.
Expand to drafting next: the agent assembles the schedule and proposes the entry, a human reviews and approves, and the approval is the control. Keep the as-invoiced and simple-arrears contracts in scope early, because they carry the least estimation judgment, and hold the heavily variable contracts for when the review workflow is proven.
Never give the agent the final post. The line between a faster close and a controls failure is whether a person approved the number before it hit the ledger. The same holds for the financial close generally, and it is sharpest in revenue, where the estimate is already the soft spot an auditor probes.
The agent earns its place by giving your accountants their weekend back on the gathering and the matching, so they spend their judgment on the estimates that need it. It does not earn its place by making those judgments for them. Automate the preparation, keep the control human, and the number that reaches the auditor is one a person is still prepared to sign.
