Invoice generation failures and a double-charged customer card
Larkspur Services issues about 14,000 invoices a month across three billing frequencies using a nightly batch. Roughly 6 percent fail with a missing billing schedule error, and the failures cluster on subscriptions created after the batch runs. One customer disputed a $61,400 annual invoice, arguing that the quantity was wrong, and asked for a credit memo rather than a cancellation. Separately, a payment gateway timeout caused a retry that charged a card twice. Month-end close requires every invoice to be accounted for, and the team currently reconciles the failures by hand in a spreadsheet.
1. How would you diagnose the 6 percent failure rate rather than treat it as a tuning problem?
Read the worked answer
The error names the cause: no billing schedule exists for the subscription at the moment the batch reached it. Batching harder will not fix an ordering problem.
Segment the 840 failures by creation date relative to the batch run. If they cluster on subscriptions created after the batch executes, the root cause is a race: the schedule is generated by a job that runs before the subscription is complete, or generation is a manual step someone forgets. The same race occurs when an amendment is applied in the same window, consuming or superseding a schedule.
Then check whether failures skew toward mid-month starts. Advance-versus-arrears treatment of a partial period is a common source of schedules that are generated but produce no invoice, which shows up as the same error downstream.
The structural fix is threefold. Generate the schedule at the point the subscription becomes active, so the schedule exists before any batch sees it. Add a reconciliation job that compares active subscriptions against existing schedules and reports gaps daily instead of at close. Make regeneration idempotent so a retry cannot produce a duplicate schedule and a double invoice.
The 840 hand-reconciled invoices a month are the real cost, and they are capacity, not variance.
2. The customer disputes quantity on a posted invoice. Cancel, void, or credit memo - and how does the correction flow forward?
Read the worked answer
Credit memo, for three reasons. The invoice is posted and almost certainly revenue-recognized; cancelling it destroys the audit trail linking the charge, the recognition, and the correction. A void may be unavailable once the period is closed, and even when available it erases the record of what happened. A credit memo leaves both the original and the reversal visible, which is exactly what an auditor wants to see.
Scope it to the disputed quantity only, and reverse tax along with it - a credit that ignores tax creates a filing mismatch.
Separately, fix the forward-looking error. If the invoice quantity was wrong, the subscription quantity is wrong, so an amendment corrects the subscription from the effective date and the credit covers the periods already billed. Do not correct the subscription and assume the credit is implied; the two are distinct acts.
One judgment call: if the customer is right that they were overbilled, the credit is not a concession and should be processed without an approval trail that treats it as one. If they are wrong, the credit is a concession and should be governed as such.
3. What should be done for the duplicate charge, and what design change prevents a recurrence?
Read the worked answer
First, establish what actually happened. A gateway timeout means the request's outcome is unknown - the charge may well have succeeded. Query the gateway for the transaction by its idempotency key before doing anything else, and confirm whether one authorization or two exist.
If two settled charges exist, refund the duplicate. A void is appropriate only while the transaction is unsettled; after settlement, void is not available and attempting it leaves the customer charged while the record says otherwise. Tell the customer before they find out, and state the refund timeline.
On the accounting side, a refund for a duplicate charge does not reverse revenue - the service was delivered once and paid twice, so the second charge was never revenue at all. Treating it as a revenue reversal corrupts the period.
The design change is idempotency: every payment attempt carries a key derived from invoice and attempt context, and a timeout triggers a status query rather than a blind retry. Add a reconciliation job that compares gateway settlements to payment records daily; duplicate charges are usually found by the customer first, which is the failure mode to eliminate.