Build Your Own Move-Out Inspection and Deposit Deduction System

Capture the move-in baseline

Before keys change hands, walk the unit and write one inspection_item row per room and item: walls, flooring, ceiling, fixtures, appliances, windows, doors. Each row carries a condition rating on the schema's six-word scale (new, good, fair, worn, damaged, missing), free-text notes for anything pre-existing, and a photo count. The photos themselves live in your storage; the schema only needs to know they exist and how many cover each item, and it holds you to that with a CHECK constraint: a row rated damaged or missing with zero photos is rejected outright, because an undocumented damage claim is worthless.

This is no longer just good practice. Under California Civil Code section 1950.5 (leginfo.legislature.ca.gov), for tenancies beginning July 1, 2025 or later, the landlord must photograph the unit at the inception of the tenancy, and must later deliver move-out photographs with the itemized statement. The statute is effectively mandating the baseline this step builds.

-- Move-in baseline (unit 12 under lease 340 in the worked example)
INSERT INTO inspection (unit_id, lease_id, inspection_type, inspected_at, tenant_present)
VALUES (:unit_id, :lease_id, 'move_in', '2024-06-01', true)
RETURNING id;  -- keep this id; the move-out will point back at it

INSERT INTO inspection_item
  (inspection_id, room_label, item, condition_rating, notes, photo_count)
VALUES
  (:move_in_id, 'living_room', 'walls',      'new',  'Fresh paint, no marks',               4),
  (:move_in_id, 'living_room', 'carpet',     'good', 'Light wear at entry',                 3),
  (:move_in_id, 'bedroom_2',   'carpet',     'new',  'Installed June 2023',                 3),
  (:move_in_id, 'bedroom_2',   'walls',      'new',  NULL,                                   4),
  (:move_in_id, 'kitchen',     'countertop', 'fair', 'Small chip near sink, pre-existing',  2);

Field note: the notes column earns its keep on pre-existing flaws, and the install date on anything with a useful life. "Installed June 2023" on the bedroom carpet is six words at move-in that become the entire depreciation calculation at move-out.

Trigger the move-out inspection from the notice

The day a move-out notice lands, two things should happen mechanically: the notice is recorded as a dated legal fact in the notice table (served date, effective date, delivery method), and the move_out inspection is created from it, dated to the notice's effective date and pointing at the baseline through baseline_inspection_id. Do not wait until the tenant is gone to think about the inspection; the clock that matters (the statutory return deadline in step 6) starts at vacancy, and the walk needs to happen at the front of that window, not the end. Clone the baseline's room and item list into the new inspection's checklist so the inspector walks exactly what was walked at move-in; a diff only works when both sides cover the same ground.

-- Record the notice as a dated legal fact (lease 340 in the example)
INSERT INTO notice (lease_id, notice_type, served_on, effective_on, delivery_method)
VALUES (:lease_id, 'tenant_notice_to_vacate',
        '2026-05-28', '2026-06-30', 'email');

-- Open the move-out inspection from it, once, pointed at the baseline
INSERT INTO inspection
  (unit_id, lease_id, inspection_type, baseline_inspection_id, inspected_at)
SELECT l.unit_id, l.id, 'move_out', b.id, n.effective_on
FROM lease l
JOIN inspection b ON b.lease_id = l.id
                 AND b.inspection_type = 'move_in'
JOIN notice n     ON n.lease_id = l.id
                 AND n.notice_type = 'tenant_notice_to_vacate'
WHERE l.id = :lease_id
  AND NOT EXISTS (
    SELECT 1 FROM inspection i
    WHERE i.lease_id = l.id
      AND i.inspection_type = 'move_out'
  );

In California, one more inspection sits in this window: the tenant can request an initial inspection before move-out, and section 1950.5 also requires post-possession photographs taken before any repairs or cleaning begin. Model that as a routine inspection tied to the same lease; the schema's inspection_type enum already accommodates it.

Run the comparison query

This query is the heart of the system. It joins every move-out item to its move-in twin for the same unit, room, and item, and returns only the rows where condition dropped. The output is the delta ledger shown above: the complete, and only, set of candidates for deduction. Anything not on this list either did not change or was already accounted for in the baseline, and charging for it is how deposit disputes start.

-- Condition deltas: move-out vs move-in, same room and item.
-- condition_rating is text, so ordering comes from its position on
-- the scale: new, good, fair, worn, damaged, missing.
WITH scale AS (
  SELECT ARRAY['new','good','fair','worn','damaged','missing'] AS r
)
SELECT
  mo.room_label,
  mo.item,
  mi.condition_rating AS move_in_rating,
  mo.condition_rating AS move_out_rating,
  array_position(s.r, mo.condition_rating)
    - array_position(s.r, mi.condition_rating) AS severity_steps,
  mo.notes            AS move_out_notes,
  mi.notes            AS baseline_notes,
  mi.photo_count      AS baseline_photos,
  mo.photo_count      AS move_out_photos
FROM inspection_item mo
JOIN inspection io      ON io.id = mo.inspection_id
JOIN inspection_item mi ON mi.inspection_id = io.baseline_inspection_id
                       AND mi.room_label = mo.room_label
                       AND mi.item       = mo.item
CROSS JOIN scale s
WHERE io.id = :move_out_inspection_id
  AND array_position(s.r, mo.condition_rating)
      > array_position(s.r, mi.condition_rating)
ORDER BY severity_steps DESC;

Three details worth copying exactly. The join runs through baseline_inspection_id, the pointer every move-out inspection carries back to its own move-in, so a unit's previous tenancies never bleed into the current diff. The pairing is sound because the schema enforces UNIQUE (inspection_id, room_label, item): each move-out line has exactly one baseline twin to match. And the query returns both photo counts, because a delta with zero move-out photos is a charge you cannot defend; the schema already refuses damaged and missing ratings without photos, and your review screen should hold every other worsened row to the same bar.

Classify each delta: wear and tear or damage

Every delta now needs a call, and the call is a legal one before it is a financial one. Section 1950.5 bars California landlords from deducting for "ordinary wear and tear or the effects thereof," and Washington's RCW 59.18.280 (leg.wa.gov) draws the same line while also refusing deductions for damage the landlord cannot document. The working test: would this condition exist if a careful tenant had lived here the same number of years? If yes, it is wear and tear and the deposit does not pay for it. If the condition required an incident (an impact, a pet, a burn, neglect), it is damage.

The pairs matter more than the lists. Nail holes are wear; a wall gouge is damage. A carpet's traffic path is wear; the same carpet's pet stain is damage. Faded paint is wear; crayon murals are damage. Encoding the classification as data (a category on each delta, with the waived rows kept, not deleted) means the statement can later show not just what you charged but what you chose not to charge, which reads very differently to a tenant weighing whether to dispute. Our tenant damage research compiles how often each of these categories actually shows up at move-out.

Price it, with depreciation, and write the deduction rows

Repairs are charged at cost: the drywall patch is the contractor invoice or your materials plus documented labor time (Washington's RCW 59.18.280 spells out exactly that: bill, invoice, or receipt for materials, plus time spent and a reasonable hourly rate for the landlord's own work). Replacements are different. If the tenant destroyed a carpet that was already three years into its life, charging full replacement price bills them for value that was already gone, and courts routinely cut such charges down. The defensible method is remaining useful life. According to IRS Publication 527 (irs.gov), appliances, carpeting, and furniture used in a residential rental activity are 5-year property, which gives you a standard, citable life to prorate against.

The worked example: lease 340 ends with an $1,800 deposit held and three charges surviving classification. The bedroom carpet ($1,200 to replace the room) was installed 36 months before move-out; with a 60-month life, 24 months of value remain, so the charge is $1,200 × 24/60 = $480. The wall gouge is a $180 repair at cost. Cleaning back to the move-in standard is $150, and the schema's category enum names it precisely: cleaning_beyond_normal, because routine turnover cleaning is not the tenant's bill. Note the foreign key on every row: each deduction points at the inspection_item that documents it, and the schema makes that column NOT NULL.

-- Deposit 77 in the worked example holds $1,800 for lease 340.
-- Carpet: $1,200 replacement, 36 of 60 months used, 24/60 remain
--   1200.00 * 24 / 60 = 480.00
INSERT INTO deposit_deduction
  (security_deposit_id, inspection_item_id, category, description, amount)
VALUES
  (:deposit_id, :carpet_item_id, 'damage',
       'Bedroom 2 carpet: pet stains, replacement prorated to remaining life',
       480.00),
  (:deposit_id, :wall_item_id, 'damage',
       'Living room wall: gouge behind door, patch and repaint',
       180.00),
  (:deposit_id, :cleaning_item_id, 'cleaning_beyond_normal',
       'Cleaning to documented move-in standard',
       150.00);

Field note: the FK to inspection_item is the discipline, not a nicety. A deduction that cannot name its documenting inspection line should fail a NOT NULL constraint, because the same charge would fail in front of a judge.

Encode state rules as data, not code

How long you have, what you must attach, and how notice travels all vary by state, and they change. Hardcode "21 days" into your workflow and the system silently breaks the day you buy a unit across a state line, or the day the legislature amends the statute. Keep the rules in a reference table keyed by state and join through property:

Three rows shown; your table carries one per state you operate in, verified against the state legislature's own published code, not a blog's summary. Florida Statute 83.49 (leg.state.fl.us) is a good illustration of why the shape of the rule matters, not just the number: it is not a "return within N days" rule but a notice regime, where failing to send the certified-mail notice within 30 days forfeits the claim entirely. The reference table needs columns for the mechanics, not just the day count.

You do not have to build this table. The reference schema ships it as state_deposit_rule, seeded with eight states whose rows were verified against the statute text and stamped with a verified_on date, because a compliance rule you cannot date is a compliance rule you cannot trust. Add rows for the states you operate in, re-verify yearly, and join through the property:

-- state_deposit_rule ships seeded in the reference schema.
-- Adding a state you operate in follows the seeded shape:
INSERT INTO state_deposit_rule
  (state_code, return_deadline_days, claim_notice_deadline_days,
   deadline_note, deposit_cap, documentation_note, statute, verified_on)
VALUES
  ('FL', 15, 30,
   'Full refund within 15 days if no claim; written notice of intent to claim by certified mail within 30 days, or the claim is forfeited',
   'No statutory cap.',
   '15-day tenant objection window after the claim notice',
   'Fla. Stat. 83.49(3)', DATE '2026-08-01')
ON CONFLICT (state_code) DO NOTHING;

-- When is this deposit's statement due, and under which statute?
SELECT sd.id,
       l.moved_out_on + r.return_deadline_days AS statement_due,
       r.documentation_note,
       r.statute,
       r.verified_on
FROM security_deposit sd
JOIN lease l              ON l.id = sd.lease_id
JOIN unit u               ON u.id = l.unit_id
JOIN property p           ON p.id = u.property_id
JOIN state_deposit_rule r ON r.state_code = p.state_code
WHERE sd.id = :deposit_id;   -- deposit 77 in the worked example

Produce the tenant-facing statement

Everything so far exists to make this last step a query instead of an argument. The statement lists each deduction with its room, item, description, and amount, shows the math from deposit held to refund due, names the evidence behind every line, and goes out before the due date computed in step 6. For the worked example, with the unit vacated June 30 in California, the statement is due July 21 and looks like this:

The statement the system generates: every charge traceable to an inspection line and its photos, the depreciation math shown, the waived wear-and-tear item named, and the statutory requirements satisfied on their face.

-- Statement lines with their evidence
SELECT dd.description,
       dd.amount,
       ii.room_label,
       ii.item,
       ii.photo_count,
       ii.notes
FROM deposit_deduction dd
JOIN inspection_item ii ON ii.id = dd.inspection_item_id
WHERE dd.security_deposit_id = :deposit_id   -- deposit 77 in the example
ORDER BY dd.amount DESC;

-- The totals box
SELECT sd.amount                              AS deposit_held,
       COALESCE(SUM(dd.amount), 0)            AS total_deductions,
       sd.amount - COALESCE(SUM(dd.amount),0) AS refund_due
FROM security_deposit sd
LEFT JOIN deposit_deduction dd ON dd.security_deposit_id = sd.id
WHERE sd.id = :deposit_id
GROUP BY sd.id, sd.amount;

Render it however your stack renders documents (HTML to PDF is fine), send it by whatever method your state's rule row requires, and record the send date. If the refund is short or the statement is late, the reference table row tells the next person exactly which statute they are now explaining.