Case study · Stripe payout reconciliation
Three generations of one weekly reconciliation
From four to six hours by hand, to under thirty minutes in KNIME, to a console that checks every week 16 ways and keeps every run.
Generation 1
By hand
4–6 hrs
every week, longer at month end
- Stripe downloads too big for Excel, pushed through Tableau first
- Consolidated with Power Query, then every tab checked by hand
- Journal entry created and posted in NetSuite by hand
The process being replaced
Generation 2
KNIME rebuild
< 30 min
door to door, review included
- Execution itself runs five to fifteen minutes
- A completeness branch catches any fee outside the nine known categories
- Builds the NetSuite journal-entry import, keyed on External ID so a re-import cannot double-post
- Run side by side with the manual process before cutover
- Ten parameters typed by hand at the start of every run
- Runs on one machine only
- A re-run overwrites what was booked; no snapshot is kept
- Its query window was too narrow and missed backdated payment entries
Built, tested and put into production alone
Generation 3
Python console
16 checks
before anything is exported
- Every run saves the data it used, with a fingerprint, so any week can be replayed
- Nothing accrued twice, checked by Stripe's own row ID
- Journal entries rebuild from the snapshot to the cent
- Caught a booked week where hand-typed dates added a day that was already booked
- Still in testing next to the manual process, not posting yet
Built, and matching what was booked
What the generation addedWhat it still could not do