If you’ve ever tried to match a Stripe payout deposit to your NetSuite invoices by hand, you already know the problem: the number that lands in your bank account almost never matches any single invoice, because Stripe doesn’t pay out invoice by invoice. It pays out in batches that bundle multiple transactions, processing fees, and any refunds or disputes that happened to settle in that window. Unwinding that bundle correctly is the entire job of this integration.
The payout is a net number, not a transaction record
A Stripe payout represents the net result of everything that happened in a given period — gross charges, minus processing fees, minus refunds, plus or minus adjustments for disputes. Post that net number straight to your bank account in NetSuite and you lose the ability to see gross revenue, fee expense, and refunds as the separate line items your GL actually needs. The integration’s job is to take that one payout number and decompose it back into its components, posting each to the account it belongs in, so your books show what actually happened rather than a lump sum that happens to reconcile with the bank.
Multi-currency accounts add a second layer
If you run a Stripe account processing multiple currencies, FX conversion happens somewhere between the original charge and the eventual payout, and that conversion has its own rate and its own timing. That has to line up with how NetSuite handles multi-currency, or you’ll see small, persistent variances that look like reconciliation errors but are actually just two systems calculating FX slightly differently. Getting this aligned at setup avoids a recurring, low-grade headache at every close.
Subscriptions turn this into a revenue recognition problem, not just reconciliation
If you’re running Stripe Billing or Stripe subscriptions, the integration isn’t only about matching payouts to the bank — it’s about getting subscription and invoice events into NetSuite in a way that supports proper revenue recognition. A subscription renewal, an upgrade with proration, a failed payment that later retries successfully — each of these needs to be reflected correctly, not just as “money arrived,” but as the right revenue recognized in the right period. This is where a reconciliation-only integration falls short of what a subscription business actually needs.
Disputes and refunds need their own path
Refunds and chargebacks don’t behave like the original charge — they arrive on their own timeline, sometimes well after the original transaction has already been reconciled and closed. The integration needs a defined path for these so they post correctly against the original transaction rather than becoming an unexplained variance that shows up in a later period with no obvious cause.
Test-mode and live-mode data need to stay separate
Stripe accounts running both test and live transactions (common during any period of active development on a checkout flow) create a specific risk: test transactions leaking into NetSuite and inflating revenue or transaction counts. It’s an easy mistake to make and an unpleasant one to unwind after the fact, since it means auditing which historical transactions were real. Keeping the two modes cleanly separated at the integration layer, rather than relying on someone remembering to filter them out downstream, avoids the cleanup entirely.
What this integration actually moves
- Payments and payouts
- Processing fees, broken out individually
- Refunds and chargebacks
- Subscription and invoice data
- Tokenized customer payment methods
Our approach
We start by pulling a sample of your actual Stripe payout data and tracing it through to how it currently lands in NetSuite — that’s usually where the real gaps show up, well before we touch any configuration.
If manual Stripe reconciliation is eating time every close, the full Stripe integration guide covers the technical approach, or get in touch to see what it would take for your setup.