Finance teams don't struggle at close because of complexity. They struggle because the architecture is wrong.
There's a pattern that shows up consistently in SaaS companies running Salesforce and NetSuite. Somewhere between the two systems, business logic crept into the integration layer. A pricing rule here. A billing calculation there. A revenue workflow that needed to live somewhere and the middleware was the path of least resistance.
Each decision made sense at the time. Together, they create a problem that Finance pays for at every month-end close.
Why Does Business Logic End Up in the Integration Layer?
Integration platforms are powerful tools. MuleSoft, Celigo, Boomi, Workato — these are mature, capable systems built to move data reliably between Salesforce and NetSuite. That's exactly what they were designed to do.
The problem starts when they get asked to do more. When pricing logic doesn't fit cleanly into either Salesforce or NetSuite, the integration layer becomes a tempting home for it. Same with billing calculations that span both systems, or revenue workflows that need data from CRM and ERP simultaneously. It feels like the path of least resistance. A few months later it's causing Finance real pain.
What Goes Wrong When Business Logic Lives in the Wrong Place?
When logic gets distributed across systems, three versions of the same calculation start to exist simultaneously. Salesforce holds one version of pricing. NetSuite holds another. The integration tool holds a third. Each was built at a different time, by a different team, with a different set of assumptions. This is what we call the "Third System Problem" — and it's why the numbers never quite agree.
They mostly agree. Until they don't.
The disagreement surfaces at month-end close. Finance runs their reconciliation and the numbers don't match. Bookings show one figure in Salesforce. NetSuite shows another. Tracking down the discrepancy means going into three different systems, understanding three different versions of the same logic, and figuring out which one is right.
In a SaaS business with ramps, swaps, mid-contract amendments, and usage-based pricing, the problem compounds quickly. At scale, this isn't just a reconciliation issue. It's an audit risk and a revenue accuracy problem.
What Should Your Integration Layer Actually Do?
One thing. Move data.
The integration layer should be dumb. That's not a criticism, it's a design principle. Middleware exists to move data between systems reliably and efficiently. It shouldn't know what a ramp deal is. It shouldn't calculate a swap credit. It shouldn't hold revenue recognition logic.
The business logic belongs in the systems that were built for it. Salesforce manages the commercial process, pricing, contracting, customer lifecycle. NetSuite manages the financial process, invoicing, revenue recognition, general ledger. Each system owns its logic cleanly. The integration layer moves data between them.
What Does the Right Architecture Actually Look Like?
The boundary between Salesforce and NetSuite needs something purpose-built for that job. Not middleware that moves data. You need a system that understands how a contract change affects billing, revenue schedules, and financial reporting before the data ever hits NetSuite. That's not an integration platform. That's a different kind of infrastructure — one built for the boundary between commercial and financial systems, not retrofitted into the plumbing between them.
How Does Continuous Approach This?
At Continuous, we built our approach around a single principle: the integration layer stays dumb. It moves data. The business logic lives in the systems Finance and Sales already trust.
Continuous sits at the boundary between Salesforce and NetSuite as embedded revenue infrastructure. It ensures that what was priced, contracted, and agreed to in Salesforce is what executes in NetSuite — without being recalculated, reinterpreted, or lost in translation between systems.
Keep the integration layer dumb. Build the logic where it belongs.
Frequently Asked Questions
Why do Salesforce and NetSuite numbers not match at month-end close?
Because pricing, billing, or revenue logic is being calculated in multiple places — Salesforce, NetSuite, and the integration layer — creating conflicting versions of the same data.
What is the Third System Problem in Salesforce and NetSuite integrations?
It's when the integration layer becomes a hidden third system of logic, holding its own version of pricing or billing rules alongside Salesforce and NetSuite, causing drift between systems over time.
What should the integration layer do in a Salesforce and NetSuite architecture?
Move records between Salesforce and NetSuite accurately and reliably. It should transport data, not interpret contracts, calculate billing, or manage revenue logic.