Planting each discrepancy on purpose and keying it is the right way to build a demo like this, because a reader can check every euro of the gap. The example stops at one month, one currency and no opening balance; a second scenario with an FX payout and a carried balance would show the bridge level earning its keep. If you end up building more of these, I work on Misata, a ground truth artificial data generator tool where you declare targets like a payout landing after cutoff and get multi-table data that hits them exactly from a seed. Happy to compare notes on the dbt test either way.
Data integration, migration and data quality: finding why numbers between systems don't match. SQL, Python. 19 years of backend and data systems. Fixes merged in NATS, numaflow and factur-x.
Good point about a carried balance and an FX payout: that's where the bridge really has to work. Here FX only shows up at the line level: a couple of customers paid in USD, Stripe settled in EUR, and the books used another rate. The opening balance is assumed to be zero, as the README says. A second month with a carried balance would be the natural next step.
Out of curiosity, in the cases you've seen, was it the carried balance or the FX conversion that usually broke the reconciliation?
Data integration, migration and data quality: finding why numbers between systems don't match. SQL, Python. 19 years of backend and data systems. Fixes merged in NATS, numaflow and factur-x.
@rasinmuhammed The October demo is up: dev.to/akarazhev/stripe-reconcilia.... Your refund case is in: Stripe took back €385.76 against €392.35 in the books, so €6.59 lands in October from a September payment. The dispute and the payouts are in too. Reserve releases aren't yet. How did you spot the one booked in the wrong period?
Carried balance, mostly. FX mistakes tend to be loud and local. Stripe converts at its own rate (you can see it on each balance transaction as exchange_rate) while the books use a daily or ECB rate, so the leftover difference shows up next to the line that caused it. A wrong opening balance is quiet and it compounds. A payout still in transit at month end, a dispute opened in one month and settled in the next, or a reserve release booked in the wrong period throws off every month after it by the same amount. Then the bridge looks broken even when that month’s activity is fine. The nasty case is when the two meet: a USD charge in month one refunded in month two, which Stripe converts at the rate on the day of the refund. Now an FX difference is sitting inside the carried balance. If you build the second month, that refund would be a good one to plant.
Data integration, migration and data quality: finding why numbers between systems don't match. SQL, Python. 19 years of backend and data systems. Fixes merged in NATS, numaflow and factur-x.
Planting each discrepancy on purpose and keying it is the right way to build a demo like this, because a reader can check every euro of the gap. The example stops at one month, one currency and no opening balance; a second scenario with an FX payout and a carried balance would show the bridge level earning its keep. If you end up building more of these, I work on Misata, a ground truth artificial data generator tool where you declare targets like a payout landing after cutoff and get multi-table data that hits them exactly from a seed. Happy to compare notes on the dbt test either way.
Thanks!
Good point about a carried balance and an FX payout: that's where the bridge really has to work. Here FX only shows up at the line level: a couple of customers paid in USD, Stripe settled in EUR, and the books used another rate. The opening balance is assumed to be zero, as the README says. A second month with a carried balance would be the natural next step.
Out of curiosity, in the cases you've seen, was it the carried balance or the FX conversion that usually broke the reconciliation?
@rasinmuhammed The October demo is up: dev.to/akarazhev/stripe-reconcilia.... Your refund case is in: Stripe took back €385.76 against €392.35 in the books, so €6.59 lands in October from a September payment. The dispute and the payouts are in too. Reserve releases aren't yet. How did you spot the one booked in the wrong period?
Carried balance, mostly. FX mistakes tend to be loud and local. Stripe converts at its own rate (you can see it on each balance transaction as exchange_rate) while the books use a daily or ECB rate, so the leftover difference shows up next to the line that caused it. A wrong opening balance is quiet and it compounds. A payout still in transit at month end, a dispute opened in one month and settled in the next, or a reserve release booked in the wrong period throws off every month after it by the same amount. Then the bridge looks broken even when that month’s activity is fine. The nasty case is when the two meet: a USD charge in month one refunded in month two, which Stripe converts at the rate on the day of the refund. Now an FX difference is sitting inside the carried balance. If you build the second month, that refund would be a good one to plant.
Thanks, very helpful. The refund across two months is a great case. I'll plant it in the second month and post here when it's ready.