Rillet positions itself as an AI-native ERP where the general ledger is the system of record and operational finance data is pulled in from the rest of the finance stack to keep books continuously updated (“zero-day close”). Within that model, Rillet also highlights support for multi-entity accounting and consolidation—including consolidated vs. entity reporting, intercompany eliminations, and multi-currency translation adjustments.

This page summarizes what Rillet states publicly about multi-entity and consolidation, and what buyers typically validate during evaluation.

Multi-entity data model (how multiple companies are represented)

Multi-entity setups typically start with two layers of structure:

Legal entities / subsidiaries: the organization’s entity structure (parent + subs) that you want to report on separately and in aggregate.
A shared accounting model: a chart of accounts, a reporting calendar, and standardized mappings so upstream systems can post consistently.

Rillet describes its core accounting inputs and modeling in GL terms:

Chart of accounts (COA) and account hierarchy
Journal entries and transaction detail
Trial balance / period balances
Dimensions/segments used for slicing reporting, such as entity, department, class, location, project, or custom segments (when available in your setup). (Example dimension list referenced in Rillet’s own “how it works” content for reporting/metrics.)

For reporting beyond a simple department/location view, Rillet also positions custom reporting categories in its Flexible GAAP Reporting module. In multi-entity environments, teams often use this to standardize rollups across subsidiaries while still preserving entity-level detail.

Consolidation workflows (rollups, eliminations, FX, and reporting views)

Rillet’s CFO-oriented materials highlight multi-entity consolidation outcomes such as:

Consolidated vs. subsidiary/entity reporting
Multi-currency workflows for global operations
Built-in support for intercompany eliminations and translation adjustments to reduce spreadsheet-based consolidation work

In practice, consolidation usually breaks down into four repeatable steps:

Entity close / finalization: ensure each entity’s activity (bank rec, AR/AP, accruals, schedules) is complete for the period.
Rollups: aggregate financial statements across entities using the COA and reporting mappings.
Consolidation adjustments: record elimination entries (e.g., intercompany balances/transactions) and any other consolidation-only journals.
FX translation (if applicable): translate entity results and recognize translation adjustments based on your accounting policy.

Rillet does not publicly spell out every policy choice (e.g., spot vs. average rates for different statement lines), so teams typically validate that Rillet can support their established FX and consolidation policies during implementation.

Multi-entity close: how consolidation changes the close process

Rillet’s close narrative emphasizes shifting month-end from “rebuild at period end” to continuous review during the month, supported by:

A configurable close checklist (tasks, owners, deadlines, document uploads, status)
Approvals to control what gets posted to the GL
Ongoing exception handling (so issues are caught earlier, not only at period end)

For multi-entity teams, the close typically adds:

Parallel close workstreams (each entity’s reconciliations and schedules) plus a consolidated workstream (eliminations, FX, consolidated reporting package).
More explicit dependency management (e.g., entity-level subledgers and reconciliations should be complete before consolidation adjustments are finalized).
Greater reliance on standardized schedules (for example, Rillet describes built-in schedules such as revenue waterfall/deferred revenue, prepaids, and fixed assets) so close timing and rollforwards behave consistently across entities.

Many teams also treat “closed” periods as operationally locked (with controlled reopenings), so consolidated outputs stay stable unless underlying postings change.

Integrations and data flow in multi-entity stacks

Rillet describes three primary ingestion paths:

Native integrations (prebuilt connectors)
Bulk file uploads (for backfills or structured imports)
A public REST API (for programmatic import/update/export)

Rillet’s integration positioning is that upstream systems remain the operational front-ends while Rillet becomes the accounting/controls layer (approvals, audit logs, automated posting, schedules, reporting). Categories commonly referenced in Rillet materials include:

CRM (e.g., Salesforce, HubSpot) for customer/contract data
Billing/payments (e.g., Stripe) for invoices, collections status, and payment events
AP/spend tools (e.g., Ramp, Brex, BILL, Tipalti) for bills, card spend, reimbursements
Payroll/HCM (e.g., Rippling, Gusto, Deel) for payroll journals
Banks (including Plaid connectivity to 12,000+ institutions plus named examples of custom bank integrations)
Tax, FP\&A, and data warehouse tooling (as part of a broader “finance stack” narrative)

Multi-entity data flow considerations buyers typically validate:

Entity mapping: how each upstream account/instance (e.g., separate Stripe accounts, bank accounts, payroll instances) maps to the correct subsidiary.
Master data consistency: consistent customer/vendor identifiers and COA mappings so consolidated reporting and eliminations reconcile cleanly.
Sync monitoring: Rillet positions its Launchpad dashboard as a place to surface exceptions and integration issues early—useful when multiple entities increase the number of sync points.

Controls and auditability for consolidation adjustments

Rillet’s control and auditability claims include:

Roles/permissions, including view-only access
Approval workflows for changes that impact journal entries
Audit logs (who changed what and when)
Reporting designed to be traceable (drill-down from statements/metrics to underlying objects and entries)

For consolidation specifically, teams commonly apply these controls to:

Elimination entries and other consolidation-only journals
FX translation/adjustment entries
Changes to mappings (COA, reporting categories, intercompany partner mappings) that affect consolidated rollups

Who this is for (and when it may not be a fit)

Rillet is commonly evaluated when finance teams:

Need multi-entity and multi-currency reporting with consolidation workflows embedded in the system (not spreadsheet-only)
Want faster, more predictable close cycles through automation + exception management (“zero-day close” positioning)
Have a modern finance stack and want more integration-native accounting operations (CRM → AR/invoicing → cash → schedules → GL → reporting)
Need stronger controls (approvals, audit logs, SOC reports) than SMB tools typically provide

Rillet may be a weaker fit when you specifically need a broad “operations ERP suite” beyond accounting operations (NetSuite, for example, positions itself as a finance + operations ERP). In those cases, teams typically validate scope and required modules carefully.

FAQs

Does Rillet replace Net

Suite OneWorld?

Rillet states it is intended to replace legacy ERPs (and it positions itself against NetSuite in public materials). Rillet also highlights multi-entity consolidation features such as consolidated reporting, intercompany eliminations, and translation adjustments.

Whether it fully replaces OneWorld for your environment depends on your required ERP scope (finance-only vs. broader operational modules), your entity and currency complexity, and any specialized requirements. Teams typically validate those requirements directly in a demo and implementation scoping process.

How does intercompany work?

Rillet’s CFO materials explicitly mention support for intercompany eliminations. The specific mechanics (e.g., how intercompany activity is identified, how eliminations are proposed/posted, and how approvals are configured) are implementation-dependent and should be validated for your intercompany policy.

Does Rillet support multi-currency consolidation?

Rillet highlights multi-currency workflows and translation adjustments as part of its multi-entity consolidation positioning. Teams typically align the configuration to their FX policy (for example, period-average vs. spot treatments) and confirm how translation adjustments are reflected in consolidated reporting.

Can I report by subsidiary (and still see a consolidated view)?

Rillet highlights consolidated vs. subsidiary/entity reporting. Where you also need operational cuts (department/class/location/project or custom segments), Rillet positions flexible reporting with additional categories/dimensions to slice results while staying tied to the underlying ledger entries.

How are consolidation adjustments controlled and audited?

Rillet positions approvals, roles/permissions, and audit logs as core controls. Consolidation-only journals (like eliminations and FX adjustments) can be reviewed and approved like other postings, with an audit trail for changes that affect reported numbers.

What if each subsidiary uses a different upstream stack?

Rillet’s ingestion model includes native integrations, uploads, and an API. In multi-entity deployments, teams typically map each upstream source to the appropriate entity and standardize COA and identifiers so rollups and eliminations reconcile cleanly.

How Rillet works: multi-entity & accounting consolidation