operating-model / loops/renter-loop/attribution.md
id: renter-loop.attributiontype: domainstatus: activeversion: 2.0loop: renter-loop

Domain · Financial close

What it covers

Ensuring every signed lease translates into invoiced, received revenue attributable to the loop. Small in volume but high in importance — this is the validation that the rest of the loop is real.

Activities

  • Coordinating with the Operator Loop's monthly confirmation cycle.
  • Ensuring every signed lease is correctly represented for invoicing.
  • Tracking lease-to-cash at the cohort level.

Operations

Monthly lease attribution operation

Signal: End of month. Steps: Match Renter Loop signed leases against invoiced amounts → flag any signed-but-not-invoiced cases → resolve before close. Closed state: Zero signed-but-not-invoiced leases at month close. Cadence: Monthly. Discipline: Zero tolerance. A signed lease that is not invoiced is a broken loop.

Cohort lease-to-cash operation

Signal: Signed lease event. Steps: Track each signed lease through to received payment → calculate true revenue per channel cohort → feed back into renter-loop.demand.attribution-reconciliation. Closed state: Payment received and attributed; cohort revenue metric updated. Cadence: Continuous.

Notes

Often forgotten by people who think of themselves as doing demand-side work. The Renter Loop is not closed at signature — it is closed when money has moved. This domain is the discipline that prevents the loop from quietly leaking revenue.

For White Label leases, the invoiced amount is the £750 per-lease fee rather than a commission. The operations are unchanged; the pricing variable is handled per-vehicle in the invoicing layer (Financial Loop), not by branching these operations.

Comment on GitHub →