Publishing the first fund report.

March 2026 was LADLE's first full month of subscribers. April 5th was the day we published the first monthly fund report — the LADLE-issued artifact that shows the meal fund balance for the month. 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-reporting model has a starting point.

A note on framing: at the time we shipped this artifact, we described it as a partner receipt. It wasn't, and we've relabeled it retrospectively. The partner's corporate-partnership framework starts at $50,000/year, and until we cross that threshold what we publish is a LADLE-issued fund report — same numbers, honest label. The full context is in [the-fifty-thousand-threshold](/blog/the-fifty-thousand-threshold). The checklist below is what we actually ran; the reconciliation-with-partner step is aspirational (it activates when the partnership does).

**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. Post the month's earmark to the meal fund.** The aggregate amount moves from "pending accrual" to "committed to meal fund" in our internal ledger. Once the partnership with the hunger-relief charity we select activates (the $50,000/year threshold), this step becomes a real wire to their platform with a reference number returned. Today, it's a LADLE-internal transfer between ledger buckets, dated to the last day of the month.

**4. Draft the public fund report page.** Fields: month, subscriber count, total meals reserved (subscribers × 10), total USD earmarked, cumulative fund balance, distance from the $50,000/year partnership threshold, per-plan breakdown. Publish at /impact/reports/2026-03.

**5. Cross-check the numbers one more time.** Read the report 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 fund balance reconciles to the sum of every prior month's earmarks.

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

**7. Archive the underlying artifacts.** Stripe report PDF, ledger CSV, fund-transfer documentation — all saved to a private drive with the month's identifier. When the partnership with the hunger-relief charity we select activates, our future partner confirmation numbers get appended to this archive per batch. 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 fund balance 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 report.

The reference-number field displayed a placeholder value. Fixed to state plainly that the partner reference number populates once the $50,000/year partnership threshold clears — no fake numbers, no truncated placeholders.

**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 report now includes a "how to verify this" section explaining how a subscriber can independently cross-check the meal-fund balance against the published subscriber count and $8/subscription formula. We should have had this from the start; adding it made the report feel more like an accounting document and less like a marketing page. Once partner receipts land alongside the fund report (post-threshold), the verification section will point subscribers at the partner's platform too.

**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 reporting discipline gets sustainable.

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