The 5 DSD Route Accounting Models, End to End

Ask a DSD bakery how their owner-operators get paid and you will get five different answers — sometimes from the same bakery, about the same route, on the same day. A chain store billed centrally, a bodega that pays the driver in cash, a deli on a buy/sell spread, a supermarket on consignment, a big-box on pay-by-scan. These are not five kinds of company; they are five kinds of account. This post walks each model end to end — route setup, customer order, delivery, invoicing, weekly reconciliation, and the accounting — and shows how our platform runs all five at once, per account, on a single weekly statement.

If you want the industry deep-dive on why settlement statements exist and what lines they carry, start with DSD Settlement Statements: AR/AP for Independent Distributors. This post is the operational companion: what actually happens, step by step, in each model.

The shared rails: route, order, delivery

Every model starts the same way, because the physical work is identical — only the money differs.

• The owner-operator is a first-class party. An independent operator (IO) is set up with their commission or spread rate, weekly fees (handheld, warehouse, insurance, vehicle lease), and optionally a route loan that repays itself out of every settlement. The IO owns one or more routes financially — separate from who happens to drive them, because IOs hire drivers.
• Every account carries its own settlement type. Each stop on the route is tagged charge, cash, buy/sell, consignment, or scan-based — with an optional per-account rate override. One route mixes them freely.
• Ordering and delivery don’t change. Customers order on the ordering portal (or standing orders generate overnight), the driver packs and runs the route, and marks each stop delivered. At that moment the platform snapshots which IO the delivery belongs to — and then the models diverge.

Model 1 — Charge accounts (central billing)

The classic “house account.” The customer is billed by the bakery, pays the bakery, and the IO earns commission on the weekly statement. This is the default for every account.

• Delivery →the moment the driver marks the stop delivered, an invoice generates automatically — atomically with the delivery, on the account’s own net terms (Net 14, Net 30, COD). No rekeying, no end-of-day batch.
• AR → the invoice lands in the bakery’s accounts receivable— aging, reminders, payment recording — and in the customer’s own portal. The bakery owns the receivable and floats it: the IO gets paid on settlement whether or not the chain has cut its check yet.
• Weekly statement →the engine aggregates the week’s invoices per account and credits the IO commission on gross, then claws back commission on stale and damage credits at the same rate — itemized, so every return is visible.

Worked example at a 19.3% rate: $6,000 delivered and invoiced, $100 credited back for stales → the statement shows commission of $1,158.00 and a stale clawback of −$19.30. The IO earns $1,138.70 on that account, before fees and the truck payment.

Model 2 — Cash accounts (the IO collects at the door)

Small independents — delis, bodegas, corner grocers — pay the driver directly. The bakery never invoices them; the IO owns that receivable and its collection risk. The interesting question is what, if anything, shows up on the weekly statement. In the industry there are two honest answers, so the platform supports both, per account:

• Off-statement(the commission-bakery flavor): door cash never touches the statement. The IO keeps what they collect, and the bakery’s economics live in the wholesale price. Nothing to reconcile.
• Product charge (the buy/resell flavor, Bimbo-style): the statement debits the IO the wholesale value of product delivered to their cash stops that week — retail minus their spread, net of returns. The cash they collected at the door covers the debit; the difference is their margin.

Worked example (product charge, 19.3% spread): $1,000 of product delivered to cash stops, $100 returned → the statement debits $726.30. If the IO collected the full $900 at the door, they cleared $173.70 on those stops.

Model 3 — Buy/sell (a spread off retail)

The classic bread-route model from the big nationals: the IO effectively buys product at a discount off retail and resells it, but chain customers still pay the bakery centrally. The statement reads like a purchase ledger instead of a commission report — and nets to the same economics.

• Delivery + AR → identical to charge accounts: invoice on delivery, bakery collects centrally.
• Weekly statement →per account, the engine credits the full retail the bakery collected on the IO’s behalf, deducts returns at full retail, then debits the wholesale product cost — computed as retail-net times one-minus-spread. The spread is the same rate field the commission model uses, so flipping an account between the two presentations never changes anyone’s pay unexpectedly.

Worked example (19.3% spread): $6,000 retail delivered, $150 credited → revenue +$6,000, credits −$150, product charge −$4,720.95. Net to the IO: $1,129.05 — exactly the spread on net sales, itemized the way a buy/sell operator expects to read it.

Models 4 & 5 — Consignment and scan-based (SBT)

In both models the bakery still owns the product after the truck leaves. Delivery is a stock movement, not a sale — revenue happens when the product sells: a store count for consignment, a POS scan for scan-based trading. So the platform deliberately does not invoice these accounts at delivery. The weekly revenue event is a sell-through report:

• Manual entry— the reality for most regional bakeries: the operator phones in “Route 4 consignment stops did $845 this week, $42 in stales,” and the office types it in. Thirty seconds per account.
• CSV import— a retailer’s or clearinghouse’s weekly report uploads in one shot, with per-row validation (a typo’d account name fails that row, not the file).
• EDI 852 ready — scan-data feeds land in the same pipeline when a retailer mandates them; the data model already carries the source and reference fields.

What happens next depends on who bills. For bakery-billedaccounts, recording the report instantly generates the AR invoice — dated the report date, on the account’s net terms, with reported credits as signed credit lines. Revenue is recognized on sell-through, which is exactly how scan-based trading is supposed to book. For IO-collectedaccounts, no invoice — the report is informational and the account behaves like cash (including the optional wholesale product charge). Either way, the report lands on that week’s settlement: commission on reported gross, clawback on reported credits, each line traceable back to the exact report it came from.

Worked example(bakery-billed, 19.3%): a report of $845 sold / $42 credited creates an $803 invoice to the store and puts $163.09 − $8.11 = $154.98 of commission on the IO’s statement. Unsold product was simply never billed — the bakery bears shrink by construction, which is the whole point of consignment.

One route, one statement

Here is the part that breaks spreadsheets: a single operator’s Tuesday can include all five. The weekly settlement statement nets every model — plus chargebacks, promo allowances, weekly fees, and the route-loan payment — into one signed number that can go negative when the IO owes.

The reconciliation and the accounting

Every week the engine closes the period per operator: it aggregates each model’s activity, pulls in pending chargebacks and sell-through reports exactly once, applies fees and the loan payment, rolls forward any unpaid negative balance, and produces a draft. Staff review, finalize (that is when loan balances actually move), and record the remit — check, ACH, or a negative payment when the operator owes. The operator sees every finalized statement, line by line, in their own portal, and the year’s finalized statements are the 1099 total — not a January spreadsheet reassembly.

On the general ledger, the platform follows the treatment the large public bakers use: customer revenue booked gross, the operator’s cut as a distribution expense, product charges as COGS recovery, route-loan payments against notes receivable. Three sub-ledgers — customer AR, the operator settlement ledger, and the loan book — reconciled by construction, because every number on the statement traces to the same delivery, invoice, or report it came from.