Aggregating micro-donations: why the batch matters.

Every LADLE subscription earmarks $8 for the World Food Programme. If we naively sent each $8 as an individual wire transfer as the Stripe charge cleared, three things would happen: (1) we'd burn a huge fraction of the donation in transfer fees, (2) WFP's finance operations would drown in tiny incoming transactions, (3) the receipts would be per-transaction chaos rather than per-month clarity.

So we batch. Every month, on the last day, we send one aggregated wire transfer to WFP through ShareTheMeal. This post is the specific reasoning about the batch, since it comes up occasionally.

**The transfer-cost math.**

International wire transfers have fixed costs — typically $15-50 per transaction depending on the corridor and bank. Even if we used a low-cost cross-border rail (Wise, or similar) fees are meaningful on small transactions.

At $8 individual transfers, a $10 fee is 125% of the donation being consumed by overhead. At a $500 aggregated transfer, the same $10 fee is 2%. At a $10,000 aggregated transfer, it's 0.1%. Batching is not optional at scale.

**The operational math.**

WFP and ShareTheMeal are not designed to receive thousands of individual transfers per corporate donor per month. Their systems can, but their finance staff shouldn't have to. When we aggregate, they see one incoming transfer with a summary line item, cross-reference it to our monthly report, issue one receipt on their end, and move on to distribution planning.

Individual per-subscription transfers would create reconciliation overhead on their side that would consume WFP staff time — which is the opposite of what we want. Their staff time should go to logistics, not to paperwork about our micro-donations.

**The timing.**

Charge clears (say, on the 3rd of the month) → $8 earmarked immediately in the LADLE ledger to "pending accrual for month X" → at end of month, sum all accruals for the month, subtract any refunds that occurred in the 7-day window, wire the net total to WFP → receipt published within 5 business days after the wire clears.

This means: your July 3rd subscription's meal donation is part of the July batch, wired at end of July, receipted in early August. Timing lag from your charge to your meals arriving in WFP's operational budget: 3-4 weeks.

**What about refunds mid-month?**

Refunds within the 7-day window unwind the meal accrual before the batch is sent. Refunds after the batch has been sent don't get reversed on WFP's side — the meals were funded — and LADLE absorbs the $8 as an ops cost. This has happened rarely enough that the operational cleanliness (never asking WFP to unwind a batch) is worth the small absorbed cost.

**Why not weekly batches?**

We considered. Monthly matches WFP's own operational cadence for how they think about incoming aggregated donor flows. Weekly would create 4x the accounting artifacts for negligible speed improvement. The meals aren't served the day the wire clears anyway — WFP's distribution runs on its own schedule.

**The escape hatch.**

If the monthly batch doesn't send for any reason (bank issue, our error, WFP receiving delay), we say so in the changelog with the reason. The accrual doesn't disappear — it rolls to the next month with a note explaining the delay. Never happened to date. Documented in advance because it might, and we want to be ready.

**Bottom line.**

Batching is boring plumbing. It's also the operational move that makes the whole model work at scale. Without batching, either the transfer fees would eat 15%+ of every donation, or WFP would be drowning in reconciliation work — either way, less meals for the same money. Batching is boring, batching is honest, batching is how the numbers stay big.