Salesforce, Stripe, and NetSuite Automation: Sales to Billing to Cash to Accounting Without the Manual Bridge

Salesforce, Stripe, and NetSuite is the default stack for a sales-led B2B SaaS company past its first finance hire. Salesforce holds the deal and the contract. Stripe holds the subscription, the invoice, and the payment. NetSuite holds the customer ledger, revenue, and the general ledger. Each system is good at its job, and none of them talks to the other two without help. The help is usually a person: the one who creates the Stripe subscription from the closed-won opportunity, the one who keys Stripe invoices into NetSuite, the one who applies the Stripe payout against forty open invoices, and the one who answers the account executive's "did they pay?" in Slack.

This guide is the architecture for replacing that person with a chain of four automated handoffs. It is deliberately not a NetSuite-only guide; the two we already publish, how to sync Salesforce, HubSpot, and Stripe to NetSuite (ownership, idempotency, cash application patterns) and how to sync Salesforce or HubSpot deals to NetSuite invoices (sales order versus invoice, object mapping, connector limits), go deeper on the NetSuite side and are linked where they apply. Updated September 2026.

Quick answer

Give each record one owner: Salesforce owns the deal and the contract terms, Stripe owns the subscription, the invoice, and the payment, NetSuite owns the customer ledger, revenue schedules, and the GL. Automate four handoffs in order: closed won to Stripe subscription and invoice (from the contract, not the opportunity amount); Stripe invoice to a NetSuite invoice or sales order keyed by external ID; Stripe payments and payouts to NetSuite customer payments, fee expense, and bank deposit; and invoice and payment status back to the Salesforce account and opportunity. Store every cross-system ID on the record it belongs to, never match on names, and make every step safe to run twice. Stripe's own NetSuite connector covers most of handoff 3 and part of handoff 2; an iPaaS covers whatever you build; LedgerUp covers handoffs 1, 3, and 4 from the contract and prepares 2 for the ledger you run.

The chain, and who owns which record

The two decisions most teams get wrong are letting NetSuite also create invoices (now two systems invoice the same customer) and letting the Salesforce opportunity amount, rather than the contract, drive the Stripe subscription. Everything below assumes both are settled.

Handoff 1: closed won to Stripe subscription and invoice

When the opportunity moves to Closed Won, something reads the CPQ quote lines and the signed order form, matches or creates the Stripe customer, and builds the right Stripe object: a subscription for a flat deal, a subscription schedule for a ramp, a series of invoices for milestones, metered prices for usage. Net terms, PO number, and start date come from the contract. This handoff is the subject of the Salesforce to Stripe billing automation hub and the four-methods guide; the part that matters for the chain is that the Stripe customer, subscription, and invoice IDs are written back to Salesforce immediately, because handoffs 2 and 4 key on them.

Handoff 2: Stripe invoice to NetSuite

Every finalized Stripe invoice becomes a NetSuite record with the Stripe invoice ID as its external ID, against the NetSuite customer keyed to the same account. Two design choices:

Record-level mirror or payout-level summary

B2B companies with net-terms invoices need the record-level mirror: one NetSuite invoice per Stripe invoice, so AR aging by customer exists in the ledger and collections and revenue are auditable per contract. Payout-level summary journals (one entry per Stripe payout) fit high-volume, low-value card businesses, not contracts.

Invoice or sales order in NetSuite

If NetSuite runs revenue recognition schedules, approvals, or fulfillment, land the Stripe invoice as a sales order first and bill from it; if the sale is simple and immediately billable, create the invoice directly. The CRM-to-NetSuite invoices guide covers this decision in detail, with the object mapping for line items, subsidiaries, tax, and billing schedules. Line items on the NetSuite record should carry the same products and amounts as the Stripe invoice, mapped by item internal ID, not by name.

Handoff 3: Stripe payments and payouts to NetSuite cash

A Stripe payout is the net of many things: card and ACH payments on several invoices, minus Stripe fees, minus refunds, minus dispute withdrawals, sometimes plus dispute reversals, arriving at the bank days after the payments. Cash application in NetSuite has to unpick it:

• Each Stripe payment becomes a NetSuite customer payment applied to the mirrored invoice, at the gross amount, to undeposited funds.
• Stripe fees become an expense line (or a fee item on a journal) per payout, so the customer's invoice shows paid in full while the bank shows the net.
• Refunds become customer refunds or credit memos against the original invoice; disputes become a reversal and, if won, a re-application.
• The payout becomes a bank deposit whose total equals the payments minus fees and refunds, so the bank reconciliation ties on the first pass.
• Wires and checks that never touch Stripe are applied in NetSuite directly and marked paid out of band in Stripe, or handoff 4 will report them past due.

Stripe's own NetSuite connector automates most of this leg. The mechanics of a payout, the six common reconciliation breaks, and the QuickBooks and NetSuite variants are on the Stripe reconciliation page and the Stripe to NetSuite integration page.

Handoff 4: status back to Salesforce

Invoice status, paid date, open balance, past-due amount, and collections state are written to the Salesforce account and opportunity from Stripe events and a daily aging calculation; a failed charge creates a task for the account owner. Sales sees cash state where they work, and the renewal conversation starts from facts. The fields, the events, and the four ways to build it are in how to get Stripe payment status back into Salesforce. In the three-system chain, this handoff also carries a NetSuite fact: whether the invoice has been booked, which matters for commission plans that pay on booked and collected revenue.

The ID crosswalk

Every retry checks the external ID first and creates only if missing. That one rule removes the duplicate invoices and duplicate customers that account for most "the integration is broken" tickets.

Tools by leg

The combinations that work: Stripe's NetSuite connector for the money legs plus LedgerUp for the contract legs is common; an iPaaS for everything is common in orgs with an integration team; the NetSuite AR side without Stripe at all is the NetSuite AR automation guide. What does not work is three point tools with no shared key.

Revenue recognition across the three systems

Stripe knows what was invoiced and when. It does not know the performance obligations in the contract, so it is not the revenue subledger. NetSuite (with Advanced Revenue Management or manual schedules) is. The handoff that makes this work is carrying the contract's service period and line structure onto the NetSuite record at handoff 2: a $120,000 annual invoice with a January 1 start creates a twelve-month schedule, a ramp creates one schedule per phase, a usage invoice is recognized in the period consumed, and an implementation fee is recognized on delivery or ratably per the policy. If the Stripe invoice line descriptions carry the service period and the product, NetSuite can build the schedule from them; if they say "Subscription," someone rebuilds it by hand every month. Write the descriptions for the accountant, not the customer.

Failure modes that show up at close

• Duplicate customers. Name matching in any of the three systems. Fix: the crosswalk above, and a one-time cleanup of Stripe before automation starts.
• Invoices booked twice. A retry that creates instead of checking, or NetSuite also generating invoices from sales orders that Stripe already invoiced. Fix: external IDs and one invoicing system.
• Net-of-fee AR. Payments applied at the payout's net amount leave every invoice short by the Stripe fee. Fix: gross to AR, fee to expense.
• Payout timing. Payments on the 30th, payout on the 2nd; AR and bank disagree at month end. Fix: undeposited funds and deposits dated by payout.
• Refunds and disputes after close. A paid invoice reverses in a closed period. Fix: post the reversal in the open period against the original with a memo, and never edit the closed one.
• Out-of-band payments. Wires applied in NetSuite but not marked paid in Stripe; Salesforce shows past due. Fix: handoff 3 writes back to Stripe, or handoff 4 reads NetSuite too.
• Multi-entity and multi-currency. One Stripe account, three NetSuite subsidiaries. Fix: subsidiary on the Salesforce account, carried through the crosswalk, and Stripe invoices in the contract currency.
• Amendments that never reach NetSuite. The Stripe subscription was updated; the NetSuite sales order and revenue schedule were not. Fix: treat amendments as a handoff-2 event, per the amendments guide.

Go-live checklist

1. Ownership table signed off by finance and RevOps: who creates customers, invoices, payments, and revenue schedules.
2. Stripe cleanup done: one customer per account, IDs stored on the Salesforce account. (Stripe cleanup is a one-week job.)
3. NetSuite items mapped to Stripe products by internal ID; subsidiaries, tax codes, and revenue rules assigned.
4. External IDs populated on existing NetSuite customers and open invoices before the first sync.
5. Handoff 1 tested on a ramp, a usage deal, and a milestone deal, not only a flat subscription.
6. Handoff 3 tested on a payout that contains a refund and a fee, and the bank reconciliation tied.
7. Handoff 4 verified by an account executive looking at an account, not by finance looking at a log.
8. Retry and replay tested by running a day twice and confirming nothing duplicated.
9. Close calendar updated: which reports come from NetSuite, which from Stripe, and which reconciliation ties them.

Frequently asked questions