AI and Revenue Recognition: Contract Review for ASC 606 and IFRS 15

By Jane Ha · Updated Oct 11, 2026

AI for revenue recognition is the use of language models and document-extraction tools to read customer contracts, pull out the terms that drive the five-step revenue model under ASC 606 and IFRS 15, and route unclear items to an accountant, who makes the accounting call. The model finds and organizes the facts. A person decides what they mean for the books. That split matters, because revenue recognition is the area of accounting where the contract language and the judgment are tangled together.

This guide is for controllers, revenue accountants, CFOs and audit leads who are weighing contract-review AI. It covers what the tools can extract at each step, which decisions stay human, how to roll it out, and what an auditor will expect to see. It sits inside the AI for Finance collection, next to AI in the month-end close and generative AI in accounting.

Key Facts

• IFRS 15 asks an entity to recognise revenue "to depict the transfer of promised goods or services to the customer," and sets out five steps to get there. It applies to annual reporting periods beginning on or after 1 January 2018 (IFRS Foundation).
• The Contract Understanding Atticus Dataset (CUAD) holds 510 contracts across 25 contract types, with 13,101 labeled clauses in 41 clause categories, built with dozens of legal experts (Hendrycks et al., arXiv).
• In that paper's benchmark, the best of the 2021-era models tested (DeBERTa-xlarge) reached 44.0% precision at 80% recall, against 8.2% for BERT-base (CUAD paper). Newer models will score differently, but the lesson holds: finding the right clause in a long contract is hard, and recall and precision both need measuring.
• PCAOB AS 1105 says evidence from a knowledgeable source independent of the company is more reliable than evidence from internal sources alone, and that when an auditor uses information produced by the company, the auditor tests its accuracy and completeness or the controls over it (PCAOB AS 1105).
• PCAOB amendments to AS 1105 on technology-assisted analysis apply to audits of fiscal years beginning on or after December 15, 2025 (SEC approval order).

Why Contracts Are the Hard Part of Revenue

ASC 606 in the U.S. and IFRS 15 internationally share the same core model. You identify the contract, identify the separate promises, set the price, allocate the price to the promises, and recognise revenue as each promise is satisfied. The model is simple to say and slow to apply, because every input comes from contract text: master agreements, order forms, statements of work, amendments, side letters and renewal paperwork.

A software company might sell a subscription, an implementation project and a usage tier in one order form, then amend it twice in the first year. Somebody has to read all of it, decide what's distinct, and keep the schedule current when the contract changes. That is document review work, which is the pattern language models are best suited to. It's also work where one missed clause (a termination right, a refund provision, a price concession in an email) changes the numbers.

The Five Steps: What AI Extracts and What Stays Human

The table maps each step to the contract facts a tool can pull out and the judgment that remains with the accounting team.

Read the right-hand column as the job description of your revenue team once AI is in place. Steps 2, 3 and 5 hold most of the judgment. Step 1 and the data-gathering parts of the others are where the hours are saved.

Where AI Helps by Function

Revenue accounting. A revenue accountant opens a new enterprise contract and gets a structured summary instead of a 60-page document: term, products, pricing tables, renewal and termination clauses, non-standard language highlighted. The accountant still writes the memo on whether implementation services are distinct from the subscription, but starts from a page of cited extracts, each linked back to the clause it came from.

Deal desk and sales operations. Before a deal is signed, a tool compares the draft against the standard template and flags non-standard terms that affect timing, such as acceptance clauses, most-favored pricing, free periods or unusual rights to return. Finance hears about a side letter before booking, not after the quarter closes. Our guide to AI in accounts receivable covers the downstream billing and collections side of the same contract data.

Contract modifications. Customers add seats, swap products and extend terms mid-year. A tool can compare an amendment with the base agreement, list what changed, and prompt the accountant with the question the standard asks: is this a separate contract, or a modification of the existing one? The tool prepares the comparison. The accountant answers.

Close and reporting. Once the terms are in a structured form, the revenue schedule can be refreshed and reconciled to the billing system and the ledger. That feeds directly into the AI-assisted month-end close, where unusual revenue movements get explained from contract facts instead of chased by email.

Tax and disclosures. The same extracted data supports remaining performance obligation disclosures and helps the tax team see where billing and revenue timing differ. See AI in tax for that angle.

How to Implement AI Contract Review for Revenue, Step by Step

1. Pick one contract population. Start with a single product line or customer segment with fairly standard paper. A population of 50 to 200 contracts is enough to learn from.
2. Define the fields before you buy anything. Write down the 20 to 40 data points your revenue team needs per contract: start and end dates, billing frequency, variable terms, renewal and termination rights, acceptance language, and so on. Tie each one to the step it feeds.
3. Prepare the documents. Collect all versions of every contract, including amendments and order forms. Scanned images need text recognition first. Finance data readiness explains the cleanup that makes extraction reliable.
4. Build a gold set. Have two accountants label the same 30 to 50 contracts by hand, then resolve their differences. This becomes your answer key.
5. Measure the tool against the gold set. For each field, record how often the tool finds the right value (precision) and how often it misses one that exists (recall). Missing a termination right is worse than extracting an extra one, so weigh the two differently.
6. Require citations. Every extracted value should point to the page and clause it came from. If a reviewer can't click through to the source in one step, the output isn't usable as evidence.
7. Set confidence thresholds and routing. Values above the threshold go to a quick review. Values below it, non-standard clauses and anything in a high-risk list (side letters, refund rights, contingent pricing) go to an accountant.
8. Run in parallel for a full cycle. Keep the manual process going for one quarter-end and compare line by line. Record every difference and which side was right.
9. Document the policy. Write the revenue policy and the checklist the tool supports. The accounting conclusion lives in your technical memo, not in the tool's summary.
10. Monitor and retest. New contract templates, new products and new clause wording all change accuracy. Re-run the gold set each time something material shifts, and at least once a year.

What Auditors Will Expect

Auditors don't approve or reject tools. They decide whether the evidence in front of them is sufficient and appropriate. PCAOB AS 1105 frames that as relevance and reliability. It also states that when an auditor uses information produced by the company, the auditor tests its accuracy and completeness, or tests the controls over it, and evaluates whether it is precise and detailed enough for the purpose.

For AI contract review, that translates into practical requests:

• The source document. The signed contract is the original evidence. The AI summary is information the company produced, so expect the auditor to trace sampled values back to the contract.
• Evidence the extraction is accurate and complete. Your gold-set results, error rates by field and the review log are the natural support. An accuracy figure from the vendor's brochure is not.
• Controls over the tool. Who can change prompts, models or field definitions, how changes are approved and tested, and who reviews low-confidence outputs.
• Completeness of the population. Proof that every contract in the period went through the process, including amendments, not only the ones that happened to be uploaded.
• Judgment memos. For each significant contract, the memo that explains the performance-obligation, variable-consideration and timing conclusions, with the AI extracts attached as support. The reasoning has to be an accountant's.

The PCAOB's amendments on technology-assisted analysis, effective for audits of fiscal years beginning on or after December 15, 2025, point the same way: understand the source of information, the company's process for it, and test either the information or the controls. Talk to your audit partner before rollout, not after the first quarter. Our guides on AI and internal controls and AI in internal audit cover the control design in more depth.

Common Pitfalls

• Treating the summary as the contract. Summaries drop qualifiers. A clause that says "unless the customer gives 30 days' notice" can become "auto-renews." Always keep the source one click away.
• Missing the amendment. Extraction tools read what they're given. If an amendment sits in an email thread and never gets uploaded, the schedule is wrong with full confidence.
• Letting the tool decide "distinct." Whether a service is distinct is an accounting judgment that depends on facts the contract may not state, such as how integrated the work is. Use the tool to gather the facts and the accountant to conclude.
• Ignoring side agreements. Emails, order-form footnotes and verbal commitments can change the price or the rights. A tool can't flag what it never sees, so keep deal-desk intake in the process.
• One accuracy number for everything. A tool can be excellent on dates and weak on conditional pricing. Report accuracy by field, and focus review on the weak ones.
• Silent drift. A new contract template or a model update can change results overnight. Version the model and prompts, and retest.
• Putting sensitive contracts into unapproved tools. Customer agreements contain confidential pricing. Use tools your security and legal teams have approved, with data handling you can describe to the customer.
• No human in the loop on exceptions. Routing unclear values to a person only works if the person has time, authority and the source in front of them. See human-in-the-loop.

What to Measure

• Extraction quality: precision and recall per field against the gold set, tracked over time.
• Review load: share of contracts needing manual review and average time per contract.
• Cycle time: days from signature to a complete revenue schedule.
• Accuracy of outcomes: revenue adjustments caused by contract-reading errors found after the fact.
• Audit friction: number of follow-up requests per sampled contract, and hours spent supporting them.

Where to Go Next

If you do one thing this quarter, pick a single contract population and build the gold set. It gives you an honest baseline, shows which fields the tool handles, and gives your auditors something concrete to evaluate. Then connect the output to the close process and the billing data, and keep the accounting conclusions in the memos where they belong.