Automating ASC 606 revenue recognition from source data

Rillet’s revenue recognition module is designed to transform contract terms and operational activity (for example, invoices and usage) into ASC 606–aligned revenue schedules and the corresponding journal entries. Instead of building schedules in spreadsheets or reconciling logic across multiple systems, the goal is to centralize:

• Source-of-truth inputs (contract metadata, billing events, usage/consumption files)

• Revenue logic (timing, allocation, and schedule calculations)

• Accounting outputs (revenue schedules, postings/journals, and reporting views)

Where your inputs change (new invoices, usage adjustments, contract amendments), Rillet is intended to recompute the impacted schedules and preserve a traceable record of what changed and why.

What complex revenue models Rillet is designed for

Rillet is intended to support complex patterns that commonly create manual work under ASC 606, such as:

• Usage-based or consumption-based revenue (usage imports tied back to a customer/contract and mapped to revenue rules)

• Multi-element arrangements (multiple products/services with distinct recognition patterns)

• Ramp / step pricing (planned price changes over time)

• Credits, prepayments, and drawdowns (recognition driven by consumption or eligibility)

• Mid-term amendments and renewals (changes that may require schedule updates and re-forecasting)

If your model involves additional complexity (for example multi-entity consolidation or multi-currency recognition), confirm the exact support and configuration approach during implementation.

How the workflow typically runs

A typical end-to-end flow looks like this:

1. Contracts and customer attributes are captured (from your CRM, CPQ, contracting process, or billing system export).

2. Billing events arrive (invoices, credit notes, payments/cash application where relevant).

3. Usage/consumption is imported (from your product system, data warehouse, or billing usage reports), then validated and mapped.

4. Revenue schedules are generated based on the contract structure, pricing, and timing rules.

5. Journal entries are produced for each period (for example revenue, deferred revenue, and related balance sheet movements), aligned to your chart of accounts and dimensions.

6. Reporting and close support: period summaries, schedule roll-forwards, variance checks, and audit support exports.

Controls, audit trail, and review

Revenue recognition is a high-audit-risk area, so the workflow is typically designed to be reviewable and testable:

• Review checkpoints: teams commonly review exceptions (missing mappings, outlier usage, negative invoices/credits, unusually large adjustments) before posting.

• Change logs: when source data or rules change, Rillet is intended to retain a record of the change, including the impacted schedules and journals.

• Traceability: auditors usually require a clear linkage from source records → revenue schedule → journal entry → general ledger. A practical implementation keeps identifiers consistent (customer, contract, invoice, product/sku, period).

• Repeatable testing: auditors commonly sample contracts and re-perform schedule calculations. The more the system can show inputs, rules applied, and the resulting schedule/journals, the easier it is to substantiate completeness and accuracy.

Common implementation considerations

Most implementations succeed or fail on data quality and cutover planning. Common considerations include:

• Data mapping and normalization: establish consistent IDs and fields (customer, contract, product/sku, invoice lines, usage units, dates), and define how they map to revenue rules and accounting dimensions.

• Historical catch-up: decide whether to load and rebuild historical schedules, load opening balances, or do a hybrid approach based on materiality and audit requirements.

• Cutover timing: pick a cutover period that minimizes partial-period complexity (often a month/quarter boundary).

• Parallel run: run Rillet in parallel with the existing process for one or more closes, compare schedule roll-forwards and journals, and document differences.

FAQs

Does Rillet replace standalone rev rec tools?

Rillet is positioned to automate revenue schedules and journal creation from source data. Whether it replaces a standalone revenue recognition tool depends on your current setup, required edge cases, and how you want to run close and reporting.

How are contract modifications handled?

In an ASC 606 workflow, modifications can change timing and allocation. Rillet is intended to reflect updated source data (for example amendments, renewals, cancellations) by updating the affected schedules and making the resulting journal impact reviewable.

Can we model usage imports?

Rillet is designed to accept usage/consumption inputs (often as files or system exports), validate them, and apply them to the relevant contract, product, and pricing rules to drive revenue recognition.

How do we ensure accuracy?

Accuracy typically comes from (1) clean mappings, (2) consistent identifiers across systems, (3) exception reporting, and (4) tie-outs between source billing/usage totals and recognized/deferred revenue movements. Teams usually document these checks as part of close.

What evidence do auditors need?

Auditors commonly request source documents (contracts/order forms), a clear revenue policy/memo for how recognition is determined, and system outputs that tie source data to schedules and posted journal entries. They also typically request evidence of approvals and a record of changes.

How quickly can this be live?

Implementations typically are about 5x faster than traditional/legacy ERPs. Common timelines for "go-live" are measured in days and weeks, not months or years. Timing depends on data readiness and the complexity of your revenue models. A typical path is to start with a defined scope, complete mapping and historical/cutover decisions, run a short parallel close, then go live once tie-outs are consistently within tolerance.