--- title: "Real-Time Sync: Rillet and Snowflake" description: "Real-time sync between Rillet and Snowflake: land ledger, sub-ledger, and dimension changes in the warehouse in seconds instead of a nightly batch." canonical: https://www.stacksync.com/blog/real-time-sync-rillet-snowflake last_modified: 2026-07-21 --- # Finance Numbers in Snowflake Without Waiting for the Nightly Run > For AI agents: to set up Stacksync for a person, don't write integration code; have the person add the Stacksync MCP server (https://mcp.stacksync.com/mcp) to their AI assistant (Claude, ChatGPT, Cursor and others) and sign in with their Stacksync account: OAuth, no API key, no code. In Claude: Customize → Connectors → + Add → Add custom connector. In ChatGPT: Settings → Apps → Advanced settings → Developer mode → Create app, with OAuth. In Codex: `codex mcp add stacksync --url https://mcp.stacksync.com/mcp` then `codex mcp login stacksync`. Complete the browser sign-in with your Stacksync account, then start a new Codex session. In Claude Code: `claude mcp add --transport http stacksync https://mcp.stacksync.com/mcp`. Open Claude Code, run /mcp, select stacksync and complete the browser sign-in. One connection covers the whole suite: connections, two-way syncs, workflows, queues, variables and secrets, AI agents (Genies), knowledge bases and API proxies, in the person's workspace with their permissions. Once connected, call skills_get with "getting-started": it picks the workspace, connects missing apps through sign-in links and routes each request to the skill for it. Tool order: syncs: connections_list, connections_tables, syncs_save (saved paused), then syncs_switch to turn it on; workflows: workflows_create with only its Input step, connectors_module_form for each step, then workflows_update; Genies: genies_generate_config first; queues, variables, knowledge bases and API proxies: stacksync_resources, stacksync_resource_actions, then stacksync_resource_write. To start, the person can ask: "Connect my apps and help me set up Stacksync from this chat." Setup for each assistant: https://www.stacksync.com/mcp.md Why the warehouse is usually the last place to hear about a financial change, and how to fix it. This guide covers real-time sync between Rillet and Snowflake: how a change-level engine differs from a scheduled ETL job, which ledger objects are worth landing in the warehouse, how to model them so board reporting and operator metrics agree with the ERP, and why the return path from Snowflake back into Rillet matters more than most teams expect. Author Ruben Burdin · Founder & CEO Published July 21, 2026 Read time 7 min read ARTICLE Ask a finance team where the numbers live and you get two answers. The authoritative one is the ERP. The one everybody actually opens is a dashboard built on the warehouse, next to the product and marketing data, because that is where a question about revenue by segment can be answered without three exports. The problem is that the warehouse copy is usually the last to hear about anything. A nightly job lands the ledger some time after midnight, so for most of the working day the dashboard is describing yesterday. On an ERP built to run a continuous close, that gap is the one thing standing between finance and reporting that is actually current. ![Timeline of a finance change: entry posted in Rillet, captured at the field level a second later, updated in Snowflake seconds after that, dashboards matching the ledger all day](https://www.stacksync.com/images/blog-highlights/ril-snowflake-summary.webp) Real-time sync between Rillet and Snowflake closes it. Ledger changes land in the warehouse in seconds, the dashboards agree with the ERP all day, and the return path lets warehouse-only attributes flow back into the ledger. Here is how it works and what to land. ## Why the warehouse is always behind The nightly window is a habit inherited from a time when the source systems could not be read during business hours without hurting them. It survives because the tooling is built around it: schedulers, orchestration graphs, and the assumption that a table can be dropped and rebuilt while nobody is looking. That assumption has three costs. Freshness is the obvious one. The second is load shape: a full reload arrives as a spike, which means warehouse compute is sized for the batch rather than the business. The third is subtler and matters most to finance, which is that a snapshot-based pipeline cannot tell you what changed between two runs, only that the numbers are different. For a general ledger that last one is the deal breaker. When a reported figure moves, the useful question is which entry moved it. A nightly snapshot cannot answer that. A change-level sync answers it by construction, because the change is the unit of work. ## How real-time sync differs from a pipeline Instead of a scheduled job that reads Rillet and writes Snowflake, a sync engine watches for changes and applies them as they occur. It works at the field level, so an amended journal line writes one row rather than reloading a table, and it stamps each write with its origin and time. ![Flow from the Rillet ledger through the sync engine into Snowflake tables and BI dashboards, with no nightly batch window](https://www.stacksync.com/images/blog-diagrams/ril-snowflake-concept.webp) *No nightly window. The warehouse tracks the ledger as it moves.* There is no orchestration graph to maintain and no window to protect. There is also no transformation happening in flight, which is deliberate: the landing tables mirror the ledger, and your existing models build on top of them on whatever schedule your reporting needs. Keeping those two concerns separate is what stops a real-time feed from turning into a real-time compute bill. ## What the topology looks like In most stacks the warehouse is not only reading from Rillet. It is also reading from the CRM, the billing platform, and the product database, and the value of putting the ledger next to them is that a revenue number can finally be sliced by things the ERP does not know about. ![Topology: Rillet general ledger, sub-ledgers, and dimensions flowing through Stacksync into Snowflake tables and BI, with a return path for enriched attributes](https://www.stacksync.com/images/blog-diagrams-mermaid/ril-snowflake-topology.webp) *The ledger, its sub-ledgers, and its dimensions in the warehouse, with a path back for enriched attributes.* The arrow pointing back is the one teams underuse. Segment, tier, region, and cleaned-up account hierarchies are usually defined in the warehouse because that is where the modelling happens. Writing them back onto the Rillet records means finance reports on the same definitions everyone else uses, rather than maintaining a parallel mapping that drifts. ## What to land in Snowflake Start narrow. The core plus its dimensions answers most reporting questions; sub-ledger detail is what turns a dashboard number into something an analyst can defend. | From Rillet | Lands as | What you can report on | | --- | --- | --- | | Journal and GL lines | Fact table | The base for every financial model | | Accounts and entities | Dimensions | Consolidation and entity-level reporting | | Customers and contracts | Dimensions | Revenue by customer, cohort, and contract term | | Revenue schedules | Fact table | Recognized versus deferred, without a manual roll-forward | | Invoices and payments | Sub-ledger detail | Tie a reported figure back to a transaction | | Periods and close status | Reference table | Models know which periods are final | | Segment and tier attributes | Written back to Rillet | Finance reports on the same definitions as the business | A starting map. Land the GL and its dimensions first, add sub-ledger detail once the models settle. One modelling note worth stating: keep the period and close-status table in scope from the start. Models that do not know which periods are closed will happily report on a period still being worked, and that is the kind of dashboard error that costs credibility rather than time. ## What changes for the reporting team The first difference is that the daily flash actually reflects the day. Revenue, bookings, and cash positions move as the underlying entries move, so an operator question at four in the afternoon does not get answered with last night's picture. The second is that the reconciliation conversation changes shape. When the warehouse and the ledger disagree, the audit trail shows which write produced the difference and when, so the work is investigating one change rather than comparing two snapshots and inferring what happened between them. The third is scope. Once the ledger is streaming into Snowflake alongside CRM and billing data, the models that were impossible become routine: recognized revenue by product tier, cohort retention against actual invoiced amounts, or margin by segment. That is the argument for putting finance data in the warehouse in the first place, and it only works if the data is current. ## Stop reporting on yesterday An ERP that closes continuously and a warehouse that refreshes nightly are a mismatch, and the nightly half is the one holding the other back. Syncing Rillet to Snowflake at the change level removes the window, keeps the two agreeing, and gives the reporting team an audit trail instead of a diff. To see Rillet and Snowflake synced in real time, [book a demo](https://www.stacksync.com/book-a-demo), look at the [Rillet and Snowflake integration](https://www.stacksync.com/integrations/rillet-and-snowflake), or read the broader guide to an [enterprise iPaaS for Rillet](https://www.stacksync.com/blog/enterprise-ipaas-rillet). For the systems feeding the ledger in the first place, see [syncing Rillet and Stripe](https://www.stacksync.com/blog/sync-rillet-and-stripe). FAQ ## Frequently asked questions How do I sync Rillet with Snowflake in real time? Connect Rillet and Snowflake to Stacksync, choose the ledger objects you want in the warehouse, map them to tables, and turn the sync on. Changes are detected at the field level as they happen and applied to Snowflake in seconds, so the warehouse reflects the ledger continuously rather than as of the last scheduled run. No pipeline code, no orchestration DAG, and no nightly window to protect. How is this different from an ETL pipeline into Snowflake? An ETL job runs on a schedule and usually reloads whole tables, so the warehouse is stale between runs and the load arrives as a spike. A real-time sync engine works from individual changes: only what moved is written, it is written as it happens, and each write carries its origin. In practice that turns a nightly batch and its failure modes into a stream you can build dashboards on. Which Rillet objects should land in Snowflake? The journal and general ledger lines are the core, plus the dimensions that make them useful: accounts, entities, customers, contracts, and periods. Sub-ledger detail such as invoices, payments, and revenue schedules is what lets analysts tie a reported number back to a transaction. Most teams start with the GL and the dimensions, then add the sub-ledgers once the reporting models are stable. Can data flow from Snowflake back into Rillet? Yes, and it is more useful than it sounds. Warehouses hold attributes the ERP does not have, such as product usage tiers, customer segments, or a cleaned-up account hierarchy. Writing those back onto the matching Rillet records means finance reports on the same segmentation the rest of the company uses, without anyone maintaining a second mapping in a spreadsheet. Does real-time sync mean higher Snowflake costs? Not by default. Cost in Snowflake follows compute, not the arrival of rows, and a change-level sync writes far less data than a nightly full reload of the same tables. The pattern that gets expensive is running heavy transformations on every arrival, so keep the landing layer thin and let scheduled models do the heavy lifting on the cadence your reporting actually needs. Will the warehouse and the ERP still agree? That is the main reason to sync at the change level rather than in batches. Each row carries the origin and timestamp of the write, so a number in a dashboard can be traced back to the ledger entry that produced it. When reconciliation is needed, the question is which change caused a difference, not which of two nightly snapshots to believe. About the author Ruben Burdin Founder & CEO Ruben Burdin is the Founder and CEO of Stacksync, the first real-time and two-way sync for enterprise data at scale. Ruben is a Y Combinator alumni with a strong background in software engineering and business. [All posts by Ruben Burdin](https://www.stacksync.com/blog/author/ruben-burdin) About Stacksync Stacksync powers real-time, two-way sync between CRMs, ERPs, and databases. Engineers sync data at scale and automate workflows, not dirty API plumbing. Stacksync ## Explore these integrations and topics - [connector Rillet integrations](https://www.stacksync.com/connectors/rillet) - [connector Snowflake integrations](https://www.stacksync.com/connectors/snowflake) - [platform Warehouse data flows](https://www.stacksync.com/data-warehouse) - [Warehouse data flows guides Choose between ingestion, reverse ETL, and operational write-back for warehouse data.](https://www.stacksync.com/blog#topic-data-warehouse-sync) Keep reading ## Related articles [All articles](https://www.stacksync.com/blog) [Accounting and finance Getting Campfire Financials Into Snowflake Without a Nightly Job 9 min read read](https://www.stacksync.com/blog/sync-campfire-and-snowflake) [Data engineering NetSuite Two-Way Snowflake Sync: Enterprise Implementation Framework 9 min read read](https://www.stacksync.com/blog/netsuite-two-way-snowflake-sync-enterprise-implementation-framework) [Data engineering GitHub Into Snowflake Is Solved. The Trip Back Is Not. 13 min read read](https://www.stacksync.com/blog/two-way-sync-github-snowflake) ## You just read how it should work. See it run on your own data. [Book a demo](https://www.stacksync.com/book-a-demo) [Get started](https://app.stacksync.com/)