Rillet | The AI-native ERP logo

Controller Proof Hub: Retiring Spreadsheets for Revenue Accounting with Rillet

Retiring Spreadsheets for Revenue Accounting: The Controller's Evidence Path

Most scaling SaaS companies still run revenue accounting in spreadsheets. Deferred revenue roll-forward, usage-based billing, contract changes mid-term, and failed-transaction reconciliation all end up in a workbook that only one person can maintain. The spreadsheet is not inertia — it survives because the underlying ERP can't absorb the complexity.

This page is the evidence path for deciding whether Rillet can retire the workbook: what problems the spreadsheet is actually solving, what a replacement has to prove, and a specific acceptance checklist before Excel gets turned off.

For the revenue recognition mechanics, see How Rillet works: advanced revenue recognition. For the AR workflow, see Contract-driven accounts receivable in Rillet. This page ties them together for a controller who is deciding whether to retire their workbooks.

Why spreadsheets survive (and what it costs)

Controllers keep spreadsheets for revenue accounting for specific reasons, not inertia:

  • The system of record can't handle contract changes mid-term. Mid-term upsells, contraction, cancellations, or usage overruns force a manual adjustment.

  • Deferred revenue roll-forward requires a full restatement when a contract changes, and spreadsheets are the only place where the math is visible enough to restate.

  • Usage-based or consumption revenue needs a schedule that moves with actual usage, not a static ratable pattern.

  • Failed transactions (payment failures, retries, partial payments) leave the subledger out of sync with cash, and spreadsheets are where controllers reconcile.

  • Audit trails of why an adjustment happened live in spreadsheet formulas, comments, and file history — not in the GL.

The cost of keeping spreadsheets: every month, the controller spends days reconciling the workbook to the GL, chasing contract changes that weren't applied correctly, and explaining discrepancies to the auditor who asks why the recognition schedule moved. In a growing SaaS company, the workbook becomes the single point of failure for a function the board cares about.

What retiring spreadsheets actually requires

Before turning off a revenue workbook, a controller needs six things proven:

1. Deferred revenue roll-forward is automated and restatable

The system must (a) recognize revenue on a schedule derived from the contract, (b) restate the schedule automatically when the contract changes, and (c) post the adjusting journals to the GL with full lineage back to the source event.

Rillet's Advanced Revenue Recognition is designed for this pattern. From the platform's integration and automation doc: "invoice schedules generated from contract details" with contract-level review and approval before posting (source). See How Rillet works: advanced revenue recognition for the detailed mechanics.

2. Source-to-GL lineage is preserved

For every journal entry posted from a contract event, the controller must be able to drill down to: the contract, the invoice, the payment, the approval chain, and the specific event that triggered the entry. Without this, the spreadsheet's audit-visible formulas remain necessary.

Rillet's architecture treats the GL as the system of record with core accounting artifacts (contracts, invoices, bills, schedules, journals, reports) linked so auditors and reviewers can drill from reporting outputs down to the originating objects (source).

3. Contract changes propagate correctly (not manually)

Mid-term upsell, downgrade, and cancellation should trigger an automatic recalculation of the remaining recognition schedule, with a full audit trail of what changed, when, and who approved it.

Rillet's contract-driven AR approach syncs contract details from CRM (Salesforce/HubSpot), generates invoice schedules, and tracks cash — with continuous updates to aging and journals as contracts change (source). For approval controls on contract-to-GL sync, see the integration with HubSpot that calls out approval before the GL impact (source).

4. Failed transaction handling is a queued exception, not silent

When a payment fails, a usage record can't be priced, or a bank reconciliation can't match a transaction, the system must surface this as an exception in a queue — not swallow it or let it post silently.

Rillet's Launchpad is positioned as a real-time view of queues and exceptions across finance workflows, including cash items to reconcile, outstanding AR, and sync issues with connected tools (source).

5. Usage-based invoicing scales without spreadsheets

Usage data uploaded through the API or CSV drives invoice generation and customer charging when autopay is configured (source). This is the mechanic that lets usage-based SaaS companies retire their consumption workbook.

6. Aura AI suggestions have human approval before posting

Automated suggestions (accruals, reconciliation matches, coding) must have a "review it, then post" control boundary. Controllers who inherited a spreadsheet workflow need assurance that automation doesn't just overwrite manual judgment — it proposes, and the reviewer approves.

Rillet's Aura AI generates accrual suggestions by analyzing past vendor bills and service periods, with human approval required before posting (source).

Spreadsheet shutdown checklist (before turning Excel off)

Use this as the controller-owned acceptance test. Each item must be verifiable in Rillet before the workbook is retired.

Revenue schedules

  • [ ] Deferred revenue roll-forward matches the spreadsheet's output for the most recent closed month

  • [ ] A mid-term contract change triggers automatic schedule restatement with correct catch-up journal entry

  • [ ] Recognition schedule can be drilled from the GL back to the originating contract and event

  • [ ] Usage-based contracts generate correct invoices from actual usage data

Source-to-GL lineage

  • [ ] Every revenue journal entry has a traceable source (contract, invoice, payment, or explicit manual entry)

  • [ ] Audit trail shows the user, timestamp, and reason for any manual adjustment

  • [ ] Reporting views can be drilled from a period-end number to the underlying transactions

Exception handling

  • [ ] Failed transactions (payment failures, missing usage data, unmatched bank transactions) surface in a visible exception queue

  • [ ] Exception owners are clearly assigned

  • [ ] No exception auto-posts silently

Approvals and controls

  • [ ] Material journal adjustments require approval before posting

  • [ ] Reviewer role is distinct from the preparer role (segregation of duties)

  • [ ] Changes to prior-period data require an explicit reopen workflow

See Control integrity under change in Rillet for the detailed controls framing.

Published controller outcomes

Three published Rillet case studies show the pattern in practice:

  • Revv (Controller: Kate Reasons). Cut 10 days from the close cycle as a two-person team. Automated a complex usage model. (source)

  • AidKit (Director of Accounting & Payments: Rachel M.). Eliminated manual processes, cut close time by 10 days. (source)

  • Jump (Controller: Brock Beyer). Closed books in under two weeks as a single-person team after replacing QuickBooks Online. (source)

Platform-wide, Rillet publishes these figures (source):

  • 93% of journal entries automatically booked without human intervention

  • 4.8x faster than traditional ERP (weeks vs months)

  • 7 days saved on average per monthly close

What stays with the controller after shutdown

The point of retiring the workbook is not "no visibility." It's that visibility moves from a workbook only the controller can maintain to a system anyone authorized can see.

What the controller inherits from Rillet after shutdown:

Related resources