Dental organizations don’t usually think of themselves as software companies. But the ones running subscription-based services across multiple locations, collecting recurring revenue, onboarding members through a CRM, reconciling into a bank feed and pushing payments through a processor most certainly are. They just don’t always build their NetSuite to reflect that.

Background

They were a multi-location dental services organization running a subscription-based revenue model. Members pay on a recurring basis, and the business manages those relationships across Salesforce , MX Merchant by Priority (their payment processor), a banking partner, and NetSuite, where the financial record lives.

It’s a model that works well when all the pieces are connected.

The NetSuite instance had been configured early, likely for a version of the business that was smaller and simpler. SuiteBilling was in place but hadn’t been fully built out to handle the billing complexity that came with growth. Revenue recognition was running through scripts that had accumulated over time without a coherent architecture underneath them. Integrations to external systems had been stood up without much review of whether they’d hold at scale.

None of this was unusual. It’s the pattern we see most often in organizations that grew faster than their ERP configuration kept pace with.

What We Came In to Fix

1. Revenue Recognition That Wasn’t Recognizing Revenue Correctly

The core issue was timing. Rev Rec dates on Sales Orders weren’t aligning with what the business actually needed, and the logic driving them was fragmented across multiple scripts without clear ownership.

We ran a full SuiteBilling and Rev Rec discovery assessment before writing a line of code. That’s not a default step for every firm. But when revenue recognition is broken and nobody has a clean map of why, the worst thing to do is start patching individual scripts. You end up with more fragments, not fewer.

The assessment gave us a clear picture of what was intentional, what was inherited, and what needed to be rebuilt. We then developed a custom SuiteScript to correct Rev Rec date logic on Sales Orders and aligned the broader SuiteBilling configuration to support accurate, defensible revenue recognition going forward.

2. A Payment Infrastructure That Was Failing in Too Many Places

The payment problems weren’t one problem. They were several, presenting in different parts of the system at the same time.

The client processes payments through MX Merchant, and the integration between MX Merchant and NetSuite had gaps that showed up in a few different ways. Credit cards were declining at a rate that pointed to something systemic, not just individual card failures. ACH payments weren’t tokenized, which created both operational and compliance exposure. The autopay process was generating errors when it encountered closed accounting periods. A CVV match requirement had been introduced upstream without the NetSuite configuration being updated to reflect it. And payment email receipts out of MX Merchant weren’t reliably reaching customers, which was creating unnecessary support volume.

On top of that, the customer onboarding flow into MX Merchant ran through Salesforce, and that handoff wasn’t clean. When a new member was set up in the CRM, the downstream process for getting them configured in MX Merchant and reflected correctly in NetSuite had manual steps where there shouldn’t have been any.

Each issue had its own fix. The CVV change required a configuration update. The autopay period errors needed logic that checked period status before attempting to post. ACH tokenization required building the tokenization process into the payment workflow. The email receipt failures got traced back to a configuration gap in the MX Merchant integration and resolved at the source.

The goal wasn’t just to close the tickets. It was to build payment infrastructure that didn’t generate the same tickets six weeks later.

3. Six Integrations That Weren’t Fully Working

The client was operating across six external platforms: Salesforce, Wells Fargo for banking, Ramp for corporate spend management, Swoogo for events, Power BI for analytics, and an ODBC connection for direct database access.

Not all of them were talking to NetSuite cleanly.

The Salesforce piece had two distinct problems. The first was the Sales Order flow: Salesforce was the system of record for new business, and Sales Orders were being pushed from SFDC into NetSuite. When that sync broke down, the financial record lagged the commercial one. The second was the customer onboarding process into MX Merchant, which was tangled up with the same integration and needed its own review. We mapped the full onboarding workflow, understood where it intersected with the SFDC-to-NetSuite Sales Order flow, and rebuilt the process so both moved cleanly and in the right sequence.

The Wells Fargo feed, Ramp connection, and ODBC setup each got their own review and stabilization work. Power BI required mapping NetSuite data correctly so the dashboards the finance team relied on were actually reflecting accurate numbers.

Six integrations, six separate stabilization workstreams. None dramatic. All necessary.

4. Reporting the Finance Team Couldn’t Rely On

The A/R Register wasn’t pulling. The Reconciliation Detail Report was surfacing clearing transactions that didn’t belong there. Report exports were failing intermittently. The finance team was doing extra work to compensate for what the system should have been doing automatically.

This is one of the more frustrating categories of NetSuite problems to deal with, not because the fixes are technically complex, but because the downstream cost is so high. A finance team that can’t trust its reports starts doing manual verification work. That work doesn’t show up anywhere in the system. It just accumulates as invisible overhead.

We restored A/R Register functionality, cleaned the clearing transaction logic in the reconciliation report, and rebuilt the export configuration so it ran reliably. Then we built saved searches that made it easy to verify the system was working correctly on an ongoing basis, without needing someone to run a manual check to confirm it.

5. Workflows and Billing Architecture That Had Grown Without a Plan

Beyond the acute issues, there was a set of structural gaps that had accumulated over time.

Approval workflows existed but weren’t comprehensive. Item inactivation after events wasn’t automated, which meant the item master was growing with records it no longer needed. The billing account structure wasn’t connecting cleanly to invoice generation workflows, which created manual work downstream every billing cycle.

We built out the approval workflow architecture, created automated inactivation logic triggered by event status, and rebuilt the billing account consolidation process so invoices generated consistently and without manual intervention.

These weren’t the kinds of problems that create incident tickets. They were the ones that made the system feel harder to use than it should have been. Fixing them didn’t produce a dramatic moment. It just made day-to-day operations quieter.

What This Engagement Was Really About

Dental organizations running subscription revenue models are, in most of the ways that matter financially, healthcare SaaS companies. They have recurring billing cycles, member-level revenue recognition obligations, CRM-to-ERP data flows, and payment infrastructure that needs to handle real volume.

NetSuite can support all of that. But it doesn’t configure itself for it. And when an organization grows into a more complex revenue model without rebuilding the ERP configuration to match, the gaps tend to show up everywhere at once: in the billing run, in the reports, in the integrations, in the payment exception queue.

The work here wasn’t a single project. It was a systematic effort to bring the financial infrastructure in line with the organization operating on top of it.

The patterns we addressed are not unique to this client:

• Revenue recognition misalignment is nearly universal in SuiteBilling environments that were configured early and haven’t been revisited as the business model evolved
• Payment infrastructure failures compound when individual incidents are resolved without addressing the underlying configuration driving them
• Integration drift between CRM and ERP is a maintenance problem, not a one-time implementation problem
• Reporting failures create invisible overhead that finance teams absorb without anyone ever tracking the cost

These are solvable problems. But you have to be willing to look at the full picture before you start patching individual parts.

That’s the work we do.

If your NetSuite environment is generating more manual work than it should, we’d welcome a conversation.

Salora ERP is a financial systems integration firm specializing in NetSuite for healthcare, life sciences, and high-growth businesses. 📧 [email protected] · 🌐 saloraerp.com · 📞 +1-720-254-1320