Home / Blog / How to track real estate contract deadlines on a calendar

How to track real estate contract deadlines on a calendar

Get option, inspection, financing, title and closing dates from the contract onto Google Calendar with reminders, and flag weekend dates instead of moving them.

An executed contract starts a handful of clocks at once. Earnest money is due, the option or inspection period is running, the lender needs an appraisal, title has to produce a commitment, and closing sits at the end. Most solo agents track all of that in a PDF, a sticky note and their memory. NAR's 2025 member data puts the typical member at 10 transaction sides in 2024, which is enough to have a few overlapping deals and usually not enough to justify a full-time transaction coordinator.

This walkthrough shows how to get those dates onto a calendar everyone already checks, and the one judgment call that's easy to get wrong. The last part covers our contract deadline calendar recipe, which automates it, and how we tested it.

Nothing here is legal advice. Your contract, your broker and, if needed, a real estate attorney decide what each deadline means.

Step 1: List the deadlines your contract actually creates

Start from the form your state uses, not a generic checklist. We'll use the Texas one-to-four family resale contract, TREC form 20-18, as the example because it spells its deadlines out clearly. In that form:

  • Earnest money and the option fee are due "within 3 days after the Effective Date."
  • A notice to terminate under the option period "must be given by 5:00 p.m. (local time where the Property is located) by the date specified," and the contract says time is of the essence for that paragraph.
  • The title company has 20 days after it receives the contract to deliver the title commitment.
  • If the seller's disclosure notice arrives late, the buyer gets 7 days after receiving it to terminate.
  • Closing happens "on or before" the date filled in.

Other states' forms use different periods and different language, so build your list from your own form.

Step 2: Decide how weekends and holidays count, then don't automate that decision

This is the step where tools usually go wrong. TREC 20-18 extends a deadline that lands on a Saturday, Sunday or legal holiday, but only for delivering earnest money and the option fee: the time "is extended until the end of the next day that is not a Saturday, Sunday, or legal holiday." It doesn't say the same about the 5:00 p.m. option-period deadline. A tool that pushes every weekend date to Monday could get the earnest money right and the option period wrong.

Our approach is to flag those dates and leave them where they are. The calendar entry says the date is a Saturday or a federal holiday, and a person who has read the contract decides what that means. If you're unsure how your form counts days, ask your broker before the deal, not on the Friday it matters.

Step 3: Confirm every date by hand

Type or confirm each date from the executed contract and any amendments. Don't let software read dates out of the PDF on its own. A missed deadline is bad, but a confidently wrong one is worse, because nobody double-checks it. Having your TC or a second person confirm the list helps catch typos.

Step 4: Put each deadline on the calendar with reminders

All-day events work better than timed ones for most contract deadlines. For each:

  • Name the event with the address and the deadline, so it reads clearly on a phone.
  • Add an email reminder a few days before and a pop-up the day before.
  • Invite your TC or partner so they get the same reminders.
  • Put the exact contract language in the description when there's a time of day, like the 5:00 p.m. option deadline.

Step 5: Update the calendar when the contract changes

Amendments move dates, and terminated deals should disappear from everyone's calendar. Edit the existing events instead of adding new ones, or the old dates will keep reminding people.

Automating it: the contract deadline calendar recipe

Our recipe does steps 4 and 5 from a short form. You or your TC confirm seven dates (option period, inspection, appraisal, financing, title, final walkthrough and closing), and the workflow creates seven all-day Google Calendar events, each with an email reminder three days before and a pop-up the day before. It invites the TC, sends invitations with Google's sendUpdates=all setting, and emails a summary with an .ics file. Weekend dates and federal holidays are flagged, not moved. State holidays aren't included. Every morning at 7:00 it sends a digest of anything due in the next three days.

If you use dotloop, it can pre-fill the form from a loop, but it still won't write anything to the calendar until a person confirms the dates.

The workflow has 10 nodes. We don't have screenshots yet, so here they are from the workflow file (some steps pair two nodes):

  1. Deadline form (webhook)
  2. Check, pre-fill or plan calendar changes
  3. Calendar calls, then Google Calendar API
  4. Record event ids, email summary + .ics
  5. Emails, then Send email
  6. Every day 7:00, plus a manual/test tick
  7. Digest: due in the next 3 days

How we tested it

Our testing notes describe the setup for every recipe. We imported the workflow into n8n 2.45.4 and ran it against a local mock server built from Google Calendar's and dotloop's API documentation. The mock checks the same request shapes, expires dotloop's access token so the refresh path runs, and records every call. Agents, deals and addresses are invented, and nothing was sent to a real calendar or person. There's no AI model; every decision is a written rule. The last run passed 8 of 8 scenarios:

  • C1, a confirmed manual entry. Seven all-day events with reminders, the agent and TC invited, plus the summary and .ics. A Saturday and Thanksgiving were flagged but not moved.
  • C2, a dotloop loop without confirmation. The workflow read the loop, hit an expired token, refreshed it and retried, then emailed the TC the dates to check with a pre-filled link. It wrote nothing to the calendar.
  • C3, bad input. Inspection after closing, a date it couldn't parse and no "confirmed" tick produced nothing on the calendar and one email listing every problem.
  • C4, an amendment. Moving closing to December 18 patched the existing event instead of creating a duplicate, and the summary showed old and new dates.
  • C5, the same form again. No calendar calls and a "no changes" email.
  • C6, spam. A filled-in hidden honeypot field and a wrong form key were both ignored.
  • C7, the daily digest. It listed only the inspection due within three days, and a second run the same day sent nothing.
  • C8, a terminated deal. All seven events were deleted with notifications, and later digests skipped the deal.

Two things broke on the way. The first was in our test setup, not the workflow: the mock dotloop server handed back a "fresh" token that was already expired, so the refresh path looked broken when it wasn't. We fixed the mock and the C2 test passed. The second was a gap we noticed in review: a public form with no protection would accept junk submissions, so we added the hidden company_website honeypot field that C6 now tests.

Testing against mocks proves the logic, not your calendar. The recipe's setup asks you to enter one past deal with known dates and compare the calendar against the contract before relying on it.

What it costs

Google Calendar comes with the Google account or Workspace plan you already have. Google's Calendar API quota page says standard use is available at no additional cost, but also that exceeding quota limits is planned to incur charges later in 2026, with at least 90 days' notice. A few deals a month is far below those limits. The emails fit in a free sending tier, so the recipe page estimates about $0 a month plus your n8n server. dotloop is optional, and its API needs dotloop to approve your app, with tokens that expire after about 12 hours.

Every message the workflow sends is signed with your name, license number and brokerage. Ask your broker what your state requires there.

Found an error or a better source? Corrections policy. More articles on the blog.