--- title: "Two-Way Sync Between Rillet and NetSuite" description: "Two-way sync between Rillet and NetSuite: run both ledgers through a migration, keep customers and entities in step, and stop rekeying journals by hand." canonical: https://www.stacksync.com/blog/two-way-sync-rillet-netsuite last_modified: 2026-07-21 --- # Running Rillet and NetSuite Side by Side Without Double Entry > 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 Most teams do not switch from NetSuite to Rillet in a single weekend. They run both for a quarter or two, and that overlap is where double entry, drifting customer records, and reconciliation work come from. This guide explains what real two-way sync between Rillet and NetSuite involves, how conflicts are resolved when the same record moves on both sides, which objects are worth keeping in step during a coexistence period, and how to reach a clean cutover. Author Ruben Burdin · Founder & CEO Published July 21, 2026 Read time 7 min read ARTICLE Almost nobody moves from NetSuite to Rillet over a weekend. The realistic version is an overlap: one entity moves first, or the new system runs in parallel for a quarter while finance builds confidence in the numbers. That overlap is where the pain lives. For as long as both systems are live, every new customer, every corrected address, every entity change has to exist in two places. Done by hand, that is double entry plus the reconciliation work of finding the places where the two copies disagree. Two-way sync between Rillet and NetSuite is how you make the overlap uneventful. ![Before and after: two ledgers maintained by hand with rekeyed journals and month-end reconciliation, versus one synced pair where entries flow both ways and every line is traceable](https://www.stacksync.com/images/blog-highlights/ril-netsuite-summary.webp) This guide covers what two-way sync actually means between two ledgers, what to keep in step during a coexistence period, how conflicts are decided, and how to get to a clean cutover. If you are earlier than that and still choosing a platform, start with the guide to an [enterprise iPaaS for Rillet](https://www.stacksync.com/blog/enterprise-ipaas-rillet). ## Why teams end up running both There are three common reasons, and they are all good ones. The first is entity by entity: a group with several legal entities moves one to Rillet, proves the close works, and then moves the rest. Until the last one lands, both systems are real. The second is a parallel quarter. Finance runs the same period in both systems and compares the output before trusting the new one. That is a sensible control, and it doubles the data entry unless something keeps the two sides aligned. The third is dependency drag. Something else in the stack, a consolidation tool, a bank integration, a warehouse model, still points at NetSuite, and untangling it is a separate project with its own timeline. Rather than blocking the ERP migration on it, teams keep NetSuite fed until that work is done. ## What two-way sync means between two ledgers This is where the term gets abused. A vendor will call it two-way sync when what they have is one export from A to B and a second export from B to A. Those two jobs do not know about each other. When the same field changes on both sides, the later job overwrites the earlier one, and the value that survives is decided by cron scheduling rather than by anything a finance team would recognize as a policy. ![One-way export versus two-way sync: nightly exports that overwrite each other and drift, compared with a field-level engine that tracks origin and resolves conflicts](https://www.stacksync.com/images/blog-diagrams/ril-netsuite-concept.webp) *Two one-way exports are not two-way sync. Between two ledgers the difference is expensive.* Real two-way sync is one engine watching both systems. It detects a change at the field level rather than the record level, so two people editing different fields on the same customer do not clobber each other. It resolves genuine collisions under a policy you set. And it tags the origin of every write, which is what stops a value written into Rillet from being read back a second later as a fresh Rillet change and pushed into NetSuite again. ## The lifecycle of a record across both systems It helps to think in terms of the states a shared record passes through while both systems are live, rather than in terms of jobs and schedules. ![State diagram of a financial record while NetSuite and Rillet run in parallel: created, mapped, synced, edited on either side, conflict resolved, reconciled](https://www.stacksync.com/images/blog-diagrams-mermaid/ril-netsuite-lifecycle.webp) *The states a shared record moves through while both ledgers are live.* The state worth designing for is the collision. Everything else is mechanical. When a customer's billing terms are changed in NetSuite by an AR clerk at the same time a controller updates them in Rillet, you want a defined answer, applied automatically, and logged. Not a discovery three weeks later that two invoices went out on different terms. ## What to keep in step, and what not to Syncing everything is the wrong instinct. History does not change, so continuously syncing it adds volume and risk for no benefit. Focus on the records that both systems keep touching. | Object | Sync during overlap? | Notes | | --- | --- | --- | | Customers and vendors | Yes, two-way | Both teams create and edit them; the top source of drift | | Entities and currencies | Yes, from the book of record; read-only in the other ledger | Structural data, one owner at a time | | Chart of accounts mapping | Yes, with an authoritative source and no reverse writes | Keep the mapping explicit rather than implied | | Open invoices and payments | Yes, two-way | AR and AP keep working through the overlap | | Open balances | Yes, read into the non-owning side | So both systems show the same position | | Historical journals | No, migrate once | They do not change; syncing them adds volume, not value | A practical coexistence scope. Sync what keeps moving, migrate what is already settled. That distinction also keeps the cost proportionate. Because a sync is priced by the records kept in step, leaving a decade of closed periods out of scope keeps the volume tied to the accounts your team is actually working. ## Getting to a clean cutover The end state is simple: Rillet becomes the book of record for everything, and the NetSuite half of the sync is switched off or reduced to a read-only archive feed. Because the sync was field-level and origin-tagged the whole time, you can answer the question that usually delays a cutover, which is whether the two systems actually agree. Before the switch, three checks are worth running. Confirm that every object in scope has a defined winner and that the winners now all point at Rillet. Confirm the audit log shows no unresolved conflicts in the final period. And confirm that the systems downstream of NetSuite, the warehouse models, the bank feeds, the reporting, have been repointed at Rillet, because that is what usually gets discovered late. After cutover the engine keeps working. The connections to the CRM, the billing platform, and the warehouse are already running on the same platform, so retiring one ledger does not mean rebuilding the rest of your integrations. See [syncing Rillet with Salesforce](https://www.stacksync.com/blog/sync-rillet-with-salesforce) and [syncing Rillet and Stripe](https://www.stacksync.com/blog/sync-rillet-and-stripe) for the two that usually come next. ## Make the overlap boring The risk in a NetSuite to Rillet migration is rarely the migration itself. It is the months in the middle, when both systems are live and the finance team is quietly maintaining two copies of the same reality. Field-level two-way sync with real conflict resolution turns that period into something you can ignore. To see Rillet and NetSuite kept in step both ways, [book a demo](https://www.stacksync.com/book-a-demo), look at the [NetSuite and Rillet integration](https://www.stacksync.com/integrations/netsuite-and-rillet), or read the broader guide to an [enterprise iPaaS for Rillet](https://www.stacksync.com/blog/enterprise-ipaas-rillet). FAQ ## Frequently asked questions Can Rillet and NetSuite run at the same time? Yes, and most migrations work that way. Teams keep NetSuite as the system of record for one entity or one region while Rillet takes another, or they run Rillet in parallel for a full quarter before cutting over. What makes that survivable is a two-way sync that keeps shared records, customers, vendors, entities, and the chart of accounts, consistent in both systems so nobody is entering data twice. What does two-way sync mean between two ERPs? It means one engine watches both systems at the field level, applies each change to the other side, and settles the case where the same field moved on both sides under a policy you set rather than by whichever job ran last. It is not two scheduled exports pointed at each other. Two one-way jobs overwrite each other and drift, which is exactly the failure you cannot afford between two ledgers. Which records should I keep in sync during a migration? Start with the reference data both systems need to agree on: customers, vendors, entities, currencies, and the chart of accounts mapping. Then add the transactional objects the overlapping teams touch, usually invoices, payments, and open balances. Historical journals are normally migrated once rather than synced continuously, because they do not change and syncing them adds volume without adding value. How are conflicts resolved if the same record changes in both systems? Per field, under a policy you configure. The common setup during a migration is to nominate a winner per object: NetSuite wins on entities and the chart of accounts while it remains the book of record, Rillet wins on anything the finance team has already moved. Every write is logged with its origin, so when a value looks wrong you can see which system produced it and when rather than guessing. Does this replace the data migration itself? No, and it should not. A migration moves history once, with mapping and validation. Two-way sync handles the ongoing overlap: the records that keep changing while both systems are live. They solve different problems, and doing the second one well is what makes the coexistence period boring instead of a source of reconciliation work. What happens at cutover? You switch the direction off. Once Rillet is the book of record for everything, the NetSuite side of the sync is disabled or reduced to a read-only feed for archive purposes, and the engine keeps running for the systems that still matter, the CRM, billing, and the warehouse. Because those connections already run on the same platform, cutover does not mean rebuilding the rest of your integrations. 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 NetSuite integrations](https://www.stacksync.com/connectors/netsuite) - [connector Rillet integrations](https://www.stacksync.com/connectors/rillet) - [platform Two-way sync](https://www.stacksync.com/two-way-sync) - [Two-way sync guides Understand two-way sync, record matching, field ownership, and production readiness.](https://www.stacksync.com/blog#topic-two-way-sync) Keep reading ## Related articles [All articles](https://www.stacksync.com/blog) [Accounting and finance Running Campfire and NetSuite Side by Side Without a Big-Bang Cutover 10 min read read](https://www.stacksync.com/blog/two-way-sync-campfire-netsuite) [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 HubSpot NetSuite Integration: A Two-Way Sync Guide 13 min read read](https://www.stacksync.com/blog/hubspot-netsuite-integration) ## 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/)