How the meal ledger actually works.

The meal ledger is deliberately simple, both because it's easier to reason about and because complexity is where trust erodes. Here's how it works, top to bottom.

We run two accounting ledgers separately. The operating ledger tracks the $12 per subscription that funds Anthropic API costs plus our overhead. The meal-committed ledger tracks the $8 earmarked for WFP. These are literally separate database tables with separate transactional boundaries. Money can flow into either from a Stripe charge; money can't flow between them.

When Stripe processes a successful $20 charge, our webhook handler writes two rows: $12 to operating, $8 to meal-committed. Both are timestamped with the exact moment of the charge. If the charge fails, no rows are written. If the charge is refunded (rare, but happens), both rows are reversed atomically in the same transaction.

On the last calendar day of each month, a scheduled job sums the meal-committed ledger for the month and initiates one aggregate donation to ShareTheMeal via their API. The transfer typically clears within 30 minutes, during which the job is in a "pending" state. On success, ShareTheMeal returns a unique reference number that we associate with every meal-committed row for that month.

The receipt is published as soon as the reference number is confirmed. It appears in three places atomically (same database transaction): the public Impact page ledger, the current month's Impact Report, and every subscriber's personal My Table screen where the plates for that month "confirm" from pending to committed status.

Reconciliation checks run continuously. Every 15 minutes, a job verifies that: - The sum of the meal-committed ledger equals the sum of all successful $20 charges times $8 (adjusted for refunds). - The sum of published receipts equals the sum of meal-committed rows tagged with a reference number. - Every reference number on the public ledger has a corresponding response record from ShareTheMeal.

Any drift triggers a page. In four months of operation, we've had zero true drift; two false positives from clock-skew between our systems and Stripe (resolved within minutes, published on the status page).

The intentional simplifications: we do not compound meal counts across time. If a subscriber's charge fails and they re-subscribe later, their historical meals stay counted at their original values — we don't retroactively adjust anything about past batches. And we do not partial-donate. Every month's transfer is a single all-in donation; if for any reason we couldn't execute it (bank holiday, ShareTheMeal outage, our own bug), the whole batch waits until the next successful attempt, with the status page reflecting the delay.

Everything on this page is verifiable independently. The reference numbers on the ledger are the specific bookkeeping identifiers ShareTheMeal uses; you can email their donor support and they'll confirm the amounts and dates.