Accounting AI agent · Revenue recognition
Revenue-Recognition AI Agent (ASC 606 / IFRS 15)
Read the contract, propose the performance obligations and the allocation, build the deferred-revenue schedule and assemble the disclosure inputs — for the technical-accounting lead to accept, with the trail an auditor will test.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Lead approval
- Pre-booking
- After launch
- Agent Care
What this agent does
Reads the contract, not the conclusion
In
- 01
A contract is signed, amended or renewed, and the agent ingests it from the configured CLM, CRM or repository feed.
- 02
Clauses are extracted and normalised, and each one stays tied to the page and section it came from.
Reason
- 03
Distinct promises are proposed as performance obligations, each anchored to the clause that supports it.
- 04
Transaction price is allocated across the proposed obligations using the configured estimation method.
- 05
Variable consideration is estimated and the configured constraint factors are applied to the proposal.
Decide
- 06
Modifications, renewal options and principal-versus-agent indicators are flagged, each with the clause behind it.
- 07
Every proposed obligation, allocation and constraint is routed to the technical-accounting lead for acceptance.
Out
- 08
The clause, the proposal, the reviewer's edits and the acceptance are retained against the contract.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent proposes the obligations, the allocation and the constraint; the technical-accounting lead decides what is booked, and the company remains the preparer of record.
Example workflow
One contract, clause to schedule
- 1Contract receivedCLM export, CRM entry, order form or contract-repository API
- 2Clauses extractedDeliverables, pricing, standalone-price data and prior modifications, each with its clause
- 3Obligations proposedProposed obligations, allocation, constraint and confidence
- 4Controls appliedClause-support check, modification-treatment check, dual-framework flag and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is booked at any of them — the technical-accounting lead's lane opens at the confidence gate.
Goes to the technical-accounting lead to approve.
Adds a controller read first.
Lead approval
The proposal is held with its clauses, its flags and the confidence.
Approve · Adjust · Send to controller review
Approved — released to book
- 6Revenue systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedAllocation accuracy, override rate, audit findings and post-close corrections
Overrides
Every lead override is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Booking the deferred-revenue entry to the ledger.
- Concluding that a promise is a distinct performance obligation.
- Setting a standalone selling price with no observable input.
- Deciding principal versus agent for a promise.
Automation boundary
Agent acts unaided
- ✓Propose performance obligations and the allocation, each attached to its clause.
- ✓Estimate variable consideration and propose the constrained amount for review.
- ✓Build the deferred-revenue schedule from the accepted.
- ✓Flag modifications, material rights.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
- Releasing a variable-consideration constraint.
- Classifying a contract modification's treatment.
- Determining functional versus symbolic IP.
- Signing the revenue policy memo.
Example output
One obligation, annotated
Everything the agent proposes is attached to the clause it was drawn from.
Allocation output · single obligation
Illustrative example- Contract
- Three-year platform contract
- Proposed obligation
- Implementation services distinct from the hosted platform
- Allocated price
- $186,400
- SSP method
- Adjusted market assessment
- Confidence
- 89%
- Basis
- Comparable market-rate SaaS deals
As received
Taken from the contract and the order form — nothing on this side is inferred.
Evidence used
- Statement of Work, clause 4.2
- Standalone price list
- Prior modification history
Why this allocation
The clause supports a distinct promise, but the price isn't observable.
What the score decides
Below the configured threshold the proposal picks up a controller read before the lead sees it.
Action
ApproveAdjustSend to controller reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every contract
From the CLM or contract repository
Read against the clause library
Draw on deliverables, pricing and prior modifications already on file.
Judgement is not extraction
Routine clause extraction and drafting run without a person touching them.
Send review to the judgement calls
Modifications, material rights and constraint estimates are flagged, so the lead's read starts where judgement concentrates.
Build an evidence trail
The obligation, the clause it was read from and the controller who accepted it stay on the contract.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Contract and CLM systems
- DocuSign CLM
- Ironclad
- Salesforce CPQ
- Conga
Billing and ERP systems
- NetSuite
- SAP
- Oracle
- Zuora
- Chargebee
- Stripe Billing
CRM and order data
- Salesforce
- HubSpot
- Order forms
- amendments
Agent
Revenue recognition
- Reads the contract
- Proposes the allocation
- Holds for approval
Disclosure and reporting
- Workiva
- Trintech
- Approval systems
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the schedule
Each layer contains the next. What escapes all of them is named in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a proposal may stand
- L3
- Puts the release in the lead's hands
- L4 – L5
- Keep the obligation and the clause behind it
- L6
- Falls back to contract summarisation when signals degrade
How Nestack evaluates it
Evaluate the allocation workflow — not only the finished schedule.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the schedule the auditor sees
- E1Final-output evaluationDid every proposed obligation tie to a supporting clause?
- E2Step-level evaluationDid the agent use the right clause library, estimation method and framework?
- E3Tool evaluationDid it read and write the correct contract and obligation?
- E4Confidence calibrationDo low-confidence proposals actually attract more overrides?
- E5Slice evaluationHow does performance change across specific contract families?
- E6Business outcomeHow many proposals needed an override or a later restatement?
Floor — the outcome the auditor tests
Failure modes
Where each failure originates in the agent
Seven failure modes, plotted against the five stages the agent moves through.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- RU-03
Superseded contract version
Clause terms are read from a version an amendment already replaced.
Stage gathers
Contract terms, pricing history and prior allocations
02 · Reasoning
2 modes
- RU-04
Modification treatment reversed
Prospective treatment is applied to a change that needs a cumulative catch-up.
- RU-06
Residual method defaulted
Every non-observable price falls to residual, not just the highly variable ones.
Stage proposes
The proposal and its confidence
03 · Tool / write
2 modes
- RU-02
Commission period undersized
Sales-commission amortisation stops at the initial term though renewals are anticipated.
- RU-05
Constraint left stale
A variable-consideration constraint carries forward without a period refresh.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- RU-01
Gross presentation error
Revenue books gross though the agent never held control before transfer.
Stage returns
The schedule the lead approves and the auditor sees
05 · Change / Version
1 mode
- RU-07
Silent estimation-method drift
A model or rule change widens which allocations default to residual.
Stage tracks
Model, prompt, clause library and method rules
- Sev-1 · books outside the boundary
- Sev-2 · wrong allocation reaches the schedule
- Sev-3 · source degrades, proposal goes to review
Affected slices
A healthy portfolio can hide one contract family
Portfolio-level accuracy can look strong while a handful of contract families absorb most of the rework. Nestack reports the allocation-rework rate by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Contracts modified mid-term | 7.2% | 3.8× | Review | |
| Bundles with no observable price | 5.4% | 2.8× | Review | |
| Usage and variable consideration | 3.3% | 1.7× | Watch | |
| Single-obligation ratable contracts | 1.9% | 0.7× | Normal |
Bar: allocation-rework rate lift vs. the single-obligation baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
Every cycle ends inside the regression suite
A cycle is closed when the misallocation is a case the next release must survive. That suite is what the next contract read is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Allocation-rework rate rises in a contract family.
- 02
Diagnose
The renewal option nobody priced is traced back through the clause and the model that misread it.
- 03
Improve
The change ships against a version, with the contracts that exposed it attached.
- 04
Verify
Release is blocked until the affected allocation cases pass again.
- 05
Learn
The case joins the standing suite and the policy memo moves with it.
Learn → Detect
The return edge. The next contract is read against a suite one case larger.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, allocation workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Contract workflow discovery and boundary definition.Week 1
- 02CLM, CRM and billing-system assessment.Week 1, Week 2
- 03Clause-library and estimation mapping and rule mapping.Week 1, Week 2
- 04Contract ingestion and normalisation.Week 2
- 05Obligation and allocation logic.Week 2, Week 3
- 06Confidence scoring and exception routing.Week 3
- 07Technical-accounting approval workflow.Week 3, Week 4
- 08Billing and ledger integration.Week 5
- 09Allocation and constraint cases.Week 4, Week 5
- 10Guardrails and acceptance controls.Week 4
- 11Contract-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne contract source, one entity | ProductionProduction revenue systems | AdvancedMultiple entities / standards |
|---|---|---|---|
| Introduced at Pilot | |||
| Allocation and schedule recommendations | ✓ | ✓ | ✓ |
| Lead approval | ✓ | ✓ | ✓ |
| Allocation-accuracy baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by contract type | — | ✓ | ✓ |
| Approval workflow in your systems | — | ✓ | ✓ |
| Approved schedule posting | — | ✓ | ✓ |
| Billing and ledger integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-standard allocation rules | — | — | ✓ |
| Multi-stage technical review | — | — | ✓ |
| High contract volume | — | — | ✓ |
| Multi-standard reporting controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your contract templates and clause library
→Contract ingestion and clause mapping
Week 102Representative signed contracts
→Allocation baseline, obligation drafting and confidence scoring
Week 203Your revenue-recognition policy and estimation methods
→Clause-library and estimation-method mapping
Week 104Access to relevant APIs, feeds or exports
→CLM, CRM and billing-system assessment, then integration setup
Week 205Schedules you would not want booked
→Modification cases and failure-mode testing
Week 406What no schedule may assume
→Confidence scoring, flag routing, guardrails and acceptance controls
Week 307Named technical-accounting leads to review proposals
→Technical-accounting approval workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Each phase sits over the weeks it really occupies, and week 5 carries evaluation alongside the pilot.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Revenue workflow discovery, clause mapping and the boundary
W2Source integration and the allocation baseline
W3Allocation workflow, confidence logic and approval controls
W4Evaluation suite, guardrails and failure-mode testing
W5Billing integration, pilot contracts and targeted corrections
W6One reporting cycle booked under the technical-accounting lead, then handover
- Reading the band
- A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
- At the end of W6
- The last checks clear on live contracts and Agent Care picks up monitoring.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Accounting AI agent
Build a revenue-recognition agent around your technical-accounting team's approval chain.
Show us your contract templates, your policy memos and who signs off on judgement calls. Not conclusions. Proposals, with the clause behind each one, for your technical-accounting lead to accept.
- Typical delivery
- 4–6 weeks
- Deployment
- Your contract and billing stack
- Lead approval
- Pre-booking
- After launch
- Agent Care available
Nestack Agents · Revenue recognition
AGT-ACC-18 · Agent Care available after launch