Zendesk customer credit request list and manual Stripe credit log — "Double refunds issued to clients because support and accounting operate in silos"
Why the manual spreadsheet breaks financial controls and how a deterministic workflow replaces it.
Refunds are issued from support tickets and again from accounting's payment log, because neither system knows the other already credited the customer.
The same invoice is refunded twice, cash is recovered only if someone notices, and there is no single state that says whether a credit is requested, approved, or paid.
Idempotent refund state machine shared by support and the payment processor, so a credit request can produce only one payout per invoice and reason.
Idempotency assertion: a refund cannot pay if another refund already exists for the same invoice, amount, and reason code.
Three-stage comparison between manual workbook reconciliation and automated rule-based execution.
Support and accounting each credit the customer from their own list.
Customers are paid twice because no shared state exists for the credit.
One credit record moves from request to payout; a second request is rejected.
A refund does not pay when another refund already exists for that invoice and reason.
Adjacent spreadsheet failure modes in the same APQC Category 9 process group.
Retailer deduction dispute log and short-payment tracking spreadsheet
RMA tracking spreadsheet and warehouse return inspection sheet
Contract-adjustment policy sheet and deferred-revenue waterfall
Scope the replacement architecture for customer refund requests processed through ad-hoc support tickets or combine multiple failure modes in the directory.
