Rillet | The AI-native ERP logo

How Rillet works: out of the box SaaS metrics

Overview

Rillet produces SaaS metrics by combining general ledger (GL) activity, connected operational systems, and accounting schedules (for example, deferred revenue and commissions) into a consistent, refreshable model. The goal is to compute common SaaS KPIs using the same sources finance already relies on for close, while still allowing drill-down to the underlying transactions and rules.

This page explains:

  • where the inputs come from (GL, integrations, schedules)

  • which metrics you can support (examples)

  • how metrics stay up to date alongside a continuous close

  • controls and auditability considerations

  • practical implementation steps

  • FAQs and common edge cases

What “out of the box SaaS metrics” means

In practice, SaaS metrics need three things to be useful:

  1. Standard definitions (for example, what counts as “churn” and which revenue base is used)

  2. Repeatable calculations (the same rules every period)

  3. Traceability (a path from the metric back to source data)

Rillet’s approach is to start from the GL as the financial source of truth and then incorporate customer-, contract-, and product-level detail from integrations when available. When a metric requires timing logic (for example, revenue recognition or commission amortization), schedules provide structured, auditable timing.

Data sources Rillet uses

Rillet’s metrics are computed from a combination of the following inputs.

1) GL data (core input)

Typical GL inputs include:

  • chart of accounts (COA) and account hierarchy

  • journal entries and transaction detail

  • trial balance / period balances

  • dimensions such as entity, department, class, location, project, or custom segments (as available in your accounting system)

GL-driven metrics are especially useful for:

  • GAAP or close-aligned reporting

  • multi-entity consolidation

  • reconciling metrics to financial statements

2) Integrations (to add operational context)

Integrations provide the operational attributes needed for SaaS metrics that cannot be derived from the GL alone. Examples of common inputs include:

  • customer and subscription objects (plan, seats/usage, start/end dates)

  • invoicing and collections status

  • CRM customer/account attributes (segment, region, owner)

  • product metadata (SKU, product family)

If a given integration is not available, many metrics can still be produced at an aggregate level using GL + schedules, with customer-level cuts added later.

3) Accounting schedules (timing and allocation)

Schedules structure time-based accounting logic in a way that is repeatable and reviewable, for example:

  • deferred revenue schedules (recognition over time)

  • prepaid and accrual schedules

  • commission capitalization and amortization schedules

  • contract-related allocations (when applicable)

Schedules help keep metrics aligned to close and support drill-down from a metric to the schedule line items that produced it.

Metrics Rillet can support (examples)

The exact set of metrics you support depends on which sources you connect and the definitions you choose. Below are common examples and what they typically require.

Revenue and recurring revenue metrics

  • Revenue (GAAP/close-aligned): typically from revenue accounts and revenue schedules

  • ARR / MRR (recurring revenue baseline): from subscription/billing data and/or revenue schedules, depending on your definition

  • Bookings: from contract/order data (often CRM + billing); may be reconciled to GL via deferred revenue movements

  • Billings: typically from invoicing/billing systems and/or AR-related GL activity

  • Deferred revenue rollforward: from deferred revenue accounts and schedules

Retention and churn metrics

  • Gross Revenue Retention (GRR) and Net Revenue Retention (NRR): usually require customer/subscription-level recurring revenue by period

  • Logo churn / customer retention: requires customer identifiers and start/end dates; can be sourced from CRM/billing

  • Expansion / contraction: requires period-over-period customer recurring revenue

Customer economics and efficiency metrics

  • CAC (Customer Acquisition Cost): typically from GL expense accounts tagged to acquisition (for example, sales & marketing) with optional segmentation from CRM

  • LTV / payback period: requires CAC inputs plus retention and recurring gross margin assumptions/inputs

  • Gross margin (overall and recurring): from revenue and COGS accounts, optionally combined with allocation rules

Growth and operational metrics (optional)

  • Headcount and headcount cost: from payroll/HR systems or GL

  • Revenue per employee: combines revenue with headcount

  • Pipeline coverage / conversion (sales analytics): primarily CRM-based, can be linked to financial outcomes

Inputs required (what you need to provide)

To get accurate, repeatable metrics, Rillet typically needs the following.

Required for close-aligned financial metrics

  • connection to your accounting system (GL transactions, balances, dimensions)

  • a mapping of relevant accounts (for example, revenue, COGS, S\&M, R\&D, G\&A, deferred revenue)

  • reporting calendar and entity structure

Required for customer-level SaaS metrics (ARR/MRR, retention)

  • a consistent customer identifier across sources (or a mapping)

  • subscription/contract attributes (start date, end date, plan/SKU, price, quantity/usage)

  • agreed metric definitions (for example, ARR based on “in-force” subscriptions vs billed amounts)

Required for schedule-driven metrics

  • schedule inputs (rules or source schedules) for deferred revenue, commissions, and other timing items

  • policies for start dates, term changes, mid-period prorations, and treatment of one-time fees

How metrics stay up to date with continuous close

Rillet keeps metrics current by aligning refresh to the same lifecycle finance uses for close:

  • Data sync cadence: metrics update when GL data and connected systems update (for example, after a new journal entry, invoice, or schedule update)

  • Incremental changes: when inputs change, only the affected periods and rollforwards need to be recomputed

  • Close status awareness: many teams treat closed periods as locked (with controlled reopenings). Metrics can follow the same pattern so historical values remain stable unless a period is reopened.

Practical implication: when the GL and schedules are kept current during the month (continuous close), SaaS metrics based on them stay current as well—without waiting for a one-time month-end rebuild.

Controls and auditability

SaaS metrics are often used in board reporting and external stakeholder conversations. The calculations should be explainable and reproducible.

Common control points include:

  • Definition documentation: each metric’s definition, filters, and inclusions/exclusions are recorded (for example, what revenue base is used for NRR)

  • Account and attribute mappings: a controlled mapping from COA/dimensions to metric categories (for example, which accounts count toward CAC)

  • Change tracking: an audit trail of mapping and definition updates (who changed what and when)

  • Reconciliation checks: tie-outs from metric totals back to GL totals (for example, revenue rollforward vs revenue accounts)

  • Drill-down: the ability to trace a metric to source transactions and schedule line items

  • Access controls: permissions to restrict who can edit definitions vs who can view outputs

Implementation steps (typical)

  1. Connect the GL

  2. confirm entities, calendar, dimensions, and historical periods required

  3. Define a metric scope

  4. pick the first set of metrics (for example, revenue, ARR, NRR, CAC) and the reporting cuts (entity, segment, product)

  5. Map accounts and dimensions

  6. tag revenue/COGS and operating expense accounts; define CAC categories; define segment rules

  7. Connect operational systems as needed

  8. billing/subscription data for ARR/MRR and retention; CRM for segmentation; payroll/HR for headcount metrics

  9. Set up schedules (if applicable)

  10. deferred revenue and commission schedules; confirm policies for modifications and prorations

  11. Validate and reconcile

  12. compare outputs to known reports, prior board decks, and GL tie-outs

  13. Operationalize refresh and governance

  14. define refresh cadence, close/lock behavior, owners, and a change process for metric definitions

FAQs

Can we use our existing metric definitions?

Yes. The most important requirement is that definitions are explicit (inputs, filters, timing rules). Rillet can support custom definitions as long as the required source fields exist.

Are metrics GAAP-aligned or billing-aligned?

They can be either, depending on definition. Revenue and margin are typically close-aligned (GL/schedules). ARR/MRR and retention are often operationally defined and may come from subscription/billing data; many teams also maintain a reconciliation to the GL.

How do you handle multi-entity and multi-currency?

When the GL provides entity structure and currency context, metrics can be computed per entity and consolidated. For FX treatment, align to your finance policy (for example, period-average vs spot) and ensure the same approach is applied consistently.

What happens if a period is reopened?

If a closed period is reopened and postings change, metrics for that period (and any dependent rollforwards) should be recomputed. A controlled reopen/reclose process helps keep historical reporting stable.

Can we override or adjust a metric?

Many teams support controlled adjustments (for example, excluding a one-time item from an operational KPI) as long as the adjustment is documented and traceable. Prefer adjustments that are rule-based rather than manual one-offs.

What if we don’t have a billing/subscription integration?

You can still produce close-aligned metrics from the GL (for example, revenue, margin, expense-based CAC) and add ARR/MRR and retention once subscription-level data is connected or provided in a structured feed.