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?
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.
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?
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.