Reconcile Stripe in NetSuite by separating customer transactions, Stripe balance activity and bank payouts. Use the provider's detailed records to explain the clearing balance, and avoid creating revenue again when the net payout reaches the bank. The right reconciliation method depends partly on whether payouts are automatic, manual or instant.
Start by identifying which application already creates invoices or sales transactions. Then determine how payment receipts, fees, refunds and disputes enter NetSuite. Without that ownership decision, two accurate feeds can still duplicate financial activity.
Stripe's payout reconciliation report links automatic payouts to the transactions they settle, subject to documented platform exceptions. Manual payout users generally need a balance-based approach, and Stripe does not identify transaction membership for instant payouts in the same way.
Stripe's Balance report explains opening balance, activity, payouts and ending balance. It does not establish which payments belong to each payout. Select the report that matches the control question instead of treating all exported totals as interchangeable.
Retain the Stripe account, currency, report period and timezone with each extract. If the business uses multiple accounts or connected accounts, define the population explicitly and prevent one account's payout from clearing another's activity.
Create an approved mapping for customer payment, refund, processing fee, dispute, adjustment and payout. Identify the source reference and target transaction or accounting treatment for each category.
If NetSuite already records the invoice, importing the Stripe payment should follow the approved receivables or clearing process. If another system creates a summarized sale, preserve enough detail to reconcile it to Stripe without creating a second sale from the payout.
Do not use a generic fee account for every unexplained deduction. Some amounts may represent refunds, disputes, currency conversion or other adjustments with different accounting treatment. Unknown categories belong in a visible review queue until finance approves their mapping.
Store stable payment, refund, balance-transaction and payout references as relevant to the selected flow. One customer payment can have associated financial events over time, so the payment identifier alone may not uniquely identify every ledger movement.
Define how the integration recognizes a previously processed event. A replay should either confirm the existing result or create the missing approved transaction, without duplicating a payment or fee. Retain import batch references and source control totals.
Where the source includes customer metadata, use only what is necessary for matching and support. Do not copy payment credentials or excessive personal information into logs or finance workbooks.
For each account and currency, begin with the approved opening balance. Add the supported payment activity, subtract refunds and fees, include other approved adjustments and deduct completed payouts under the chosen cutoff policy. Reconcile the resulting ending balance to Stripe's evidence and NetSuite.
Next, match payouts to the bank. Preserve the distinction between a payout recorded by Stripe and cash confirmed in the bank statement. An expected arrival date is not independent proof that the bank received the money.
Investigate outstanding balances by age and type. Some are legitimate settlement timing differences; others reflect missing imports or incorrect classifications. Confirm subsequent settlement before repeatedly carrying an old amount as “timing.”
Assume a settlement batch contains 12,000 currency units of payments, 800 of completed refunds, 350 of processing fees and a 200 dispute deduction. With no other activity, the net amount is 10,650.
The finance team traces those categories to approved NetSuite entries and matches the 10,650 payout to bank evidence. If sales were already recorded, the deposit clears the supported payment balance rather than becoming another 10,650 of revenue.
Now assume the business requests a manual payout of 9,000 from a larger accumulated balance. It should not invent a list of individual payments that “must” belong to that payout solely to make a batch report balance. The balance bridge explains the remaining amount. This hypothetical example simplifies fees, tax and currency effects.
A refund may relate to a sale from an earlier month, and a dispute may change status after the original payout. Retain the original transaction relationship while applying the controller's approved posting-period policy.
Avoid editing a historical sale simply to match the current net bank deposit. The financial event needs its own supported treatment and evidence. Track unresolved disputes and any later reversal without assuming that all disputed funds will be recovered.
For multiple currencies, distinguish transaction currency from settlement currency and the ledger reporting basis. Validate conversion amounts and classifications with finance rather than applying an undocumented rate to force agreement.
For each period, confirm:
Keep the mapping version with the reconciliation. A newly introduced source category should be detected before it silently changes reported revenue or fees.
A CuriousRubik integration review can focus on these financial event boundaries and the evidence behind each payout. The goal is an explainable clearing balance, with every amount recorded once and every unresolved difference assigned to someone who can fix it.