COD Isn't "Paid." It's a Receivable.

Cash on Delivery looks simple from the outside: customer gets the package, customer pays the driver, order is "paid."

Most systems model it exactly that way - a boolean on the order row flips from false to true and everyone moves on. That's wrong, and it took a support ticket to notice why.

The Money Isn't Ours Yet

The money the driver collected isn't actually ours yet. It's sitting with the carrier until they run their settlement cycle and transfer it over - which, depending on the carrier, can be days or weeks later.

During that whole window, paid: true is a lie. The order is fulfilled, sure. The cash isn't.

From Flag to Receivable

So we stopped treating it as a flag and started treating it as what it actually is: a receivable.

An order moves from:

• placed
• COD pending (an open receivable on our books)
• carrier payout
• reconciled

And it's only "settled" once we've matched an actual payout from the carrier against that specific order's expected amount.

If the carrier's payout comes in short, or an order's COD never gets matched to any payout, that's visible - not quietly absorbed into paid: true.

Why a Ledger Beats a Boolean

It's a small modeling change but it matters most for exactly the stores that rely on COD heavily, where this isn't an edge case, it's most of the order volume.

A boolean can't tell you if a carrier is underpaying you on 3% of orders every month. A reconciled ledger can.

Built this into StoreFlux (storeflux.store) - a backend-as-a-service for e-commerce.

Curious how other people handle carrier-collected payments in their own systems - anyone doing something smarter than a straight ledger match?