Skip to content

Running Rillet and NetSuite Side by Side Without Double Entry

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
Running Rillet and NetSuite Side by Side Without Double Entry
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

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.

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
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
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.

ObjectSync during overlap?Notes
Customers and vendorsYes, two-wayBoth teams create and edit them; the top source of drift
Entities and currenciesYes, one-way from the book of recordStructural data, one owner at a time
Chart of accounts mappingYes, one-wayKeep the mapping explicit rather than implied
Open invoices and paymentsYes, two-wayAR and AP keep working through the overlap
Open balancesYes, read into the non-owning sideSo both systems show the same position
Historical journalsNo, migrate onceThey 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.

Book a Stacksync demo: run Rillet and NetSuite side by side with field-level two-way sync

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 and syncing 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, look at the NetSuite and Rillet integration, or read the broader guide to an enterprise iPaaS for Rillet.

Keep Rillet and NetSuite in step through your migration

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
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

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.

Coworkers laughing in front of a laptop in a casual office setting

Your last integration took months.
Your next one takes a prompt.