I get some version of this question every few weeks now, usually from an engineering leader who just watched AI generate a working application in an afternoon: if the code writes itself, why are we still paying for revenue recognition software? It’s a fair question, and I don’t take it as a challenge to RightRev’s existence. I’m an engineer and developer myself so I build things, I ship code, I’m not skeptical of AI in principle. Build versus buy is not a new conversation; finance and engineering teams have been having some version of it for as long as there’s been software to build instead of buy. What’s changed is the economics: the cost of building internal tools has genuinely shifted, and finance teams at growth-stage companies are right to revisit old assumptions in light of it.
Here’s the part I keep coming back to: the hard part of revenue recognition was never the code.
Revenue recognition is financial infrastructure. Its outputs feed reported revenue, deferred revenue balances, and close packages that go to auditors, boards, and, for pre-IPO companies, eventually to the SEC. A prototype that handles 80% of contracts correctly is not 80% of the way to a production system. The remaining gap is where financial risk actually lives, and closing it requires something AI cannot generate on its own: exhaustive, continuously updated accounting judgment encoded into deterministic, auditable logic.
Before You Build: Where Does This Actually Sit on the Complexity Curve?
Most people’s intuition about what AI can do comes from the left side of the curve below. Ask a question, get a plain-language answer, resolved entirely inside a chat window. One step further, that same kind of question needs real formatting, a table, a breakdown, something a person downstream will actually use. Both are genuinely useful, and I use AI for both constantly.
A recent poll of finance and accounting practitioners bears this out: a majority are still mostly working inside a chat window, and only about one in five have built a real application for a workflow use case, and even fewer still have solutioned an entire process end to end. Most of the profession, in other words, is still clustered at the near end of the curve, which makes it easy to underestimate how much distance separates “AI helped me draft this” from “AI runs this process unsupervised.”
The curve keeps climbing past that. The next stage stitches together multiple systems and runs on its own schedule, a workflow to orchestrate rather than a question to answer. Revenue recognition sits at the far end, in Purpose-Built System territory. A recognition engine is a standing product, not a chat session: it runs on its own, takes actions against contract data, maintains state across modifications and renewals, and has to produce the same result every time for the same inputs. The output has to be traceable to source records and defensible to an external auditor. That distance, from asking a question to owning a standing, audit-grade system, is where I’ve watched most internal build efforts lose ground.
Where AI Genuinely Helps in Revenue Accounting
I want to be direct about this: AI adds real value in revenue workflows. The question I keep pushing teams to ask is which workflows.
Contract intelligence is a strong use case. Extracting performance obligations, pricing terms, and payment structures from order forms and sales contracts is pattern-matching work that AI handles well, especially when the volume of contracts makes manual review impractical. Classification and triage work similarly. AI can flag contracts that likely contain multiple performance obligations, variable consideration, or structures that resemble past treatment decisions, surfacing them for controller review rather than letting them move through unexamined.
Drafting support is another area where AI earns its place. Policy memo first drafts, contract summaries, disclosure language for controller review, these are tasks where AI accelerates the work without owning the accounting conclusion. And once judgment calls are made and rules are approved, AI can automate mechanical execution: generating schedules, proposing journal entries from structured inputs, running anomaly detection against established patterns.
The common thread I see across all of these is that accounting treatment has already been decided. AI is implementing a specification, not authoring one.
87% of CFOs expect AI to be extremely or very important to finance operations in 2026. (Deloitte Q4 2025 CFO Signals Survey)
That figure reflects genuine momentum, and I don’t discount it. Finance leaders are right to take AI seriously. My argument here is narrower: adopting AI in finance workflows is different from delegating ownership of a compliance system to an AI-assisted build effort.
Where the AI Build Actually Stalls
I’ve watched this pattern play out the same way every time it’s tried: AI gets a working prototype most of the way there fast. Domain experts push it further still. It never quite reaches something a Big Four auditor would sign off on for SEC reporting. The reason is specification, not capability. Someone has to translate every edge case, exception, and validation rule into system behavior, and that’s work no model can originate on its own. We’ve written before about exactly how that burden compounds as a business grows; the short version is that it never resets, and it lands on the same finance team already keeping the lights on with spreadsheets.
Michelle Stalick, Chief Accounting Officer at BlackLine, made a version of this argument in CPA Practice Advisor this July, writing from outside RightRev entirely, which is exactly why it’s worth citing here. Generic AI models don’t know a company’s chart of accounts or where materiality actually sits. Black-box outputs don’t satisfy audit requirements without a documented chain of decisions. And governance can’t be bolted on after the fact. That’s a description of what a production revenue recognition system has to be, and it matches everything I’ve seen building one.
The Failure Mode That Doesn’t Announce Itself
The most instructive illustration I go back to, of where billing-triggered recognition logic breaks down, involves a contract with a free period before billing starts.
A seat is added or dropped during that free period. A billing-triggered recognition engine has no invoice to process, so the change never reaches the engine at all. Revenue continues accruing against the original seat count. Once billing begins, the paid-period numbers don’t reconcile against what should have been recognized from the start of the contract. Nothing throws an error. The output is just quietly wrong until someone reconciles it by hand.
Getting this right requires treating the contract, not the invoice, as the unit of account, with seat and usage changes as first-class recognition triggers independent of billing events. That’s an accounting architecture decision, not a coding problem. An AI-assisted build will gravitate toward billing-triggered logic because that’s the best-documented integration pattern. The accounting requirement that overrides it has to be explicitly specified by someone who understands why it matters, and that’s the kind of thing I’ve had to specify by hand more times than I can count.
What’s Expensive to Recreate
The capabilities that matter most in a production revenue recognition system are not features. They’re accumulated accounting logic, tested against years of contract edge cases, and maintained through every business change, things like:
- A recognition engine that runs on contract terms, not just invoices
- An SSP allocation engine with a defensible, documented methodology
- Modification handling that distinguishes prospective from cumulative catch-up treatment
- Free-period and ramp recognition that doesn’t depend on a billing event to catch a change
- A SOX-ready audit trail, access controls, approvals, evidence retention, built in from day one, not bolted on
Each one is a category where the gap between a prototype and an audit-ready system is measured in accounting specification work, not engineering hours. We’ve laid out the fuller list elsewhere; the short version is that this is a map of where I’ve watched teams get stuck.
The Real Cost of Building It Yourself
Finance leaders who have evaluated internal builds consistently underestimate cost because the initial framing focuses on engineering time. The fuller picture includes requirements definition across every contract scenario the business runs, QA coverage that holds up under audit, and ongoing upkeep, ERP and CRM integration, audit documentation, change management, every time the product or pricing model evolves.
Meaningful production value typically takes 12 to 24 months to reach. During that window, the business keeps changing. New pricing models, AI-credit billing, consumption tiers, channel expansions, each one adds logic that has to be specified before it can be built. The engineering team is re-engineering while the finance team is still running the manual process alongside it.
Homegrown systems also attract more scrutiny once they become material to reported results. Auditors ask harder questions about controls and documentation for systems built internally than for purpose-built platforms with established audit histories. That scrutiny increases the documentation burden on an already stretched finance team.
There’s also a predictability gap that rarely shows up until the board asks about it directly, and I’ve sat through that conversation. A licensed platform is a known, fixed, budgetable line item, quoted up front and typically locked in for the contract term. An internal build’s true cost is diffuse: spread across engineering headcount, ongoing maintenance, and the opportunity cost of what that team isn’t building instead, which makes it far harder to defend in a budget review.
That diffusion compounds at scale, too. As transaction volume grows, an internally built system has no ceiling protecting it from its own success, while a multi-year licensed term insulates the business from re-pricing risk exactly when volume, and the cost of getting recognition wrong, is highest.
The alternative to perpetual re-engineering is a platform that absorbs business change through configuration rather than code. The accounting logic is already built, tested, and maintained. Updates to standards or new contract structures become configuration decisions, not development projects. The finance team specifies treatment; the platform implements it. This is the bet I made when I started RightRev, and nothing I’ve seen since has changed my mind about it.
The Question That Actually Determines the Decision
AI can write the code. Yes..
The question that determines whether a build is viable is who will own the accounting knowledge, compliance burden, and continuous evolution of the system for years to come. That ownership doesn’t transfer to an AI model. It stays with the finance team, indefinitely, on top of everything else they’re already doing.
For growth-stage and pre-IPO companies, that’s a cost and risk calculation, not a capability question. The build path trades a one-time platform cost for perpetual specification work, ongoing maintenance, audit scrutiny of a homegrown system, and the schedule risk that comes with re-engineering a compliance system while the business keeps moving.
A purpose-built platform shifts that burden. The accounting logic is already there. The audit trail is already there. The edge cases, including the ones that don’t announce themselves until a reconciliation breaks, have already been worked through. I built RightRev because finance teams are too skilled, and too expensive, to spend their time patching spreadsheets and rebuilding infrastructure that already exists. I’d rather they spend it on providing the expertise only they can provide.
Wondering whether your revenue model is complex enough to stress-test a homegrown build? RightRev’s Revenue Complexity Assessment is an 11-question self-diagnostic that helps finance teams map their contract structures, pricing models, and modification patterns against what a production recognition system actually needs to handle. If you’d rather walk through the architecture directly, request a demo and I’ll show you where the gaps typically appear.
