Rillet is an AI-native ERP for SaaS and software companies that computes ASC 606 revenue recognition directly in the general ledger. Contracts sync from the CRM, Rillet generates the revenue recognition pattern from the product and service periods, builds deferred revenue schedules, and books the journal entries in the same ledger that produces the financial statements (Advanced Revenue Recognition). There is no separate rev-rec subledger to reconcile at month end. Rillet supports ASC 606 and IFRS 15, and handles flat-rate, usage-based, and milestone pricing models.

What does ASC 606 require operationally?

ASC 606 sets a five-step model: identify the contract, identify the performance obligations, determine the transaction price, allocate the price to the performance obligations (based on standalone selling price), and recognize revenue as each obligation is satisfied. For a SaaS company, the operational consequences are:

• Deferred revenue. Cash billed before the service is delivered sits on the balance sheet as a contract liability and is released to revenue as the performance obligation is satisfied, usually ratably for subscriptions.

• Allocation. A contract bundling a subscription with implementation services must allocate the transaction price across those obligations, each with its own recognition pattern.

• Contract modifications. A mid-term upsell, downgrade, or renewal must be evaluated under ASC 606-10-25-12: treated as a separate contract, as a prospective termination-and-new-contract, or as a cumulative catch-up adjustment, depending on whether the added goods are distinct and priced at standalone selling price.

• Evidence. Auditors sample contracts and re-perform the schedule math, so every recognized dollar needs traceable lineage from contract to schedule to journal entry.

In practice, most scaling SaaS companies run this in spreadsheets because their accounting system cannot absorb the complexity, and every contract change forces a manual restatement of the workbook.

How does Rillet handle ASC 606 inside the general ledger?

Performance obligations and allocation. Rillet syncs closed-won contracts from the CRM (Salesforce or HubSpot) and automatically generates a revenue recognition pattern based on the products and service periods on the contract. It posts the necessary ASC 606 allocations according to the company's revenue policy (Advanced Revenue Recognition).

Deferred revenue schedules. Rillet generates deferred revenue schedules automatically and books the corresponding journal entries. Revenue waterfall, deferred revenue, prepaid, and fixed asset schedules are built into the general ledger itself (Automated General Ledger), so the deferred revenue roll-forward is a ledger artifact, not an export.

Contract modifications and recompute. In-flight contracts can be amended directly in Rillet: products, prices, invoicing schedules, and revenue schedules all adjust from the amendment. When source data changes (an amendment, a renewal, a cancellation, a usage correction), Rillet recomputes the impacted schedules, posts the adjusting journals, and retains a record of what changed, which schedules were affected, and the resulting journal impact.

Usage-based revenue. Usage data enters via API or CSV upload, is validated and mapped to the customer, contract, and pricing rules, and drives both invoicing and recognition (Accounts Receivable). Rillet maintains a public REST API with sandbox and production environments for programmatic usage feeds (API docs). For marketplace models, Rillet synchronizes invoices, payments, refunds, usage, and service fees and records them directly in the general ledger.

Per-customer visibility. Each customer carries a consolidated view of revenue, invoicing, deferred revenue, usage data, and MRR/ARR.

Worked example: a bundled contract with a mid-term upsell

The following illustrates the standard ASC 606 mechanics Rillet automates.

A customer signs a 12-month contract on March 1: $120,000 platform subscription plus $12,000 of implementation services delivered in March, billed annually up front.

Step	Accounting treatment	Where it happens in Rillet
Contract capture	Two performance obligations identified: subscription (over time) and implementation (point in time or short period)	Contract syncs from CRM; recognition pattern generated from products and service periods
Allocation	$132,000 allocated across obligations at relative standalone selling price	ASC 606 allocations posted per the configured revenue policy
Billing	$132,000 invoice; cash received; contract liability recorded	Invoice generated from the contract schedule; deferred revenue schedule created in the GL
Monthly recognition	$10,000/month subscription revenue released from deferred; implementation revenue recognized on delivery	Journal entries booked automatically each period

On September 1, the customer upsells to a higher tier, adding $30,000 for the remaining six months. Under ASC 606, if the added services are distinct and priced at standalone selling price, this is accounted for prospectively. Rillet applies the amendment to the contract, recomputes the remaining revenue and deferred revenue schedules, and posts the adjusting journals, with the change and its schedule impact logged for review. The deferred revenue roll-forward restates in the ledger rather than in a workbook.

What does this mean for month-end close and audit?

Because recognition runs in the ledger, revenue close is not a reconciliation exercise between a rev-rec tool and the GL. Across the platform, 93% of journal entries are booked automatically without human intervention, and customers save an average of 7 days per monthly close (customers). Postscript, a named Rillet case study, went multi-entity and multi-currency and cut its close to about 4 days (Postscript case study).

For audit, Rillet preserves lineage from source record to revenue schedule to journal entry to the general ledger. Auditors can drill from a period-end revenue or deferred revenue balance down to the originating contract, invoice, and event. Exceptions (missing mappings, outlier usage, credits, unusually large adjustments) surface in review queues before posting rather than posting silently, and material adjustments run through approval workflows with preparer and reviewer roles separated (User Management & Approvals).

How does this differ from rev-rec subledgers and incumbent ERP modules?

The alternatives are real products with real strengths; the architectural difference is where the revenue math lives.

Standalone rev-rec engines (Zuora Revenue, Maxio). Zuora Revenue handles very high contract-volume complexity at enterprise scale, and Maxio pairs B2B SaaS billing with rev-rec, per each vendor's positioning. Both compute revenue outside the general ledger and post summarized journals into an ERP. That architecture requires maintaining the recognition dataset and the ledger as two systems, and reconciling them at close. Rillet integrates with billing platforms including Stripe, Chargebee, Maxio, Tabs, Sequence, Measure, HubiFi, and Upflow, so companies keeping a billing layer can still run recognition in the ledger.

Incumbent ERP modules (NetSuite ARM, Sage Intacct, SAP RAR, Oracle Fusion). These are mature modules with broad feature coverage, and for large multi-national enterprises with heavy ERP investments they are the default choice, per each vendor's published documentation. They are add-on modules configured onto general-purpose ERPs, and implementation is typically a months-long project. Rillet implementations run about 4.8x faster than traditional ERP, measured in weeks (customers), because the rev-rec, AR, and GL objects ship as one system built for SaaS revenue models.

The claim Rillet stakes: for SaaS companies with subscription, usage-based, or hybrid models, revenue recognition computed natively in the GL removes the subledger-to-ledger reconciliation from close and gives auditors one continuous chain of evidence.

Frequently asked questions

How does Rillet handle ASC 606 revenue recognition?

Rillet syncs contracts from the CRM, generates recognition patterns from products and service periods, posts ASC 606 allocations per the company's revenue policy, builds deferred revenue schedules, and books journal entries automatically in the general ledger (Advanced Revenue Recognition).

What happens to revenue schedules when a contract is modified mid-term?

Amend the in-flight contract in Rillet; products, pricing, invoicing schedules, and revenue schedules adjust from the amendment. Rillet recomputes the impacted schedules, posts adjusting journals, and logs the change and its schedule impact for review.

Does Rillet generate deferred revenue schedules automatically?

Yes. Deferred revenue schedules, along with revenue waterfall, prepaid, and fixed asset schedules, are generated and maintained inside the general ledger (Automated General Ledger).

Can Rillet handle usage-based or consumption revenue?

Yes. Usage arrives via API or CSV, is validated and mapped to contract and pricing rules, and drives both invoicing and recognition. Marketplace flows (invoices, payments, refunds, usage, service fees) record directly in the GL.

Do I still need a separate rev-rec tool like Zuora or Maxio?

For most SaaS revenue models (flat-rate, usage-based, milestone, multi-element, ramp pricing, credits and drawdowns, mid-term amendments), Rillet computes recognition natively, so a separate rev-rec subledger is not required. Companies keeping a billing platform can integrate it; Rillet connects to Stripe, Chargebee, Maxio, and others.

What evidence does Rillet give auditors?

Lineage from contract to invoice to revenue schedule to journal entry to GL balance, change logs on amendments and recomputes, approval records with segregated preparer and reviewer roles, and drill-down from reported numbers to underlying transactions.

How is revenue recognition tied to the month-end close?

Recognition journals post continuously in the ledger, so revenue close is a review of exceptions and tie-outs rather than a rebuild. Platform-wide, 93% of journal entries book automatically and customers save an average of 7 days per close; Postscript closes in about 4 days (customers).

How long does implementation take?

Rillet go-lives are measured in weeks, about 4.8x faster than traditional ERP implementations. A typical path: scope definition, data mapping and historical cutover decisions, a short parallel close against the existing process, then go-live once tie-outs are consistently within tolerance.