This article is relevant if you are using the Boomi Integration Connector with NetSuite and Stripe Payments Processing in your business but are having trouble with your transaction volume and reporting.

Background

In 2022, a subscription-based pet food company came to our firm requesting help with multiple concerns with their NetSuite configuration. The organization had recently gone live and was having a growing problem keeping up with its custom-built eCommerce-based membership system, which was attempting to automatically create 1,000s of order and payment transactions daily.

While the amateur approach is to focus on the technology situation when encountering these scaling challenges, like we do for all of our clients, we must first consider the major business requirements to determine if the NetSuite configuration and, thus, technology model is sound.  Indeed, we discovered a number of issues in the way the client had worked with another NetSuite Partner to build out their configuration and ultimate processing model.

The solution required us to fundamentally reconfigure NetSuite to drive the proper operations and accounting in a scalable manner. In this discussion, I will outline the major breakdowns and findings to help make the following point: Business First, Technology Thereafter.

NetSuite a Follower vs. a Leader System

When we arrived at the situation, the client was already locked into a processing model where their eCommerce system was tightly coupled to their 3PL fulfillment partner.  For building a scalable business operation, we do not consider this a best practice.  In this situation, NetSuite must be configured to keep up with transactions that are occurring in other systems.

We often see younger and smaller organizations attempt to migrate from accounting systems such as QuickBooks and Xero in an effort to produce consolidated financial reports. While noble, forward-thinking about the architectural implications of particular business system roles and responsibilities in a constellation of applications is often missing.

The real power of the NetSuite platform is unleashed when you put the ERP business system at the center of your transaction narrative. Meaning, we want NetSuite to become a Leading system in that we can accept customer orders from any source (phone, web, EDI, etc.), and we can fulfill from a network of warehouses anywhere in the world.  Sometimes we call this best practice architecture “NetSuite as a Hub”. Click the image to see the model more clearly.

In this approach, we can still get the value of consolidated financial statements — but with NetSuite as a Hub, we can get scalable consolidated operations. A consolidated operation means we can centralize functions (or keep them decentralized if we wish);  and we all operate from a single version of the truth, which allows us to design powerful order management and fulfillment narratives  — typically at a lower processing cost with more effective transaction coordination and superior reporting.  Our most ambitious clients understand this pattern and seek to work with professionals, like those that work in our firm,  to drive this storyline.

Overcame Boomi Technical Limitations

In the client’s follower model, they were creating sales orders for each eCommerce order. However, since we carefully considered their architecture, there was no value in the Sales Order transaction because fulfillment was decoupled from NetSuite.  Instead, they needed to create invoices to recognize revenue and decrement NetSuite inventory (a different discussion not elaborated here) as soon as the fulfillment partner shipped.

In addition, a growing problem was developing for Boomi to keep up with the daily transaction volume. When we arrived, the system was already one week behind in trying to get sales orders into the system. After working with Boomi professionals who were unable to offer quality technical leadership to solve the issue, and given we knew we needed to change the transaction model, we worked with the client on a new approach.

Thus, in 2022, I wrote the article, Contrast Platform vs NetSuite Point-to-Point Integration Options, which outlined how we solved the challenge. We reconfigured the system to create Invoices instead of Sales Orders without Boomi, the client saved money because they eliminated Boomi recurring transaction fees, and based on the client’s existing in-place SuiteCloud licenses, we easily demonstrated that we could process twice the largest anticipated daily order volume and keep up with the work; all without a third-party system.

Overcame Stripe Configuration Limitations

The client’s custom-built eCommerce system was using the Stripe gateway. Stripe is a popular payment processing platform. It’s no surprise that the custom-built eCommerce membership system was powered by Stripe as it has strong recurring/subscription features for securely holding credit card information.

However, Stripe is not an official NetSuite SuitePayments certified gateway. This means that all the built-in payment capacities in NetSuite are not available; Yet, the built-in payment capacities are effectively meaningless when NetSuite is in a Follower architecture.

Still, the challenge the client was facing was fundamentally incorrect transaction processing logic.  To Stripe’s credit, they offer a Connector for NetSuite (formerly known as SuiteSync). The configuration was pushing in charges as Customer Payments. Thus, the client had 1,000s of transactions coming into NetSuite and causing a reconciliation nightmare:

1. Customer Payments: the client was using the Connector to book transactions as an unapplied credit to accounts receivable. However, the proper flow was to book these as Customer Deposits as they were collecting funds in advance of delivery. I have written numerous articles on NetSuite Customer Deposit accounting.
2. Undeposited Funds: the client had the funds arrive in the default Undeposited Funds account.  With this kind of transaction volume, the Undeposited Funds account can be very difficult to manage. It forces you to find the respective transactions and create a bank deposit — perfect for low volume — nightmare with large volumes.

Both of these configuration weaknesses were covered in my 2022 article, Solve for High Volume NetSuite Cash Receipt Payment Patterns.

As we contemplated the Followership architecture reconfiguration, we knew it was important to have a model to ease the cash reconciliation burden. The more we studied the Stripe Connector for NetSuite, we recognized we could not get sufficient control over a number of concerns:

1. Customer Identification: the client did not want to have customer accounts in the Follower NetSuite system. A scalable pattern to insert 1,000s of transactions into NetSuite is to use multiple phantom customer records (in our client’s case, 20 of them) so that you minimize record locking as NetSuite tries to maintain deposit and accounts receivable balances every time there is a recorded transaction.  Stripe data has order information but nothing that would bridge this customer identification pattern.
2. Returns and Discretionary Refunds Processing: the custom-built eCommerce system and the client’s processing model allowed customer service to manipulate the Stripe gateway directly. Again, we would never promote that practice in a NetSuite Leader model. But here, we needed to do the best we could to follow along while minimizing the impact on the accounting department. The Stripe Connector lacked the branching and transaction identification logic we needed.
3. Shaping Bank Deposits and Cash Management: we needed to configure the environment to shape how the records were written so they would mimic how cash arrived daily at the bank. Again, the thinking in the article, Solve for High Volume NetSuite Cash Receipt Payment Patterns, offers guidance.

Once it became clear that the Stripe Connector for NetSuite did not have sufficient logic, we could have tried to work with the Stripe organization to build more custom flows.  Yet, the client could see that our technical depth to overcome the Boomi limitations meant that it would be quicker and ultimately more economical to take matters into our own hands and build a Contrast Platform vs NetSuite Point-to-Point Integration Options Point-to-Point NetSuite to Stripe integration.

And that we did to our client’s success.

Hence, there were some important technical findings as we produced a real-time Stripe integration, all running from NetSuite servers handling 1,000s of daily transactions:

Stripe Transaction API Request Nuances

The typical way you request transactions via APIs is to ask the interface, “give me all transactions since this point in time.” In this pattern, you track the last time you received a transaction and move into the future. You provide the API with your start date/time (or last transaction number), and it supplies transactions starting with the oldest to the newest. This works well; you can always catch up as you move closer to the latest transaction.

Stripe works the opposite. You can ask for a transaction with a start time as you would expect. But it supplies the transactions sorted by the newest first.  This sorting approach is highly unusual.  The system will only allow you to request 100 transactions at a time — not unusual.  But in this sorting pattern, you have no idea how many transactions exist between now and the last time you checked. In the normal approach to supply transactions from the oldest to the newest, you can collect 100 transactions, remember the last transaction you received, and start a brand new process to move closer to the current time.

The peculiar Stripe model requires that you make sure that you request a sufficient amount of transactions within NetSuite’s technical processing governance window because you do not know how many transactions you are going to get.  Consider that if there are 10,000 transactions, you will need to make 100 calls.  This is risky because you will soon hit NetSuite’s technical governor and run out of processing capacity. The API callouts aim to ensure you get sufficient transactions in one session so you can move your last transaction date/time forward — otherwise, you are stuck in the dark. This sorting pattern can more easily be dealt with in a system outside of NetSuite without the governance limitation.  We did solve it, but we had to determine timing and batch parameters that would allow us to call forward the transactions without getting lost and in a conservative fashion allowing for system downtimes.

Once we worked through the technical particularities, we then were able to build the right transaction model:

• customer deposits were connected with the proper customer record; we solved how customer deposit application records were applied against revenue earned on invoices.
• customer refunds were either connected with previous revenue transactions or were discretionary in fashion: we were able to produce the right accounting treatment via credit memos and customer refund transactions.

After getting the transaction processing model correct, there was the work to “get in sync,” which included the cutover, customer deposit application, and bank reconciliation work to help the client stay under control.

Taking Control to Drive NetSuite Correctly

Unfortunately, we see the above situation too often. Here, and in more than one instance, a recognized accounting firm that touts itself as the largest NetSuite professional services alliance partner, led our client to a poor NetSuite configuration.

It’s so important to model the challenge correctly. In our minds, if you can not correctly outline the business purpose, transaction, and accounting flows, you simply can not model right. An incorrect conceptual model will lead to a very disappointing implementation.

Many new NetSuite customers realize they have the right software — their worries are because they had the wrong implementation leadership. When you realize you are in this situation, it’s time for a turnaround.  The robustness of the platform produces its capacity for power. Yet, that robustness also greatly increases the risk of costly-to-recover mistakes.

If you found this article relevant, feel free to sign up for notifications to new articles as I post them. If you suspect your NetSuite configuration model is leading to troublesome transaction processing and poor reporting, let’s have a conversation.

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - YouTube