Online Tenant File Builder

At minimum: identity verification, proof of income, right-to-rent evidence, references (previous landlord and/or employer), and any guarantor documents where applicable. What's mandatory varies by jurisdiction and letting type, so confirm the current legal minimum rather than copying a generic list.

Beyond the legal minimum, add only what the letting decision actually depends on. A file padded with 'nice to have' extras is harder to review and doesn't make the tenancy decision any better supported.

Distinguish documents needed before the tenancy starts from ones needed only if something goes wrong later — a guarantor's contact details, for instance, matter far more after a missed payment than during initial referencing, but should still be collected upfront.

Organising by requirement — one section for ID, one for income, one for references — makes it obvious at a glance what's missing for any given tenancy. Organising loosely by 'documents from this applicant' hides the same gap inside a flat list.

This matters more for joint tenancies, where multiple applicants each need to complete the same set of requirements. A requirement-based view shows exactly which applicant is missing which item; an applicant-based view makes that a manual cross-check.

Keep the same structure across every property and tenancy type where possible. A consistent shape means a reviewer moving between cases doesn't have to relearn where to look for a given document each time.

If referencing runs through a separate portal, at minimum keep a link and the outcome inside the tenant file, rather than leaving it as a separate system nobody checks when reviewing the file as a whole.

Right-to-rent checks, in particular, should be recorded with a date and evidence in the file itself — not just noted as 'done' in someone's memory or a spreadsheet that isn't tied to this specific tenancy.

Where possible, trigger the checklist for these checks automatically at application stage rather than relying on someone remembering to run them manually for every applicant.

A tenant file isn't done at move-in — it's the reference point for the rest of the tenancy: a dispute, a renewal, a guarantor being contacted after a missed payment. If it's scattered by then, none of those situations get easier.

Set a retention rule for the file rather than letting it sit indefinitely or get deleted the moment the tenancy starts. What to keep, and for how long, is usually a compliance question as much as a convenience one — check local requirements.

Avoid duplicating the same document across systems as the tenancy progresses (a fresh copy of ID for a renewal, for instance, when the original is still valid). One current file, updated rather than re-created, stays trustworthy longer.

Give guarantors their own section inside the same tenant file, not a separate file linked loosely by name. That keeps the guarantor's documents discoverable exactly when they're needed — typically well after the original onboarding is finished.

For joint applicants, avoid asking each person to re-submit shared property details (the address, the tenancy terms) that don't vary between them. Only the requirement-specific documents — each person's own ID and income proof — need to be collected per applicant.

Make clear inside the portal which items are shared and which are individual. Without that distinction, joint applicants either duplicate effort unnecessarily or assume something was handled by the other applicant when it wasn't.