Decide: does holt recognise revenue when the order is written, or when it is invoiced?

[goetchstone]

The question

computeDailyReconciliation compares two sides that are on different accounting bases:

• source.revenue — every order written on the day. SALES_REVENUE_STATUSES includes ORDER, so an order placed today counts immediately.
• journal.revenue — only orders carrying an invoice. generateSalesJournal defers everything else to Customer Deposits.

For a furniture retailer this diverges structurally. A special order written today and delivered in six weeks appears as revenue drift equal to its full value, every day until it is invoiced. The balanced flag goes false and the warnings list a "Revenue drift" that is not an error.

A daily control that reports a false discrepancy every day is one people stop reading — the same failure mode as the cash-bucket bug fixed alongside this one.

Why this is not just a bug fix

Both readings are defensible and they are a business policy, not an implementation detail:

1. Recognise on invoice (accrual). Today's journal behaviour is correct; the reconciliation's source side is measuring bookings and should either match the journal's basis or report deferral as its own reconciling item rather than as drift.
2. Recognise on order. Bookings are the real measure and generateSalesJournal's if (!order.hasInvoices) gate is an artifact of how Ordorite modelled orders, inherited rather than chosen.

Picking one silently would set an accounting policy for every deployment from inside a test fixture.

Current state — pinned, not papered over

__tests__/integration/tradingDay.integration.test.ts stage 14 asserts the drift equals exactly the un-invoiced bookings:

const DEFERRED_REVENUE = 5000;
const DEFERRED_COST = 2500;
expect(recon.drift.revenue).toBeCloseTo(DEFERRED_REVENUE, 2);
expect(recon.drift.cost).toBeCloseTo(DEFERRED_COST, 2);

So the number stays explained. If it ever stops equalling the deferred amount, something other than deferral is wrong and the test says so.

What resolving this looks like

Whichever way it goes, DailyReconciliationSource.revenue / .cost and the drift warnings need to say which basis they are on, and the two sides need to agree. If option 1: add a deferred component so drift means genuine drift. If option 2: drop the invoice gate in buildJournalLines.

Documented in docs/domains/accounting.md under "Open: bookings vs recognised revenue".

[goetchstone]

Decided: recognise on delivery

From the product owner:

anything not delivered, is a promise, not a sale, we may report the sales data in reports and dashboards but those sales are in accounting deposits and liabilities until delivered. Anything delivered generates the "invoice" which then would move the money from deposits and make the journal entries for the sales and tax etc

and:

same with a pickup too

The policy

1. Not handed over → not a sale. It is a promise. In accounting the money sits in customer deposits / liabilities. Reports and dashboards may still show it as sales data (bookings) — that is explicitly allowed and must not be "fixed".
2. Handover generates the invoice. The invoice moves the money out of deposits and produces the journal entries for sales, tax and COGS.

What counts as handover

holt already models three fulfilment methods (SalesOrder.deliveryMethod, set in create-from-cart.ts:52). All three are the same accounting event — the goods left the building:

Method	Handover moment
DELIVERY	the delivery stop completes
PICKUP	the customer collects (READY_FOR_PICKUP → FULFILLED)
TAKEN	at the till — cash-and-carry, delivered immediately

What this settles

The journal side was already correct: generateSalesJournal defers an un-invoiced order to Customer Deposits, which is exactly the policy.

Two things are wrong, and one is missing:

• Wrong: computeDailyReconciliation compares a bookings-basis source against a recognised-basis journal and calls the difference "drift". It should not — deferral is expected, not an error.
• Missing: nothing makes handover generate the invoice. dispatch.ts already has the right seam — dispatchStatus === "FULFILLED" guarded on the transition, inside a transaction, already calling consume() because "the goods left the building" (its own comment). The invoice belongs there.
• Also missing: create-from-cart records deliveryMethod: "TAKEN" but creates the order as status: "QUOTE" with no dispatchStatus, so a cash-and-carry sale is never marked fulfilled and never invoices.

Implementation tracked separately; this issue stays open until the reconciliation stops reporting deferral as drift.