Senior Living Vendor Contract Inventory: A Template for Multi-Community Operators

What gets a record

These are working rules for your register. They aren't a legal definition of a contract.

• A PDF is a file, not a record. It might be a full agreement, an amendment, an exhibit, or the third scan of the same signed copy.
• A signed agreement gets one record and one stable ID. Amendments, exhibits, and schedules attach to that ID. A second amendment doesn't create a second contract.
• The vendor is the legal party named in the signed document. The name on the truck or the invoice may be a brand. The agreement may name a differently titled company, and two agreements under one brand may name different companies.
• Your contracting entity isn't the same as the community. A parent company, management company, or community-level entity may have signed. The communities covered are usually listed in an exhibit or schedule. A community name on the cover page doesn't establish who signed or who is covered. Check the parties clause, the signature blocks, and the coverage exhibit.
• Coverage is a separate relationship. A waste agreement serving six communities is one agreement with six coverage rows.

Some cases need judgment. A local agreement a community signed on its own gets its own record, even when the same vendor also holds a corporate agreement. When a master agreement sets general terms and community schedules set start dates, pricing, or scope, keep one record and put the local differences on the coverage rows. If a schedule carries its own term and renewal language, it may need its own record, linked to the master. An agreement signed before you acquired a community gets its own record too. How it applies now depends on its terms and the transaction, so flag it for review rather than assuming it transferred, or that it didn't.

The template

Use two tabs. Agreements has one row per agreement. Coverage has one row per agreement-community pair. You count agreements on one tab and coverage on the other, and neither gets double-counted.

agreement_id,vendor_party,contracting_entity,category,source_documents,term_end,renewal_type,notice_rule,cancel_by_date,pricing_basis,owner,status,checked_on,next_action

Most fields explain themselves. A few need a convention:

• agreement_id: a stable ID you assign, such as AGR-014. Never reuse one.
• vendor_party and contracting_entity: the parties exactly as the signed agreement names them.
• source_documents: the signed agreement plus every signed amendment and exhibit, in order, with file locations.
• notice_rule: the non-renewal requirement as written, with the section number.
• cancel_by_date: the last day notice can be given under that rule. It's a calculation, not contract wording. Finding it takes its own check.
• pricing_basis: how the contract prices the service (per pickup, per pound, monthly per container), as stated.
• status: one of four values.
  • Verified: checked against the listed signed documents on the checked_on date.
  • Needs review.
  • Missing documents: an agreement was found but is incomplete.
  • Not located: a lead, such as recurring payments, with no agreement found yet.

Give Not located leads their own prefix, such as LEAD-001. Leave them out of agreement totals and report them separately as open investigation items.

agreement_id,community,coverage_source,local_start_date,local_terms

coverage_source names the document and exhibit that put the community on the agreement. local_terms records anything that differs from the master: a different rate, service frequency, or scope. Write "None stated" only after checking the relevant schedule. If you haven't checked it, write Unknown.

Optional columns, when you're ready for them:

parent_agreement_id,estimated_annual_spend,spend_source

Use parent_agreement_id when a separately recorded schedule sits under a master. Keep spend estimates in their own columns with their source, so nobody mistakes an accounts payable figure for a contract term.

A worked example

The operator, vendor, entities, communities, and dates below are fictional.

A nine-community operator finds four waste-hauling PDFs, all under the Vendor A brand:

• a master services agreement
• what looks like a second copy of it
• Amendment No. 1
• an agreement Community G signed before the operator acquired it

A side-by-side comparison of contents, agreement reference, parties, and execution pages shows the second file is a rescan of the signed master. It's filed with that record. The amendment attaches to the master. Community G's agreement gets its own ID, and it turns out to name a different Vendor A company.

Agreements tab

Coverage tab

Accounts payable shows monthly waste charges at Communities H and I, but no agreement for either has been found. Each gets a lead, LEAD-001 and LEAD-002, with an owner.

AGR-015 is the more urgent record, despite having the fewest facts. Its cancel-by date might be months away or next week, and nothing in the file rules out either.

Building the first version

1. Gather signed versions with every attachment. Keep drafts and redlines out of the register.
2. Treat look-alike files as a review flag. A master agreement and a local schedule can be signed the same day. Compare contents, agreement reference, scope, parties, and execution pages before merging anything.
3. Open leads for gaps. Recurring payments with no agreement on file, and communities with no coverage row for a service they clearly receive, each get a LEAD row.
4. Name an owner for every record and lead. A person, not a team.
5. Check notice terms before trusting any date in the cancel-by column, and record when you checked.
6. Queue the investigation by confirmed cancel-by date and by how much each service matters to residents and daily operations. Unknown deadlines stay near the top, alongside the nearest confirmed ones.

Then keep it from going stale. "Verified" means checked against a specific set of signed documents on a specific date, not correct forever. Set a record back to Needs review when:

• an amendment is signed
• a renewal takes effect
• a community is acquired, opened, or divested
• a vendor changes its notice address or legal name

What the register can and can't say about cost

The register records how each agreement prices a service, not what you paid. Invoices can differ from contract rates because of surcharges, extra pickups, minimums, or escalators. Comparing rates also requires comparable scope. Prices for the same service can differ between a central agreement and community-level purchasing. A per-pound linen rate doesn't line up directly with a per-piece rate, and waste rates for different container sizes or pickup frequencies don't line up either.

A lower contract rate is a reason to look closer. Showing realized savings takes a comparable baseline, similar scope and volumes, and purchasing or invoice evidence of what was actually paid. Keep projected cost avoidance from a new rate separate from savings you can show in paid invoices.