A billing job judged only by its exit status grades its own work. The scheduler records the run’s zero exit status, which says the code reported success. Whether a customer received an invoice lives in another system.
Take a hypothetical billing run on the first of each month: it reads a usage export, prices it, calls a mail provider, and stamps each invoice as sent. Suppose the export never lands. The run opens the file already on disk, prices usage already billed last month, finds nothing new to charge, and exits cleanly. Zero invoices is a valid output for that path. Now suppose pricing is right and the provider rejects the batch; the error lands in a log nobody opens and the run still ends well. Both mornings look identical in the scheduler.
Put the test outside the job. After the window closes, a separate process should query the billing ledger: invoice count against last month, total billed, and the age of the newest usage record it priced. The ledger will not tell you whether anyone got the mail: in this design, the sent stamp is written when the code calls the provider, so it establishes the call. If the provider returns delivery results, store them on the invoice and check those too.
The evidence I would require is the date the check last failed, and a record of someone holding back a cycle on purpose to watch it fire. The test should show that the alert reached the person responsible for billing. A customer who was not billed has little reason to write in, which makes complaints a weak detector.