How to Document Overnight and Multi-Day NDIS Support

When support crosses midnight, a single date can leave the reader unsure when the session ended. Clear start and end dates make that context easier to follow, particularly when someone later filters a month of records or reads the notes in an exported chronology.

The examples below are fictional documentation examples. They focus on recording what happened and when; they do not determine billing, shift arrangements or how your organisation should divide work between notes.

Separate the session from the time you wrote the note

Session dates and times describe the support being documented. Creation, submission and approval timestamps describe actions taken on the record. These may fall on different days.

If a session ends at 07:00 and you finish the note at 08:15, those are two different facts. Record the session’s actual end time in the session field. Do not substitute the writing time because it is easier to remember or because the system displays it automatically.

In MyCaseNote, local session dates and times are preserved as entered rather than converted to another device’s timezone. They are not an automatic duration calculation. The record’s creation and workflow timestamps remain separate.

Example 1: A session crossing midnight

For a fictional overnight support session, the recorded timing might be:

• Session start date: 14 September 2026
• Session start time: 22:00
• Session end date: 15 September 2026
• Session end time: 07:00

An excerpt from the note might read:

“At 22:15 on 14 September, Sam asked for assistance locating their reading glasses. I helped check the bedside drawer, where Sam found them. At 06:30 on 15 September, Sam chose cereal for breakfast and prepared it with one verbal prompt to locate a bowl.”

The excerpt identifies observations within the session. It is not a complete record of everything that occurred overnight. Staff should document the relevant support and events they actually know about, following their organisation’s process.

If the note is saved at 08:15 on 15 September, its session still begins on 14 September. Entering the same date for both ends with these times would describe an end before the start. Check the calendar dates as well as the clock values.

Example 2: Support spanning a month boundary

Consider a session recorded from 31 August 2026 at 21:00 to 1 September 2026 at 07:00. It overlaps August and September.

MyCaseNote’s session-date filter includes recorded sessions that overlap the chosen date range. This session can therefore appear in both an August export and a September export. That is useful when reviewing each period, but it needs attention if you later combine those files.

Before assembling a larger chronology, check for duplicate notes at the boundaries. If your purpose is one continuous collection, a single date range can be simpler than stitching together monthly downloads, provided the request fits the export limits. See case note PDF exports for the available formats and limits.

Example 3: A multi-day record with dates only

Suppose your organisation’s documentation process calls for a multi-day summary covering 18–20 September 2026, and exact session times are not known. Record the known start and end dates and leave optional times blank. Explain the scope of the summary in the narrative so the date range is not mistaken for a claim of uninterrupted support.

Do not enter 00:00 or 23:59 simply to make the interval look complete. Those are specific times, not placeholders for “unknown”. If separate daily or worker records are required by your process, a multi-day date range does not replace them.

MyCaseNote allows date-only sessions. When recording times for submission, enter both start and end times with the dates needed to describe a valid interval.

Handle incomplete drafts and historical notes honestly

An unfinished draft can hold incomplete timing while the author checks the details. Before submission, review the required session information and resolve contradictory dates or times.

Older records may contain only a start date. In MyCaseNote, a missing end date falls back to the start date for date-range matching; that does not turn the fallback into a recorded end date. Notes without a session date do not match a session-date range, so a date-filtered export may not represent every historical note on file.

If the true interval is unknown, do not invent an end date to make a record appear in a report. Review historical gaps separately and use the normal correction or amendment process when reliable information becomes available.

Keep timing outside the narrative template

Session timing is shared context for standard and templated case notes. With custom case note templates, you can use narrative sections for support delivered, participant responses and follow-up without requiring workers to re-enter the session interval in every section.

Include an event’s date or time in the narrative where it helps explain the sequence, particularly across midnight. The goal is to give the reader useful context without creating conflicting copies of the same session fields.

Check before submitting or exporting

• Do the start and end dates describe the session rather than the writing date?
• If times are supplied, are both entered and is the end after the start?
• Are narrative events clear about which day they occurred?
• Are unknown historical values left unknown rather than estimated as facts?
• Does a multi-day summary explain what the record covers?
• If combining exports, have you checked overlapping sessions for duplicates?

For a wider review, use the plan reassessment preparation checklist. For help designing the narrative prompts your team uses alongside session timing, see how to create a case note template.