Publishing the first receipt.

March 2026 was LADLE's first full month of subscribers. April 5th was the day we published the first monthly receipt for WFP donations. This is the specific checklist we ran through to get it right, written down partly for our own future selves and partly so anyone else building a public-receipts model has a starting point.

**The checklist (in order):**

**1. Reconcile Stripe to the ledger.** Every successful Stripe charge in March that wasn't refunded needs to have contributed $8 to the meal accrual. Every refund needs to have subtracted its $8 accrual. We ran the reconciliation query and matched it to Stripe's monthly summary. Off by $32 on the first pass (four refunds we'd missed in the accrual code). Fixed the code, backfilled the four missed reversals, matched.

**2. Compute the aggregate.** Total accrued dollars for the month = total_subscribers × meals × $0.80. Sanity-check against the ledger sum. Both computed independently, both should match. They did after step 1.

**3. Send the wire to WFP via ShareTheMeal.** Their platform issues a receipt with a reference number. We wire the aggregate amount. The confirmation comes back with the reference number and confirmation of the batch inclusion. This is the number that anchors the whole receipt.

**4. Draft the public receipt page.** Fields: month, subscriber count, total meals funded (subscribers × 10), total USD sent, WFP reference number, batch identifier, per-plan breakdown. Publish at /impact/reports/2026-03.

**5. Cross-check the numbers one more time.** Read the receipt as if you're a subscriber checking whether the numbers add up. Do the meals × $0.80 math externally. Match the total to the ledger and the Stripe summary. Confirm the reference number is real by looking it up on ShareTheMeal's side.

**6. Publish and announce.** Receipt page live. Note in the changelog with a link. Short update in the blog. No fanfare — the receipt IS the announcement.

**7. Archive the underlying artifacts.** Stripe report PDF, ledger CSV, WFP confirmation, batch documentation — all saved to a private drive with the month's identifier. If we ever get audited or challenged, this is the evidence trail.

**What we caught before publishing:**

The four missed refund reversals (step 1). Would have overstated the meal count by 40. Publishing that number wouldn't have been fraudulent — the total transferred to WFP would have been higher than the refund-adjusted count — but the count would have been inconsistent with the ledger and someone would have noticed.

A rounding artifact where the per-plan breakdown didn't quite sum to the total (off by $0.03 due to floating-point rounding across many small transactions). Trivial in impact, would have looked sloppy in the receipt.

The reference number format we'd originally displayed was truncated. Fixed to show the full ShareTheMeal reference.

**What we changed for month two:**

The reconciliation script now runs automatically on the 1st of each month, not manually. Human error → script.

The refund reversal test is now a self-test that runs against a synthetic batch every night. Catches the class of bug that hit us in month one before it can hit us in month N.

The receipt now includes a "how to verify this" section explaining how a subscriber can independently cross-reference the reference number on ShareTheMeal's platform. We should have had this from the start; adding it made the receipt feel more like a receipt and less like a marketing page.

**The general lesson:**

The first version of anything public-facing is where you learn what to check for. The checklist we ran on month one was longer than any subsequent month; each month gets shorter as the automation catches more of the surface area. That's how the receipt discipline gets sustainable.

The alternative — publishing a receipt that turns out to be wrong six months in — would kill the whole product. The first-receipt care is the deposit against future error.