Plaid vs. Stripe: which side of reconciliation are you actually looking at?
Plaid is the bank side: read-only transaction data from the account the money actually lands in. Stripe is the processor side: the system that generated the payment. They aren't two views of the same event that should match directly — both reconcile against a common bank statement line, and disagreeing is normal until that line is found.
By Zuny Fester, Head of Operations and MarketingPart of the finance integrations guide.
| Plaid's role | Read-only aggregator of bank account transaction and balance data |
|---|---|
| Stripe's role | Payment processor — issues charges, invoices, and payouts |
| What Plaid shows | What actually posted to the bank account, via /transactions/sync |
| What Stripe shows | What was charged and why, netted into a payout on its own schedule |
| Where they meet | The single bank deposit line a Stripe payout settles as — not each other's records directly |
Two different kinds of system, not two competing sources of truth
Loopfour's Plaid integration is read-only: it uses /transactions/sync to report what a connected bank account's data actually shows, with no ability to initiate a payment. Loopfour's Stripe integration is the opposite kind of system — it can create invoices, run subscriptions, and process charges, but has no independent view of the bank account those payments eventually settle into. Neither is more authoritative than the other about the same fact; they're authoritative about different facts. Plaid knows what happened at the bank. Stripe knows what happened at the payment processor. A transaction that's real doesn't appear identically in both — it appears as a Stripe charge/payout record on one side, and as a bank deposit line on the other.
Why they shouldn't be expected to match each other directly
A Stripe payout typically nets many individual charges, fees, and refunds into a single bank deposit, on a schedule that runs a few business days behind the underlying charges. Plaid's feed for that same bank account shows exactly one deposit line for the whole netted amount — it has no visibility into the individual charges that made it up, because those never touched the bank directly. Trying to match Stripe's per-charge records against Plaid's per-deposit-line records one-to-one will fail by design, because they're not describing the same unit of activity.
What actually reconciles
The real reconciliation is three-way, even when only two integrations are involved: Stripe's payout record (the netted total and its constituent charges/fees), Plaid's bank deposit line (the amount and date that actually posted), and the accounting system's own record of what was expected. Stripe tells you what the deposit should unpack into. Plaid confirms the deposit itself happened, for the amount and on the date Stripe's payout record says it should have. Neither one, on its own, proves the other is right or wrong — together, they confirm the same money moved through both systems as expected.
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
Field mapping
What each side actually knows about the same $4,850 deposit
| Question | Stripe's answer | Plaid's answer |
|---|---|---|
| What made up this amount? | 12 charges, 2 refunds, processing fees — itemized | No visibility — sees one deposit line |
| Did it actually land in the bank? | Reports payout as 'paid' on Stripe's side | Confirms the posted transaction, amount, and date |
| What happens if the bank rejects or delays it? | Stripe's payout status may lag behind actual bank state | The authoritative record of what actually posted |
Frequently Asked Questions
Sources
Related
Integration
Why don't my Stripe payouts tie to the NetSuite bank deposit?
A Stripe payout rarely equals one NetSuite deposit line: Stripe nets many charges, fees, and refunds into one transfer settled days later. Check, in order: the payout isn't unbundled into individual charges, the deposit date doesn't match the transaction date, fees are netted not booked separately, a partial capture created a variance, or the payout is still in Undeposited Funds.
Read moreTopic
Integrations
Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…
Read moreDiagnostic
What breaks when a reconciled Plaid transaction changes to modified or removed?
Plaid transaction data isn't immutable. A pending transaction can be removed from the feed entirely and replaced by a different transaction once it posts, and a bank can remove a transaction outright. If a payment was already matched to the old transaction, that match is orphaned the moment the removal comes through, and the replacement has to be found and re-matched — it doesn't update in place.
Read moreHow-to
How do I set up Plaid /transactions/sync for bank feed reconciliation?
Call /transactions/sync with a null cursor the first time for an Item, store the next_cursor it returns, and pass that cursor back on every later call to fetch only what changed. Loop while has_more is true, and process the added, modified, and removed arrays as three distinct kinds of change — not as one undifferentiated transaction list.
Read more