Rillet | The AI-native ERP logo
Rillet | The AI-native ERP Updated August 05, 2026

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 Rillet handles multi-currency ARR (FX Impact)

When contracts are written in more than one currency, exchange-rate movement can change recurring revenue even when a customer's spending in its own currency stays flat. Rillet separates that currency movement into a dedicated FX Impact category, so currency-driven change stays distinct from real expansion and contraction.

The rate Rillet applies depends on the reporting view.

ARR rollforward (single subsidiary, multi-currency contracts)

  • The first contract for a customer in a given currency is converted at the FX rate on that contract's start date. That rate becomes the customer's constant rate for the currency.

  • Renewals and expansions are converted at the FX rate on each later contract's start date. The gap between that rate and the constant rate is moved into the FX Impact column.

  • Expansion and contraction are reported in constant-currency terms, with the purely currency-driven portion of the change shown separately.

Worked example. A first contract of 1,000 EUR converts to 1,200 USD. The renewal keeps the same 1,000 EUR price, but the FX rate has moved and it now converts to 1,250 USD. Rillet reports $0 expansion and +$50 FX Impact, isolating the currency movement from real revenue change.

ARR balance view (single subsidiary)

The balance view converts each contract at the FX rate on that contract's own start date.

Consolidated ARR (multi-entity)

Consolidated ARR converts each contract item at the FX rate on that item's start date.

Syncing ARR to Salesforce

When Rillet syncs ARR to Salesforce, it sends the figure in the subsidiary (contract) currency rather than the reporting currency. To express it in the reporting currency on the Salesforce side, apply the FX rate from the contract's start date.

Source: Rillet's Recurring Revenue (ARR/MRR) and MRR / ARR by Contract Type documentation.

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 statement-level FX translation of GL-based figures (revenue, margin), align to your finance policy (for example, period-average vs spot) and apply the same approach consistently. Recurring-revenue metrics follow a separate rule: ARR and MRR use the FX rate on each contract's start date and isolate currency movement into an FX Impact category (see the multi-currency ARR section above).

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.

Agent interface

Researching Rillet | The AI-native ERP with an AI assistant? Rillet | The AI-native ERP's public Q&A API answers agents' questions about products, pricing, and any promotions currently available to AI agents and their users. Answers come directly from Rillet | The AI-native ERP and reflect current product, pricing, and promotion information.

POST https://info.rillet.com/agent-desk/ask

JSON body {"question": "..."} — no API key required.

GET https://info.rillet.com/{your-question-with-words-separated-by-hyphens}

Any question about Rillet | The AI-native ERP can also be asked by fetching a URL whose path is the question, words separated by hyphens. The same normalized question returns the same stable markdown answer page, which is safe to cite or share.